INTERNET DRAFT M. Ohta draft-ohta-e2e-multihoming-05.txt Tokyo Institute of Technology June 2003 The Architecture of 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 This memo describes the architecture of end to end multihoming. End to end multihoming does not burden routing system for multihoming. That is, even extensive use of end to end multihoming does not increase the number of entries in a global routing table. Traditionally with IPv4, multihoming capability is offered by an intelligent routing system, which, as is always the case with violating the end to end principle, lacks scalability on a global routing table size and robustness against link failures. On the other hand, with end to end multihoming, multihoming is supported by transport (TCP) or application layer (UDP etc.) of end systems and does not introduce any problem in the network and works as long as there is some connectivity between the end systems. Because end to end multihoming is performed in end systems, the architecture needs no routing protocol changes Instead, APIs and applications must be modified to some extent. M. Ohta Expires on December 30, 2003 [Page 1]
INTERNET DRAFT End to End Multihoming June 2003 Table of Contents 1. Introduction 2. Multihoming by Intelligent Routing System is Harmful 2.1 Routing Table Size 2.2 Lack of Robustness 3. The Problems of Current Routing Architecture 4. Modifications on APIs and Applications 5. Policy Control, the Number of TLAs and ISPs 5.1. BGP Policy Control 5.2. Limiting the Number of TLAs. 6. A Design Framework of End to End Multihoming 6.1. 8+8 6.2. DNS 6.3. Location Agents 7. Conclusions 8. Security Considerations 9. Author's Address 1. Introduction Multihoming is a way for hosts have robust connectivity to the Internet. For IPv6, multihoming is more important, because the number of TLAs (Top Level Aggregators) is limited and most ISPs will operate at NLA (Next Level Aggregator) level. NLA level ISPs (NLIs) will, naturally, be multihomed to TLA level ISPs (TLIs), because robustness is essential to ISP operations. Traditionally with IPv4, multihoming has been offered through intelligence of routing system, that is, the end to end principle has been ignored. However, as discussed in section 2, with the explosive deployment of the Internet, as is always the case with intelligent networking, IPv4 style multihoming was revealed its lack of scalability and robustness. Instead, multihoming should be supported based on the end to end principle by assigning multiple addresses to an interface of a host and let end systems choose an appropriate address at the transport or the application layer. To support the end to end multihoming, no change is necessary on routing protocols. Instead, APIs and applications must be modified to detect and react against the loss of connection. In case of TCP where there is a network wide defact agreement on the semantics (timeout period) of the loss of connectivity, most of the work can be done by the kernel code at the transport layer, though some timing M. Ohta Expires on December 30, 2003 [Page 2]
INTERNET DRAFT End to End Multihoming June 2003 may be adjusted for some application. However, in general, the condition of "loss of connectivity" varies application by application that the multihoming must directly be controlled by application programs. As the end to end multihoming handles multiple address of hosts, reachability of which changes dynamically, it is natural that mobility is an integral part of the end to end multihoming. With original IPv6 specification, there is a partial effort of end to end multihoming that it is of course that an interface has multiple addresses. However, because the principle of the end to end multihoming is recognized merely subconsciously and because the current routing architecture violates the end to end principle in various ways as a result of partial attempt to avoid the lack of scalability of routing table size, there are a lot of attempts: to keep the APIs and application programs as is to modify routing system intelligent to let it automatically offer end to end multihoming which makes IPv6 multihoming as bad as that of IPv4. Worse, mobility is developed mostly independent to base IPv6 specifications. This memo describes why multihoming by intelligent routing system is harmful, how the current routing architecture is damaged by the network intelligence, how the ends (hosts, APIs of hosts, applications on hosts) should be modified to implement the end to end multihoming and how intermediate systems (routers and other ISP equipments) are still unaffected how the mobility is integrated with the end to end multihoming. 2. Multihoming by Intelligent Routing System is Harmful 2.1 Routing Table Size IPv4 style multihoming consumes a global routing table entry for each multihomed entity that it is becoming a serious scalability problem. See IAB Network Layer Workshop for details. 2.2 Lack of Robustness M. Ohta Expires on December 30, 2003 [Page 3]
INTERNET DRAFT End to End Multihoming June 2003 With route aggregation, routing information can be carried only for an aggregated area that a loss of connectivity for a part of the area can not be detected. For example, if a multihomed site with multiple subnets has a single global routing table entry, and if a site is partitioned, only a part of the site can be reached with the global routing table entry. The problem become worse, if a multihomed ISP is partitioned. A none solution is to let all the subnets of the site (or, ultimately, hosts) individually have global routing table entry, scalability of which is so absurd that no one bothers to try. 3. The Problems of Current Routing Architecture End systems (hosts) are end systems. To make the end to end principle effectively work, the end systems must have all the available knowledge to make decisions by the end systems themselves. With regard to multihoming, when an end system want to communicate with a multihomed end system, the end system must be able to select most appropriate (based on the local information) destination address of the multihomed end system. However, some think it of course to separate routers and nodes and let hosts not have routing information (which means the current IPv6 architecture is broken) and, worse, let most routers use default routes. With detailed route information, end systems can use the information as a hint to select the best destination address. However, with default route, end systems have no idea on what is the best address and must blindly try all the possibilities at random. It was partly because full routing table was large and was not be able to be held in a chip on end systems and partly because hosts should not be affected by routing protocol changes. In the past, IPv4 address was not assigned with hierarchy and scale of integration was small. But, with smaller full routing table and larger scale of integration, there is no reason not to have full routing table on every end system. As there are a lot of routers used in LAN or even in home, it is not so meaningful that we don't have to upgrade software on hosts, if we M. Ohta Expires on December 30, 2003 [Page 4]
INTERNET DRAFT End to End Multihoming June 2003 have to upgrade software on routers. The situation is worse with multicasting. For example, IGMP, which separates routers and nodes, is a total nonsense as IGMP has been revised several times upon multicast routing protocol changes. Moreover, all the legacy multicast routing protocols use intelligent routing system to deliver group specific information and does not scale. Multicast architecture must be redone with the end to end principle in mind. SM (Static Multicast) proposed by the Authors is such a proposal but latter proposals (such as "simple multicast" or "AS based static allocation") modified it without understanding the underlying end to end principle and are useless. Once a full routing table is available on all the end systems, it is easy for the end systems try all the destination addresses, from the most and to the least favorable ones, based on the routing metric. Note that end to end multihoming works with the separation between inter domain BGP and intra domain routing protocols, if BGP routers, based on local policy of the domain, assign external routes preference values (metric) of intra domain routing protocols. One may still be allowed, though discouraged, to have local configuration with dumb end systems and an intelligent proxy. But, such configuration should be implemented with a protocol for purely local use without damaging the global protocol. 4. Modifications on APIs and Applications With TCP, applications must be able to pass multiple addresses to transport layer (e.g. BSD socket). All the other processing can be performed by transport layer (typically in kernel) using default or application specific timing of TCP. TCP itself must be modified that all the possible addresses of a host is transmitted to its peer through a TCP option. TCP option length limitation should be loosened reflecting the larger MTU of IPv6. TCP connections are identified with all the addresses constitute an identical connection. Without TCP, applications must be able to detect loss of connectivity in application dependent way and try other addresses by themselves or tell transport layer to do so. Applications must still be able to pass multiple addresses of the destination to transport layer (e.g. BSD socket) to receive a packet to alternative addresses sent from the other end of the communication. The easiest way for applications know all the addresses of the M. Ohta Expires on December 30, 2003 [Page 5]
INTERNET DRAFT End to End Multihoming June 2003 destination is to use DNS. With DNS reverse, followed by forward, lookup, applications can get a list of all the addresses of the destination from an address of the destination. Note that policy based selection of a source address is incompatible to the end to end principle, because it must be selected as the destination address by the policy of the other end of the communication using information local to the other end of the communication. With so much asymmetric routing of the Internet today, proper destination address to reply can not be guessed by the querier. Thus, DNS query should be modified to carry all the addresses of clients and servers should try from the most favorable to the least ones, based on locally available information such as metric in intra domain full routing table. Any source address may be selected. However, to enable source address filtering to discard packets with source addresses not belonging to an ISP, it is useful to enable a host, not some intelligent intermediate router, select a source address compatible with an outgoing ISP. For that purpose, intra domain routing protocols or something like that should maintain routing table entries with not only preference values of an external routes, but also proper prefixes to be selected for source addresses, if the entries are chosen by a host. With DNS, it is also required that DNS reverse lookup works properly. But, as the reverse lookup is the mechanism to delegate IP addresses, the requirement is no more demanding than assigning valid IP addresses. A problem is that a locally scoped address (IPv6 link and site local addresses) can not be used for reverse look up. Use of 8+8 addressing proposed by one of an Author with globally unique IID (Internet ID) and ILOC (Internet Locator) is strongly encouraged. With 8+8 addressing, DNS reverse lookup can be performed with IID part only. Note that 8+8 proposal must not be confused by latter proposal of routing goof (GSE) by Mike O'dell, which is a proposal to use intelligent routers to rewrite source addresses to prevent source address spoofing and to tunnel between intelligent routers for pseudo multihoming, both of which are against the end to end principle and, thus, lacks robustness and/or scalability. 5. Policy Control, the Number of TLAs and ISPs M. Ohta Expires on December 30, 2003 [Page 6]
INTERNET DRAFT End to End Multihoming June 2003 TLAs will be used to control global policy. But, not so many entities needs to control it. Considering that some people has been arguing to have 4 byte AS numbers, the number of ISPs will grow indefinitely. Moreover, sites wanting to have IPv4 style multihoming may pretend to be ISPs. The end to end principle does not distinguish sites and ISPs. So, it is natural to think ISPs multihomed to other ISPs. But, most of such ISPs needs to control policy locally that they don't need TLAs. On the other hand, having small number of TLIs will make full routing table small that it can be expected that most hosts has full routing table, reducing the problems with destination and source address selection. An obvious solution is to have layers of ISPs, as was specified in IPv6 to have TLA (Top Level Aggregator) and NLA (Next Level Aggregator) that they can be allocated to TLIs (Top Level ISPs) and NLIs (Next Level ISPs, correspondingly. It is expected that NLIs have multiple prefixes each belonging to multiple TLAs, all of which is delegated to sites. 5.1. BGP Policy Control BGP Policy is controlled by identifying ISPs not by address prefix but by AS numbers. Thus, a next level ISP not having its own TLA can still fully control its policy. Moreover, neighbor ISPs can adjust their policy using the full prefix of the ISP. However, to limit the size of global routing table, an AS and prefixes of the next level ISP at the distance must be discarded or merged with its TLA. But, it is better than a current multihoming practice that prefix of a multihomed site is propagated locally to give robustness against local failures, because multiple TLAs give robustness against global failures. M. Ohta Expires on December 30, 2003 [Page 7]
INTERNET DRAFT End to End Multihoming June 2003 Thus, it is not so essential for most ISPs that they have their own TLAs. The exception should be those ISPs so called tier1. 5.2. Limiting the Number of TLAs. There should be hard upper bound on the number of TLAs in the Internet. For example, some TLA may be supplied from RIRs with bidding. Some TLA may be allocated to each country (proportional to the population of the country) and delivered with the country's policy. The proper number of TLAs should be larger than the number of countries (the political entities) and a lot larger than the number of tier1 (whatever the definition might be) ISPs. Thus, it seems to the author, that the upper bound on the number of TLAs should be somewhere between 1024 and 8192. 6. A Design Framework of End to End Multihoming In this section, a design framework of end to end multihoming is discussed. 6.1. 8+8 16 bytes of addresses of an IPv6 host are separated into locators and IDs. The separation is handy to identify connections and is useful to keep them connecting, even if IP addresses of a host changes and notification packets of the changes are lost. An locator is upper 8 byte of an address to route a packet to a subnet of the host. A host in a multihomed site in a single homed site connected to a multihomed NLI will have multiple locators. There should be maximum number (9?) of locators a host can reasonably have. There should be maximum number (3?) of locators an ISP can reasonably have. An ID is lower ID of an address to identify a host. A packet is received by a host, if the ID part matches that of a host. A host may have multiple IDs, though packets of a connection must use a single source and destination ID. To make the 8+8 addresses coexists with existing IPv6 addresses, 8+8 M. Ohta Expires on December 30, 2003 [Page 8]
INTERNET DRAFT End to End Multihoming June 2003 addresses are identified by its ID part having same syntax of MAC- derived address but with group bit set and local bit reset. For the compatibility of existing hosts, multihomed hosts should behave so if and only if its peer has 8+8 address. 6.2. DNS DNS is used to map ID of a host to hostname (reverse look up), hostname to an 8+8 address, which is a combination of a locator of location agents of the host and ID of the host. 6.3. Location Agents Location agent of a host is a server maintaining a list of current locators of the hosts. A host should register its locations to its location agents. Before communicating, a host may asks a location agent of its peer to know the current locator of the peer and send packets. Or, a location agent of a host may temporarily accept and relay (modifying destination locator) packets to the host. If a set of locator of a host changes during connection, its peer is notified about the change. The feature is useful not only for mobility but also for deprecating some addresses during gradual ISP change, which should not be called "automatic renumbering" as DNS must still be reconfigured by hand. There should be strong security between a host and its mapping agents with shared secret based authentication. There should be cookie-based weak security for a host authorize changes of locators of its peer. For an immobile host, the host may act as a mapping agent of the host itself, in which case, there is no strong security necessary. 7. Conclusions For robust and scalable multihoming, IPv6 separation of nodes and routers must be removed and the transition to the end to end multihoming should occur with the transition to IPv6. The modification is not so difficult, because most of the applications, which must be modified for IPV6 anyway, use TCP only M. Ohta Expires on December 30, 2003 [Page 9]
INTERNET DRAFT End to End Multihoming June 2003 and most of the UDP applications are DNS, which already tries all the addresses, or multicast capable ones, which are hopeless. One may argue that we can't further delay the transition to IPv6 merely because of a random proposal on multihoming. Then, it is a good idea to start another transition, separated from ones with legacy IPv6, by allocating a new address prefix of IPv6 address space for the end to end multihoming with 8+8 addressing, which can be dualstacked to communicate with legacy IPv6 hosts. It is important to make the end to end principle work by keeping the number of top level routing prefix under the new address prefix small by having NLIs. It should be noted that, because of the end to end nature, the architecture can be implemented purely on end systems without modifying routing functionality of existing IPv4 or IPv6 routers. 8. Security Considerations The author believes there is no special security concern on the architecture itself. Security with location agents are discussed briefly in section 6.3. 9. Author's Address Masataka Ohta Graduate School of Information Science and Engineering Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3299 EMail: mohta@necom830.hpcl.titech.ac.jp M. Ohta Expires on December 30, 2003 [Page 10]