INTERNET-DRAFT K. Ohira October 27, 2003 K. Ogata A. Matsumoto K. Fujikawa Y. Okabe Kyoto University Y. Koyama Trans New Technology IPv6 Address Assignment and Route Selection for End-to-End Multihoming Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract In this document, we propose a way of address assignment and route selection suitable for "Host-Centric" or "End-to-End" multihoming, where an end node plays the main role of multihoming. The key techniques are a hierarchical address assignment and a source address based routing (SABR) for only default route entry. In our proposal, an IP address itself has some sense of routing Ohira Expires on April 27, 2004 [Page 1] draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003 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 he also hands routing information to his 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 [REQ], the main purpose of multihoming is getting redundancy and sharing a load. 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" [M6H] or "End-to-End" [E2E] 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 [REQ]. The term "site" means the small site and it is assumed as a home network. In the section 5, we will deal with so-called "Large site". 2.2 Network Topology of a Site A site can be classified into the following 3 cases: 1. single link, single exit router (fig. 1), 2. single link, multiple exit routers (fig. 2) and Ohira Expires on April 27, 2004 [Page 2] draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003 3. multiple link, multiple exit routers (fig. 3). | | | | | | +-----+ +-----+ +-----+ | | | | | | +-----+ +-----+ +-----+ | | | ----+-+------ ------+-----+------+------ | | +-----+ +-----+ | | | | +-----+ +-----+ [fig. 1] [fig. 2] | | | | +-----+ +-----+ | | | | +-----+ +-----+ | | ---+--+---- ----+--+--- | | +-----+ +-----+ | | | | +-----+ +-----+ | | ---+--------+---------+--- | +-----+ | | +-----+ [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 [NIF]. 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. Ohira Expires on April 27, 2004 [Page 3] draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003 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 the case of 3, a tunnel between exit routers makes exit routers virtually on one link, so a method used in the case 2 is available. This tunnel method has an advantage that it requires no modification except on site exit routers. However, with this method, according to the position of a host and exit routers, a packet may go through with uselessly long path. Moreover, in this method, an exit router has to know addresses of the other routers in advance and these tunnels should be fully-meshed among all exit tunnels. 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. In order to solve these issue, we propose the following method. 3. Proposed solution 3.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) [RRN], DHCPv6 Prefix Option [DHC] and/or RA (Router Advertisement) [NDC] may be useful. The initial configurations are as below. o Upper 48 bits: Some temporary "site-local" prefix such as Unique Local IPv6 Unicast Address [UQL]. o Middle 16 bits: With manual configuration or auto configuration Ohira Expires on April 27, 2004 [Page 4] draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003 such as zeroconf [ZCF,SLA], REQUIRED to complete configurations independently of the upper 48bit. o Lower 64 bits: Node identifier. 3.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 have 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 Based Routing (SABR) 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, more rapid change routes is expected. 4. Evaluation of our solution In this section, we will evaluate how much our proposing method meets the requirements pointed out in RFC3582 [REQ]. 4.1 Capabilities of IPv4 Multihoming 4.1.1 Redundancy Every external connection is treated completely separate. Ohira Expires on April 27, 2004 [Page 5] draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003 Therefore, our proposing method is able to continue a connection unless all external connection fail. 4.1.2 Load Sharing A site is able to distribute both inbound and outbound traffic between multiple transit providers. 4.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. 4.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. 4.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. 4.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. Ohira Expires on April 27, 2004 [Page 6] draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003 o Transport layer protocol itself directly handles multiple IP addresses. As an intermediate layer, LIN6 [LIN,L6A], HIP [HIP], MAST [MAS], SIM [SIM] and etc. are proposed. In order to bind several IP address to a TCP connection, the TCP extension to multihome [MHO] is proposed. SCTP [SCT] 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 [DAS]. However, these methods are both disputable about how to hold binding relation and its security issues. 4.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. 4.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 be discarded. 4.2 Additional Requirements 4.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. 4.2.2 Impact on Routers Ohira Expires on April 27, 2004 [Page 7] draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003 The SABR is REQUIRED for at least one router in a multihoming site. If there are some routers which cannot handle SABR, according to the position, routing loop may be occurred. The authors think that this requirement is relatively little because the SABR 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. 4.2.3 Impact on Hosts The SABR is REQUIRED for all end hosts who want to be fully multihomed. However, a legacy (without SABR) 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. 4.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. 4.2.5 Operations and Management 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. 4.2.6 Cooperation between Transit Providers Our proposing method does not require any co-operative work between upstream providers at all. 4.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. Ohira Expires on April 27, 2004 [Page 8] draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003 5. Applying for ``Large Site'' In the former sections, we assume that the network is 2-level: a site and the outside of the site. However, this 2-level relation is extensible to multi-level. This extension may be useful when we apply our method to a so-called "Large Site". In such a case, the hierarchical relationship is: (upstream) ISP -- large site (cluster of small sites) -- small site. At this time, a large site is delegated a prefix from an ISP and delegate a sub-prefix to a small site. 6. Security Considerations A protocol of verifying identification of L4/L7 may introduce some security problems. Therefore, it is out of scope of this document. 7. IANA Considerations There are no IANA considerations in this document. 8. References [REQ] J. Abley, et. al., "Goals for IPv6 Site-Multihoming Architectures", RFC3582, August 2003. [RRN] M. Crawford, "Router Renumbering for IPv6", RFC2894, August 2000. [MAS] D. Crocker, "Multiple Address Service for Transport (MAST): An Extended Proposal", Internet Draft (work in progress), draft-crocker-mast-proposal-01.txt, September 2003. [DAS] R. Draves, "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC3484, February 2003. [NIF] P. Ferguson, et. al., "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC2267, January 1998. [UQL] R. Hinden, et. al., "Unique Local IPv6 Unicast Address", Internet Draft (work in progress), draft-hinden-ipv6-global- local-addr-02.txt, June 2003. [M6H] C. Huitema, et. al., "Host-Centric IPv6 Multihoming", Internet Draft (work in progress, expired), draft-huitema-multi6-hosts- Ohira Expires on April 27, 2004 [Page 9] draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003 01.txt, June 2002. [L6A] A. Matsumoto, et. al., "Basic Socket API Extensions for LIN6 End-to-End Multihoming", Internet Draft (work in progress), draft-arifumi-lin6-multihome-api-00.txt, June 2003. [MHO] 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-08.txt, October 2003. [NDC] T. Narten, et. al., "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461, December 1998. [SIM] E. Nordmark, "Strong Identity Multihoming using 128 bit Identifiers (SIM/CBID128)", Internet Draft (work in progress), draft-nordmark-multi6-sim-00.txt, October 2003. [E2E] M. Ohta, "The Architecture of End to End Multihoming", Internet Draft (work in progress), draft-ohta-e2e-multihoming-05.txt, June 2003. [SCT] R. Stewart, et. al., "Stream Control Transmission Protocol", RFC2960, October 2000. [LIN] F. Teraoka, et. al., "LIN6: A Solution to Mobility and Multi- Homing in IPv6", Internet Draft (work in progress, expired), draft-teraoka-mobility-lin6-00.txt, December 2000. [ZCF] S. Thomson, et. al., "IPv6 Stateless Address Autoconfiguration", RFC2462, December 1998. [DHC] O. Troan, et. al., "IPv6 Prefix Options for DHCPv6", Internet Draft (work in progress), draft-ietf-dhc-dhcv6-opt-prefix- delegation-05.txt, October 2003. [SLA] T. Yoshihiro, et. al., "Stateless Autoconfiguration of IPv6 Site-Local Address." Communications and Computer Networks pp.. 299--304, IASTED (2002) 9. Authors' Addresses Kenji Ohira Graduate School of Informatics Kyoto University Yoshida-Hommachi, Sakyo-ku, Kyoto 606-8501 JAPAN Ohira Expires on April 27, 2004 [Page 10] draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003 Tel: +81-75-753-7468 Fax: +81-75-753-7472 Email: ohira@net.ist.i.kyoto-u.ac.jp Katsuya Ogata 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: ogata@net.ist.i.kyoto-u.ac.jp Arifumi Matsumoto 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: arifumi@net.ist.i.kyoto-u.ac.jp Kenji Fujikawa Graduate School of Informatics Kyoto University Yoshida-Hommachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81-75-753-5387 Fax: +81-75-753-4961 Email: fujikawa@real-internet.org 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 Ohira Expires on April 27, 2004 [Page 11]