Internet Engeneering Task Force K. Ohira INTERNET-DRAFT K. Ogata June 22, 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 IPv6 suppose that 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 in order for end hosts to select an adequete route from multiple routes when multihoming. 1. Introduction Ohira Expires on December 22, 2003 [Page 1] draft-ohira-assign-select-e2e-multihome-00.txt 23 June 2003 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 little as a home network. It is difficult for present way of multihome to respond such request. 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 Address assignment We assume that the Internet is composed of world-wide ISPs, local ISPs and sites, and then they are connected as fig. 1. +---+ +---+ +---+ | X | | Y | | Z | Top Level ISPs +---+ +---+ +---+ \ / \ / \ \ / \ / \ \ / \ / \ +---+ +---+ +---+ | A | | B | | C | Local 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)). +---+ +---+ +---+ +---+ | X | | Y | | Y | | Z | +---+ +---+ +---+ +---+ Ohira Expires on December 22, 2003 [Page 2] draft-ohira-assign-select-e2e-multihome-00.txt 23 June 2003 \ / \ / \ / \ / \ / \ / +---+ +---+ | A | | B | +---+ +---+ / \ / \ / \ / \ / \ / \ +---+ +---+ +---+ +---+ | a | | b | | b | | c | +---+ +---+ +---+ +---+ [fig. 2(a)] [fig. 2(b)] [fig. 2 Proposed 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. 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. At each case, the expected packet flow is as shown in fig. 3. ......... ......... : : Virtual Aggregator : : ......... ......... : : : : : : ......: : :...... ......: : :...... : : : : : : +---+ +---+ +---+ +---+ +---+ +---+ | X | | Y | | Z | | X | | Y | | Z | +---+ +---+ +---+ +---+ +---+ +---+ \ #/ \# / \ \ / \ / \ \ #/ \# / \ \ / \ / \ \#/ \#/ \ \ / \ / \ +---+ +---+ +---+ +---+ +---+ +---+ | A | | B | | C | | A | | B | | C | +---+ +---+ +---+ +---+ +---+ +---+ / \# / \# / / \ #/ \# / / \# / \# / / \ #/ \# / / \#/ \#/ / \#/ \#/ +---+ +---+ +---+ +---+ +---+ +---+ | a | | b | | c | | a | | b | | c | +---+ +---+ +---+ +---+ +---+ +---+ Ohira Expires on December 22, 2003 [Page 3] draft-ohira-assign-select-e2e-multihome-00.txt 23 June 2003 src. addr. = ::A:b:s src. addr. = ::B:b:s dest. addr. = ::B:c:t dest. addr. = ::B:c:t [fig. 3(a)] [fig. 3(b)] ......... ......... : : Virtual Aggregator : : ......... ......... : :#:####### : : : ......: :#:......# ......: : :...... : :# :# : : : +---+ +---+ +---+ +---+ +---+ +---+ | X | | Y | | Z | | X | | Y | | Z | +---+ +---+ +---+ +---+ +---+ +---+ \ #/ \ /#\ \ / \ #/#\ \ #/ \ / #\ \ / \ #/ #\ \#/ \ / #\ \ / \#/ #\ +---+ +---+ +---+ +---+ +---+ +---+ | 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. 3(c)] [fig. 3(d)] [fig. 3 expected path of packets] 3. Route Selection We assume that every router has routing information already. When a router accept a packet, if the destination address of that packet matches explicit route, then the router forwards the packet according to that route. Otherwise, the router forwards the packet according to the default route. If a network has two or more upstreams, the network has two or more default routes. At such time, the router refers to the source address of the packet Ohira Expires on December 22, 2003 [Page 4] draft-ohira-assign-select-e2e-multihome-00.txt 23 June 2003 and then the router forwards the packet to the upstream whom the source address belongs to. 4. Tasks of upper layer (out of scope of this document) a) How to know what addresses does the host to which I will connect have? b) How to know what pair of source address and destination address is the best suitable in some sense? c) How to keep a connection even if the address of connection member changes? 5. Conclusions The proposed way of multihome does not destroy the hierarchical structure of address space nor increase routing informations 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 of the network. This way of multihome can deal with source address filtering. 6. Security Considerations The author believes this document does not have any direct impact on security of Internet infrastructure. 7. Acknowledgement The authors would like to thank everyone involved. 8. 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 Ohira Expires on December 22, 2003 [Page 5] draft-ohira-assign-select-e2e-multihome-00.txt 23 June 2003 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 Kenji Fujikawa 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: fujikawa@real-internet.org Yasuo Okabe Integrated information Network System Kyoto University Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81 75-753-7468 Fax: +81 75-753-7472 Email: okabe@i.kyoto-u.ac.jp Ohira Expires on December 22, 2003 [Page 6]