Internet Engeneering Task Force K. Ohira INTERNET-DRAFT K. Ogata June 30, 2003 A. Matsumoto K. Fujikawa Y. Okabe Kyoto University IPv6 Address Assingment 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 We assume that IPv6 network is hierarchical. Though the present IP network topology is not hierarchical at the point of multihoming. In this document, we clarify that a) how to assign address blocks to ISPs and sites in order to achieve multihome environment without destroying hierarchical structure of IPv6, b) requirements for end hosts in order to select an adequete route from multiple routes when multihoming. with the way which is based on so-called 'end to end multihoming' or 'host centric multihome'. Ohira Expires on December 30, 2003 [Page 1] draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003 1. Introduction Multihome is the way to make load balancing or to improve reachability. Today, the Internet becomes popular and then someone will want to get multihomed environment even if whose network is small as a home network. Still more, there are a lot of requirements for multihoming pointed out in [REQ]. It is difficult to respond to such request with present way of multihome. Further more, IPv6 address space is far wider than that of IPv4, so we have to aggregate addresses thoroughly or IPv6 fails earlier than IPv4. In this document, we explain the network topology model which we should follow and addressing policy the in that network. 2. Network topology and Hierarchical Address assignment In a current multihoming envirionment, a site needs an AS number or needs a so-called "punching hole" method in order to select a route from candidate routes. This causes explosion of routing information. We show that a site can select a preferable route even when IP addresses are hierarcically assinged. Hierarchical IP address assignment suppresses the explosion of routing information. We will construct our multihoming model based on the "end to end multihoming" ([E2E]). Note that end to end multihoming and host centric multihoming is the same in terms of address assignment. As described in [M6H], source address based routing allows for a large diversity between the site exits. It also allows for host based policy decision, since a host can influend the routing of a packet by choosing the appropriate source address. So, we use source address based routing for this purpose. In [M6H], an example of two level hierarchical structure that a site obtain prefixes from the ISPs whom the site subscribes to is shown. This time, we should assign hierarchical addreses to those networks in order to aggregate addresses and in order to express that what ISP a certain site belongs to. ~~~~~~~ ( ) BGP cloud ~~~~~~~ : : : ......: : :...... : : : Ohira Expires on December 30, 2003 [Page 2] draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003 +---+ +---+ +---+ | A | | B | | C | ISPs +---+ +---+ +---+ / \ / \ / / \ / \ / / \ / \ / +---+ +---+ +---+ | a | | b | | c | Sites +---+ +---+ +---+ [fig. 1 Considered network connection topology] When the connection is as shown as fig. 1, site b gets address prefixes from ISP A and B. When a host in the site b claims that its address is A:b:HostID, that host is regarded as belonging to the ISP A (as shown in fig. 2(a)). When a host in the site b claims that its address is B:b:HostID, that host is regarded as belonging to the ISP B (as shown in fig. 2(b)). +---+ +---+ A:: | A | B:: | B | +---+ +---+ / \ / \ / \ / \ / \ / \ +---+ +---+ +---+ +---+ | a | | b | | b | | c | +---+ +---+ +---+ +---+ A:a:: A:b:: B:b:: B:c:: [fig. 2(a)] [fig. 2(b)] [fig. 2 [M6H] model network topology on IP layer] Every host in the site b has addresses, one is assigned by ISP A and the other is assigned by ISP B. Each host can take a stand on that it belongs to domain of ISP A or that of B per packet. Here, in this two level hierarchical structure model, addresses are throughly aggregated. In other words, which ISPs each site subscribes to has nothing to do with the exchange routing information among the ISPs. Now, we show this two level hierarchical relation is expandable to three or more level hierarchical relation as shown in [ISP]. Here, the author of [ISP] thinks that all end nodes are able to have Ohira Expires on December 30, 2003 [Page 3] draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003 full route, but we think that some very simple appliances probably never will have any information and that end nodes are able to select routes in the upper layer because the end node does not have full route. We assume that the sites a, b, and c subscribe to the local ISPs A, B and C and that the local ISPs A, B and C subscribe to the top level ISPs as shown in fig. 3. In fig. 3, the site b has only default route to A and B. ~~~~~~~ ( ) BGP cloud ~~~~~~~ : : : ......: : :...... : : : +---+ +---+ +---+ | X | | Y | | Z | Top Level ISPs +---+ +---+ +---+ \ / \ / \ \ / \ / \ \ / \ / \ +---+ +---+ +---+ | A | | B | | C | Local ISPs +---+ +---+ +---+ / \\ // \ / / \\ // \ / / \\/ \ / +---+ +---+ +---+ | a | | b | | c | Sites +---+ +---+ +---+ [fig. 3 Proposed network topology on IP layer] At this time, the top level ISP have to have the routes to the other top level ISPs and do not have to have the other routes. The hosts and routers in each site have to have the routes inside of the site and default route to the site exit routers which have the connectivity to the outside of the site. Only the site exit routes have to have the full routes among the top level ISPs and routes in the routes inside of the top level ISPs which the site belongs to. Notes: It is difficult issue that what route should each local ISPs have. It is an idea that all routers in each local ISP have full routes. If we use this solution, we have to estimate the size of the routing table of full routes. Ohira Expires on December 30, 2003 [Page 4] draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003 By using this way, routers can reduce the routes which the routers should have. In fig. 3, the site b has four prefixes: X:A:b::, Y:A:b::, Y:B:b:: and Z:B:b::. 3. Route Selection If a host has full routing information, it can select an adequete route by means of the ordinal destination based routing. However, especially in a site, it can select an adequete route without full routing information by means of source address based routing. In such case, those nodes have a routing information that the default routes are the ISPs whom the end site subscribes for. In order to achieve the benefit of multihoming in such site, we propose: If a host have default routes, it maintain as many parallel routing tables as there are valid source prefixes for the default routes. Using these tables, the host can select proper route from many routes. At this time, the host refer to not only destination address but also source address. Here, we do not use the tunneling method as shown in the 'host-centric' multihoming but use the source address based routing. With our method, we have the disadvantage that hosts and routes in each sites must be able to handle source address based routing, but we get the advantage that we can select the prefer route and that we do not have to warry about the single point of failure at the site exit routers. The biggest advantage to use end to end multihoming is that end system can select a path or paths from various paths. In the scheme of host centric multihoming, we can not select different path to the same destination for different applications on the same host. Our proposal requires the source address based routing for only default routes. this causes little impact on hosts and routers. Similarly, the impact on the present routing protocol. In fig. 1, the site b is multihoming to the ISP A and B, then a packet from a host named s in the site b has A:b:s or B:b:s as its source address. Similarly, a packet to a host named t in the site c has B:c:t or C:c:t as its destination address. If the host select the route with the longest match between the source address and destination address, the expected packet flow is as shown in fig. 4. ~~~~~~~ ~~~~~~~ Ohira Expires on December 30, 2003 [Page 5] draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003 ( ) ( ) ~~~~~~~ ~~~~~~~ #######: :#: : : : #......: :#:...... ......: : :...... #: :# : : : : +---+ +---+ +---+ +---+ +---+ +---+ | A | | B | | C | | A | | B | | C | +---+ +---+ +---+ +---+ +---+ +---+ / \# / \# / / \ #/ \# / / \# / \# / / \ #/ \# / / \#/ \#/ / \#/ \#/ +---+ +---+ +---+ +---+ +---+ +---+ | a | | b | | c | | a | | b | | c | +---+ +---+ +---+ +---+ +---+ +---+ src. addr. = A:b:s src. addr. = B:b:s dest. addr. = B:c:t dest. addr. = B:c:t [fig. 4(a)] [fig. 4(b)] ~~~~~~~ ~~~~~~~ ( ) ( ) ~~~~~~~ ~~~~~~~ #######: : :####### : :#:####### #......: : :......# ......: :#:......# #: : :# : :# :# +---+ +---+ +---+ +---+ +---+ +---+ | A | | B | | C | | A | | B | | C | +---+ +---+ +---+ +---+ +---+ +---+ / \# / \ #/ / \ #/ \ #/ / \# / \ #/ / \ #/ \ #/ / \#/ \#/ / \#/ \#/ +---+ +---+ +---+ +---+ +---+ +---+ | a | | b | | c | | a | | b | | c | +---+ +---+ +---+ +---+ +---+ +---+ src. addr. = A:b:s src. addr. = B:b:s dest. addr. = C:c:t dest. addr. = C:c:t [fig. 4(c)] [fig. 4(d)] [fig. 4 expected path of packets] 4. Issues in upper layer When a site is in the proposed multihoming environment, in other words, when the site subscribes for multiple upstream ISPs and hold Ohira Expires on December 30, 2003 [Page 6] draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003 different prefixes, how to achieve the benefit of multihoming easily? In order to make it, we have to solve the following issues at least: a) How to know which addresses does the host to which I will connect have? b) How to know which pair of source address and destination address is the most suitable in some sense? -- The host can select route with DNS based address, negotiation in upper layer and so on. Anyway, the selection method is out of scope of this document. c) How to keep a connection even if the address of connection member changes (transport layer survivability) ? -- By using [L6A], each node is identified by lower 64 bits of IP address. While this identifier is same, the connections continue even if the addresses of both ends are changed. -- If protocols in upper layer (SCTP and so on) can deal with, we can get the multihoming environment without host ID (LIN6 and so on). 5. Conclusions The proposed way of multihome does not destroy the hierarchical structure of address space nor increase routing information explosively because the addresses which are assigned to multihome site are always subsets of address space of upstream ISPs. All routers in a network do not have to concern about the route of outside the network. This way of multihome can deal with ingress filtering (indicated in [M6H]) because the source address is always included in the address range of the upstream ISP. 6. Impacts All routers and hosts in the domain in which this proposal is in operation need to be able to deal with source address based routing but the cost to enable this option is not too high because we allow source address based routing for only default route. 7. Security Considerations The authors believe this document does not have any direct impact on security of Internet infrastructure. Ohira Expires on December 30, 2003 [Page 7] draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003 8. References [E2E] M. Ohta, "The Architecture of End to End Multihoming." Work in progress. [M6H] C. Huitema, et. al., "Host-Centric IPv6 Multihoming." Work in progress. [REQ] J. Abley, et. al., "Goals for IPv6 Site-Multihoming Architectures." Work in progress. [L6A] A. Matsumoto, et. al., "Basic Socket API Extensions for LIN6 End-to-End Multihoming." Work in progress. [ISP] M. Ohta, "Multihomed ISPs and Policy Control." Work in progress. 9. Acknowledgement The authors would like to thank everyone involved. 10. Authors' Addresses Kenji Ohira Graduate School of Informatics Kyoto University Yoshida-Honmachi, 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 Katsuya Ogata Graduate School of Informatics Kyoto University Yoshida-Honmachi, 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-Honmachi, 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 Ohira Expires on December 30, 2003 [Page 8] draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003 Kenji Fujikawa Graduate School of Informatics Kyoto University Yoshida-Honmachi, 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-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81 75-753-7458 Fax: +81 75-751-0482 Email: okabe@i.kyoto-u.ac.jp Ohira Expires on December 30, 2003 [Page 9]