INTERNET-DRAFT K. Ohira M. Kozuka Y. Okabe Kyoto University Y. Koyama Trans New Technology July 19, 2004 IPv6 Address Assignment and Route Selection for End-to-End Multihoming Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 19, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Ohira Expires on January 19, 2005 [Page 1] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 Abstract In this document, we propose a way of address assignment and route selection suitable for "Host-Centric" multihoming, where an end node plays the main role of multihoming. The key techniques are a hierarchical address assignment and a source address dependent routing (SADR) for only default route entry. In our proposal, an IP address itself has some sense of routing information. We propose that an address assignment SHOULD be hierarchical. Under the conditions that address assignment is hierarchical, when someone delegates an address block, it means that it also hands routing information to its downstream at the same time. In this manner, a host which has several addresses can select which upstream to go through with by selecting its source address. 1. Introduction As described in RFC3582 [3582], the main purpose of multihoming is getting redundancy and load sharing. Usually, if someone wants a site to be multihomed, he has to get an AS number and connect to upstream ISP with BGP peering. This method is too difficult to configure and AS numbers are limited, so it is actually unable for small sites to be multihomed. In the BGP method, we MUST trust any routing information from outside of a site and reconfigure routing information inside of the site, so this method is problematic at reliability and its speed. Furthermore, in IPv6, it is REQUIRED that we aggregate addresses more thoroughly than in IPv4 because of its address length. In this document, we show a scalable way to multihome with a very little information from outside. It is based on so-called "Host-Centric" [HOSTS] multihome, where an end node plays the main role. 2. Types of multihoming sites 2.1 Definition of Terms Terms which are not referred here are used as the meaning in RFC3582 [3582]. Ohira Expires on January 19, 2005 [Page 2] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 The term "site" means a small site such as a home network. The term "end-to-end" means that an identity / locator binding should be done within the end-to-end transport protocol layer (Section 5.3.3 of [ARCHITECTURE]) though this proposal is applicable with an IP layer solution or a shim layer solution. 2.2 Network topology of a site First, it should be noted that every host centric solutions in a small site is completed within the site. In other words, it is nothing to do with an action of an upstream ISP. Moreover, even if another site adopts another solution, a communication between those two sites must not inhibited only because of it. Furthermore, in the most of usual methods, routing information in a site deeply depends on that from outside of the site. This is problematic at the point of reliability and its speed. A site is classified into the following 3 cases according to the location(s) of site exit router(s): 1. Single link, single exit router (Fig. 1), 2. Single link, multiple exit routers (Fig. 2) and 3. Multiple link, multiple exit routers (Fig. 3). | | | | | | +-----+ +-----+ +-----+ | | | | | | +-----+ +-----+ +-----+ | | | ----+-+------ ------+-----+------+------ | | +-----+ +-----+ | | | | +-----+ +-----+ [Fig. 1] [Fig. 2] Ohira Expires on January 19, 2005 [Page 3] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 | | | | +-----+ +-----+ | | | | +-----+ +-----+ | | ---+--+---- ----+--+--- | | +-----+ +-----+ | | | | +-----+ +-----+ | | ---+--------+---------+--- | +-----+ | | +-----+ [Fig. 3] At this time, we assume that a site is assigned PA (Provider Aggregatable) address prefixes from each upstream (multi-addressing) and each upstream carries out ingress filtering on an advice of RFC2267 [2267]. In the case of 1, if the exit router has a mechanism of forwarding a packet to the proper upstream, the other nodes in the site do not have to be modified at all. In the case of 2, if the exit routers have a mechanism of forwarding a packet which should go through with another exit router to the proper exit router, the other nodes in the site do not have to be modified at all. In this draft, we will mainly discuss about the case 3. 3. Analysis of source address dependent routing solutions [HOSTS] proposes a solution that setting tunnels between site exit routers and that a site exit router forward a packet to the proper one according to its source address. With this method, each host (or each end on a host) in a multihomed site can select an upstream ISP respectively. This tunnel solution is classified as a kind of source address dependent routing (refer to the Section 4.2 of [HOSTS].) This Ohira Expires on January 19, 2005 [Page 4] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 solution need modification only on site exit routers but there is a fear that a path from a source host to a proper site exit router may not be shortest. Therefore, we pursue of a method which is good at fault tolerance and which can route an outgoing packet to a proper site exit router with shortest path even in a multi-link and multi-exit-router site. Here, we classify a multi-link and multi-exit-router site into the following two cases: a) A site exit router to an ISP (global prefix) and b) Multiple site exit routers to an ISP (global prefix.) Compared the case a with the case b, it is considered that the case b is more generalized. Therefore, we consider the case b. An example is as shown in Fig. 4. ISP A ISP B ISP A ISP B | | | | ---+------+------+------+---- ( ) ( site ) ( ) ----------------------------- Fig. 4: Multiple site exit routers to an ISP At a site as shown in Fig. 4, not only a selection which upstream ISP a packet should be goes through with but also a selection which exit router it should be go through with is needed. ISP A ISP A | | ---+-------------+----------- ( ) ( site ) ( ) ----------------------------- Fig. 5: Multiple site exit routers to the same ISP In this section, in order to gurarantee a path from a source host to a site exit router the shortest, we discuss about adding new Ohira Expires on January 19, 2005 [Page 5] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 features to either routers or hosts in a site. 3.1 Host enhancement solution As a solution that a source host selects a proper site exit router, following solutions are considered: i) IP in IP tunneling between a source host and a site exit router and ii) Using a routing option header. These solutions do not need any enhancement on routers in a site except site exit routers. Moreover, by using these solutions with tunneling between site exit routers, all hosts do not need these solutions. However, these solutions have a drawback that they need to expand the size of IP packet. These solutions request a source host to select not only an upstream ISP but also a site exit router to the ISP which go through with. 3.2 Router enhancement solution A multihomed site can be divided into 2 fields as shown in Fig. 6. Multiple site exits | | | | -----+-----+-----+-----+----- ( ) ( Source based routing domain ) ( ) ----+----+----+----+----+---- ( ) ( Generic routing domain ) ( ) ----------------------------- Fig. 6: Source based routing domain (Cited from Section 4.2 of [HOSTS]) Here, a solution that every router in the source based routing domain holds source address dependent routing policy is considered. This solution does not need any enhancement on a host in a site. Moreover, this solution does not expand the size of an IP packet. Ohira Expires on January 19, 2005 [Page 6] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 However, for effectiveness, it is preferable that the most part of a site is source based routing domain. In other words, the most routers of the site are required to be enhanced. This may become a drawback of this solution. With this solution, a source host can select an upstream ISP and/or a site exit router to the ISP which go through with. 4. Proposed solution In order to solve issues described at the previous section, we propose the following method. 4.1 Network topology and Hierarchical Address assignment This method is categorized into multi-addresses model. In this model, a site is delegated a prefix of PA address from each upstream. At this time, in order to be easy for a site to construct dynamic network: o The length of the prefix which an ISP delegates to a site is equal to or less than 48. A site exit router advertises to the all nodes in the site: o Delegated prefix(es) and o Information that this exit router is proper one for packets with such prefixed address as source address. In order to advertise, RR (Router Renumbering) [2894], DHCPv6 [3315] Prefix Option [3633] and/or RA (Router Advertisement) [2461] may be useful. An usual configuration is as below. o Upper n bits: Global prefix or some temporary "site-local" prefix such as Unique Local IPv6 Unicast Address [LOCALADDR]. o Middle m bits: With manual configuration or auto configuration such as zeroconf [2462, STATELESS], REQUIRED to complete configurations independently of the upper n bit. o Lower 128-n-m bits: Node identifier. Where n and m are in conformity with the definition in RFC3513 Ohira Expires on January 19, 2005 [Page 7] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 [3513]. As for an issue of association between an address assignment and the SADR in a site, see [MULTILINK]. 4.2 Route Selection With an usual method, routing information inside of a multihomed site depends on that of outside, then there are some problems: o A node in the site has to trust the unreliable information. o When a connection between site exit router and upstream fails, it spends a few minutes to recover (some connections may timeout). In our proposing method, o In a site, route information of only inside of the site is advertised. o Route information about outside of the site is only default route in order to rely on the least information about outside. In order to select the proper exit router, nodes SHOULD refer the source address of a packet bound for the outside of the site. In other words, o Source Address Dependent Routing (SADR) SHOULD be done for default route entries. In our method, an external route is expressed as a connection to the "next-hop" upstream. Therefore, this information is reliable as information about inside of the site. Besides, because the whole (or a part of) information about connections to upstream is advertised to all nodes in the site and a node (or an application running on the node) can select or change its source address, a more rapid change routes is expected. 4.3 Site Exit Selection In the section 3, we discussed about solutions that a source host selects a site exit router depending on a source address and that a path from the source host to the exit router is the shortest one. In the case of Fig. 5, it is difficult to make some rule whether exit router to go through with only from source address. Therefore, a solution which does not require a host to select a site exit router than a solution which requires. Ohira Expires on January 19, 2005 [Page 8] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 In other words, a selection which upstream ISP to go through with should be done by a source host but a selection which exit router to go through with to the ISP should be done by routing mechanism in the site. As for this, this draft proposes a solution that all routers in a site carry out source address dependent routing (SADR.) With the proposed solution, even a legacy host can send a packet to a proper site exit router with the shortest path. The proposed solution requires site exit routers and routers around site exit (details is described in 4.3.1) to enhance. Because of it, it may seem difficult to apply a site as a short term solution. However, because this solution is able to be adopted gradually, this solution can be a candidate of long term solutions. Conventionally, a source address dependent routing is considered to have some drawbacks as below: 1) A packet forwarding may be looped, 2) The size of routing table at a router may become too large and 3) Massive re-engineering of routers and routing protocol may be needed. We show that these anxiety are disappeared by limiting the target routes of source address dependent routing in 4.3.1, 4.3.2 and 4.3.3 respectively. Therefore, a source address dependent routing becomes a solution which can be used at small site. 4.3.1 Avoidance of packet forwarding loop At a site as shown in Fig. 6, source based routing domain must not be discrete. This is because the following reason. In a site with discrete source based routing domains as shown in Fig. 7, when a host in generic routing domain send a packet and the packet reaches at the left hand side of source based routing domain, if the proper site exit router is in the right hand side of source based routing domain, then the packet is forwarded around the border between the left hand side of source based routing domain and generic routing domain until TTL becomes 0. Ohira Expires on January 19, 2005 [Page 9] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 Multiple site exits | | | | -----+-----+---- ----+-----+----- ( Source based ) ( Source based ) ( ) ( ) ( routing domain ) ( routing domain ) ----+----+----+--------------+----+----+---- ( ) ( Generic routing domain ) ( ) -------------------------------------------- Fig. 7: A discrete source based routing domains However, even if there are some physically discrete source based routing domains in a site, if these domains are logically connected with tunnels, the problem described above is not occurred. Multiple site exits | | | | -----+-----+---- ----+-----+----- ( Source based ) tunnel ( Source based ) ( )----------( ) ( routing domain ) ( routing domain ) ----+----+----+--------------+----+----+---- ( ) ( Generic routing domain ) ( ) -------------------------------------------- Fig. 8: Concatenated source based routing domains with a tunnel Here, it should be noted that this tunnel itself goes through with the generic routing domain, so that an capsuling packet itself is routed according with the destination address of it. 4.3.2 Suppression of the amount of routing information The purpose of this solution is forwarding a packet for a host which is outside of a site from a source host to a proper site exit router according to the source address of the packet through the shortest path. Based on the discussion in 4.3.1, even in the source based routing Ohira Expires on January 19, 2005 [Page 10] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 domain, a packet which destination is inside the site must be routed source address independently. A small site seems hardly to get detailed routing information about outside of the site and the site exit router mostly gets only the information about the address of counter router in an upstream ISP as the default gateway of the site. Moreover, the site is not considered to transit any traffic between two third parties. Therefore, a limitation route outside of the site to default route does not seem to occur any special problems. This draft proposes to limit route outside of the site to default route (dst=::/0) and to apply source address dependent routing only for default route entry. These are useful to suppress the amount of routing information. If a site exit router gets detailed routing information about outside of the site, it can be used as base information of source address selection by a source host. However, this issue is outside of the scope of this draft. 4.3.3 Suppression of impact on a router or a routing protocol This proposed solution can be carried out without any change of packet format of routing information advertised within a site. Especially in a link state routing protocol such as OSPF, because routing information is not merged normally, information about multiple default routes can be announced in a site respectively. In a distance vector routing protocol such as RIP, routing information about the same destination is merged. Therefore, when a site exit router announces a default route within the site, the destination of each information should not be as the same kind (like ::/0) but should be different for each global prefix assigned by an upstream ISP. An example is described in Appendix B. However, as in a link state routing protocol, the packet format of routing information does not need any changes. In this case, it is considered that each default route entry is expressed as 'the whole address space which a site is assigned from an ISP.' As explained above, the format of routing information does not need any change. All what is required is that a router which received information about default route should hold default route information for each global prefix respectively. In order to carry out it, enhancement to every router to keep default Ohira Expires on January 19, 2005 [Page 11] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 route information for each global prefix respectively or not to merge information about default route is required. An implementation of this solution is described in Appendix A. 5. Evaluation of this proposal and multihoming goals In this section, we will evaluate how much our proposing method meets the requirements pointed out in RFC3582 [3582]. 5.1 Capabilities of IPv4 Multihoming 5.1.1 Redundancy Every external connection is treated completely separate. Therefore, our proposing method is able to continue a connection unless all external connection fail. 5.1.2 Load Sharing Each end of transport layer is able to distribute both inbound and outbound traffic between multiple transit providers. (cf. In host centric multihoming, each host is able to distribute.) 5.1.3 Performance No information between upstream ISPs is REQUIRED. If a corresponding node can divide a stream into several destination addresses, we can accomplish to distribute inbound traffic. 5.1.4 Policy Policies of a site will be expressed as ingress/egress filtering rules. If a site does not want a host to use an external connection, the site can neglect to re-delegate an address with the prefix specific to the external connection. 5.1.5 Simplicity Our proposing method is very simple. In the simplest case, we may be able to configure with only one command or jumper switch. Ohira Expires on January 19, 2005 [Page 12] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 5.1.6 Transport-Layer Survivability With the method described in the section 3, we can select a route to use from several candidates. At a point of view of an application, we expect that all messages are exchanged in just one connection. In order to meet this requirement, we need some co-operation with L4 (for UDP, it may be L7). There are two approaches as below: o Define an intermediate layer between the transport layer and IP layer. In this approach, the intermediate layer merges several IP addresses into one transport layer address, so a transport layer protocol thinks that an unchanged connection continues. o Transport layer protocol itself directly handles multiple IP addresses. As an intermediate layer, LIN6 [LIN6], HIP [HIP, HIP-MM], MAST [MAST], SIM [SIM] and etc. are proposed. In order to bind several IP address to a TCP connection, the TCP extension to multihome [TCP-MH] is proposed. SCTP [SCTP, SCTP-MH] can handle several IP addresses in an association. A connection between a node and another node may have several paths (i.e. several pairs of source/destination addresses). Decision of priority of these pairs SHOULD be done in L4/L7 with following the rules described in RFC3484 [3484]. However, these methods are both disputable about how to hold binding relation and its security issues. 5.1.7 Impact on DNS Any change of external connections of a site cause change(s) of prefixes which the site has. Therefore, in the worst case, we may be required to change DNS information at every time. 5.1.8 Packet Filtering Our proposing method is designed to co-operate with ingress/egress filtering. If the source address of an IP packet is valid then the packet is forwarded to the proper next hop, otherwise the packet will Ohira Expires on January 19, 2005 [Page 13] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 be discarded. 5.2 Additional Requirements 5.2.1 Scalability Only a Provider Aggregatable IP address block from upstream is REQUIRED. This address is always aggregated at upstream, so even if the number of multihoming site with our proposing method increase, the number of routing information at DFZ (Default Free Zone). Still more, no AS number is REQUIRED for a site to be multihomed. In these points, our proposing method is very scalable. 5.2.2 Impact on Routers The SADR is REQUIRED for at least one router in a multihoming site. If there are some routers which cannot handle SADR, according to the position, routing loop may be occurred. The authors think that this requirement is relatively little because the SADR is required only for default route entry. These modifications do not prevent normal single-homed operations. In a single-homed site, modified routers and unmodified routers can coexist. 5.2.3 Impact on Hosts The SABR is REQUIRED for all end hosts who want to be fully multihomed. However, a legacy (without SADR) host can be obtain some functions of multihome. If you want to bind several IP addresses to a single TCP connection, TCP Extension for Multihoming may be useful. 5.2.4 Interaction between Hosts and the Routing System No interactions are REQUIRED except for information about proper next hop for each source address prefixes. 5.2.5 Operations and Management Ohira Expires on January 19, 2005 [Page 14] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 Administrators of a site are completely capable to monitor the state or to configure parameters of multihoming. At this time, the administrators do not have to do any co-operative work with administrators of upstream. 5.2.6 Cooperation between Transit Providers Our proposing method does not require any co-operative work between upstream providers at all. 5.2.7 Multiple Solutions In a single network segment, our proposing method is RECOMMENDED to be used solely. However, we can divide the site into two or more segment in order to use those multiple solutions respectively. 6. Things multi6 developers should think about In this section, we will evaluate our proposing method at the point of questions described in [THINKABOUT]. 6.1 On the wire behavior 6.1.1 How will your solution solve the multihoming problem? Put source address dependent routing policy on every router in a site. 6.1.2 At what layer is your solution applied, and how? At the layer 3. The proposal is applied in every packet. The source address field is used. 6.1.3 Why is the layer you chose the correct one? Because this proposal only relates to the issue of packet forwarding from a source host to a proper site exit router according to the source address of the packet. 6.1.4 Does your solution address mobility? Ohira Expires on January 19, 2005 [Page 15] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 No. This proposal is orthogonal to MOBILEIP-V6. 6.1.5 Does your solution expand the size of an IP packet? No. 6.1.6 Will your solution add additional latency? No. 6.1.7 Can multihoming capabilities be negotiated end to end during a connection? No. 6.1.8 Do you change the way fragmenting is handled? N/A. 6.1.9 Are there any layer 2 implications to your proposal? No. 6.2 Identifiers and locators N/A. 6.3 Routing system interactions 6.3.1 Does your solution change existing aggregation methods? No. 6.3.2 If you introduce any new name spaces, do they require aggregation? No. 6.3.3 Are there any changes to ICMP error semantics? Ohira Expires on January 19, 2005 [Page 16] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 No. 6.4 Name service interactions N/A. 6.5 Application concerns and backward compatibility 6.5.1 What application/API changes are needed? No change is needed. 6.5.2 Is this solution backward compatible with "old" IP version 6? An user of a normal IPv6 node may receive an ICMP redirect message. 6.5.3 Is your solution backward compatible with IPv4? This proposal is orthogonal to 6to4 gateways. This mechanism does not consider IPv4. 6.5.4 Can IPv4 devices take advantage of this solution? Yes. 6.5.5 What is the impact of your solution on different types of sites? Single homed sites: No impacts. Small multihomed sites: The main target of this proposal. Source address dependent routing policy on each router in a site. Large multihomed sites: May prefer another solution. Ad-hoc sites: Not preferable. Short lived connections: No impacts. 6.5.6 How will your solution interact with other middleboxes? Ohira Expires on January 19, 2005 [Page 17] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 We do not use any middlebox. 6.5.7 Referrals This proposal does not make it worse. 6.6 Legal concerns N/A. 7. Security Considerations This proposal does not introduce any new kind of messages. Therefore, the authors think this proposal make it less secure than the current situation. 8. IANA Considerations There are no IANA considerations in this document. 9. Acknowledgements The authors thank Mr. Arifumi Matsumoto who grants us permission to publish an implementation of SADR for default route entry. The downloads page of the implementation is noted at Appendix A. Appendix A: Implementations of SADR for default route entry SADR for default route entry can be put in practice with some extensions of policy routing. We can get it with ipfilter (ipf,) and we have another implementation of extended ECMP which runs on NetBSD (KAME.) The implementation of extended ECMP is now available at http://www.rd.miako.net/~arifumi/ietf/kame-20031020-netbsd161- ecmpsabr.diff. Appendix B: An expression of a default route at a distance vector routing protocol Ohira Expires on January 19, 2005 [Page 18] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 For example, a site is assigned an address space A::/48 from the ISP A and an address space B::/48 from the ISP B. In this case, a site exit router a which is connected to the ISP A announces routing information of dst=A::/48 within the site with distance vector routing protocol such as RIP. If all routers in the site know that the site is assigned A::/48 beforehand, at a router which receive the above information can recognize that the information must be treated as the default route in the site. The same is true in B::/48. By using this replacement expression, even with DV routing, multiple default routes can be announced in demultiplexable style. Here, the reason why A::/48 and B::/48 are used as alternative expression of ::/0 is that they are never used in the site because of longest match rule of routing information. References [3582] J. Abley, et. al., "Goals for IPv6 Site-Multihoming Architectures", RFC3582, August 2003. [SCTP-MH] L. Coene, et. al., "Multihoming: the SCTP solution", Internet Draft (work in progress), draft-coene-multi6-sctp- 00.txt, January 2004. [2894] M. Crawford, "Router Renumbering for IPv6", RFC2894, August 2000. [MAST] D. Crocker, "Multiple Address Service for Transport (MAST): An Extended Proposal", Internet Draft (work in progress), draft-crocker-mast-proposal-01.txt, September 2003. [3484] R. Draves, "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC3484, February 2003. [3315] R. Droms, Ed., et. al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC3315, July 2003. [2267] P. Ferguson, et. al., "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC2267, January 1998. [LOCALADDR] R. Hinden, et. al., "Unique Local IPv6 Unicast Address", Internet Draft (work in progress), draft-hinden-ipv6- Ohira Expires on January 19, 2005 [Page 19] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 global-local-addr-02.txt, June 2003. [HOSTS] C. Huitema, et. al., "Host-Centric IPv6 Multihoming", Internet Draft (work in progress), draft-huitema-multi6- hosts-03.txt, February 2004. [ARCHITECTURE] G. Huston, "Architectural Approaches to Multi-Homing for IPv6", Internet Draft (work in progress), draft- ietf-multi6-architecture-00.txt, July 2004. [THINKABOUT] E. Lear, "Things MULTI6 Developers should think about", Internet Draft (work in progress), draft-ietf-multi6- things-to-think-about-00.txt, June 2004. [TCP-MH] A. Matsumoto, et. al., "TCP Multi-Home Options", Internet Draft (work in progress), draft-arifumi-tcp-mh-00.txt, October 2003. [HIP] R. Moskowitz, et. al., "Host Identity Protocol", Internet Draft (work in progress), draft-moskowitz-hip-09.txt, February 2004. [2461] T. Narten, et. al., "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461, December 1998. [HIP-MM] P. Nikander, et. al., "End-Host Mobility and Multi-Homing with Host Identity Protocol", Internet Draft (work in progress), draft-nikander-hip-mm-02.txt, July 2004. [SIM] E. Nordmark, "Strong Identity Multihoming using 128 bit Identifiers (SIM/CBID128)", Internet Draft (work in progress), draft-nordmark-multi6-sim-01.txt, October 2003. [MULTILINK] K. Ohira, et. al., "Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address Model Multi-Link Multihoming Site", Internet Draft (work in progress), draft-ohira-multi6-multilink-auto-prefix-assign-00.txt, January 2004. [SCTP] R. Stewart, et. al., "Stream Control Transmission Protocol", RFC2960, October 2000. [LIN6] F. Teraoka, et. al., "LIN6: A Solution to Multihoming and Mobility in IPv6", Internet Draft (work in progress), draft- teraoka-multi6-lin6-00.txt, December 2003. [2462] S. Thomson, et. al., "IPv6 Stateless Address Autoconfiguration", RFC2462, December 1998. Ohira Expires on January 19, 2005 [Page 20] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 [3633] O. Troan, et. al., "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC3633, December 2003. [STATELESS] T. Yoshihiro, et. al., "Stateless Autoconfiguration of IPv6 Site-Local Address." Communications and Computer Networks pp.. 299--304, IASTED (2002) Authors' Addresses Kenji Ohira Graduate School of Informatics Kyoto University Yoshida-Hommachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81-75-753-7468 Fax: +81-75-753-7472 Email: ohira@net.ist.i.kyoto-u.ac.jp Masahiro Kozuka Faculty of Law, Kyoto University Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81 75-753-7468 Fax: +81 75-753-7472 Email: ma-kun@kozuka.jp Yasuo Okabe Academic Center for Computing and Media Studies Kyoto University Yoshida-Hommachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81-75-753-7458 Fax: +81-75-751-0482 Email: okabe@i.kyoto-u.ac.jp Youichi Koyama Trans New Technology, Inc. Inohara BLDG. 2F, 72 Tanaka Monzencho, Sakyo, Kyoto 606-8225 JAPAN Tel: +81-75-706-9800 Fax: +81-75-706-9801 Email: koyama-y@trans-nt.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in Ohira Expires on January 19, 2005 [Page 21] draft-ohira-assign-select-e2e-multihome-03.txt July 19, 2004 this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ohira Expires on January 19, 2005 [Page 22]