Internet Engineering Task Force Jun-ichiro Hagino INTERNET-DRAFT Research Lab, IIJ Expires: January 28, 2000 July 28, 1999 IPv6 multihoming support at site exit routers draft-itojun-ipv6-2260-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with 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/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be January 28, 2000. Abstract The document describes operational requirements and mechanisms for basic IPv6 multihoming support. The mechanism in this document can be combined with more sophisticated (or complex) multihoming support mechanisms, and it will be able to serve as foundation for others. The document is largely based on RFC2260 [Bates, 1998] by Tony Bates. 1. Problem IPv6 specifications try to decrease the number of backbone routes, to cope with possible memory overflow problem in the backbone routers. To achieve this, the IPv6 addressing architecture [Hinden, 1998] only allows the use of aggregatable addresses. Also, IPv6 network administration rules [Durand, 1999] do not allow non-aggregatable routing announcements to the backbone. Hagino Expires: January 28, 2000 [Page 1] DRAFT IPv6 multihoming support at site exit routers July 1999 In IPv4, a multihomed site uses either of the following technique to achieve better reachability: o Obtain a portable IPv4 address prefix, and announce it from multiple upstream providers. o Obtain single IPv4 address prefix from ISP A, and announce it from multiple upstream providers the site is connected to. The above two methodologies are not available in IPv6, but on the other hand IPv6 sites and hosts may obtain multiple simultaneous address prefixes to achieve the same result. The document provides a way to configure site exit routers and ISP routers, so that the site can achieve better reachability from multihoming connectivity, without violating IPv6 rules. The technique uses already-defined routing protocol (BGP or RIPng), and tunnelling of IPv6 packets, and introduces no new protocol standard. The document is largely based on RFC2260 [Bates, 1998] by Tony Bates. 2. Goals and non-goals The goal of this document is to achieve better packet delivery from a site to the outside, or from the outside to the site, even when some of site exit link is down. Non goals are: o Choose the "best" exit link as possible (How do you measure "best" exit link anyway?). o Achieve load-balancing between multiple exit links. 3. Basic mechanisms We use technique described in RFC2260 section 5.2 onto our configuration. To summarize, for IPv4-only networks, RFC2260 says that: o We assume that our site is connected to 2 ISPs, ISP-A and ISP-B. o We are assigned IP address prefix, Pref-A and Pref-B, from ISP-A and ISP-B respectively. Hosts near ISP-A will get an address from Pref- A, and vice versa. o In the site, we locally exchanage routes for Pref-A and Pref-B, so that hosts in the site can communicate with each other without using external link. Hagino Expires: January 28, 2000 [Page 2] DRAFT IPv6 multihoming support at site exit routers July 1999 o ISP-A and our site is connected by ``primary link'' between ISP router ISP-BR-A and our router E-BR-A. ISP B and our site is connected by primary link between ISP router ISP-BR-B and our router E-BR-B. (ISP A) (ISP B) ISP-BR-A ISP-BR-B | | |Primary link | | | | | +---|-----------------------------|--+ | E-BR-A E-BR-B | | | | Pref-A <----------> Pref-B | +------------------------------------+ o Establish a secondary link, between ISP-BR-A and E-BR-B, and ISP-BR-B and E-BR-A, respectively. Secondary link usually is IP-over-IP tunnel. It is important to have secondary link on top of different medium than primary link, so that one of them survives link failure. For example, secondary link between ISP-BR-A and E-BR-B should go through different medium than primary link between ISP-BR-A and E-BR- A. If secondary link is an IPv4-over-IPv4 tunnel, tunnel endpoint at E-BR-A needs to be an address in Pref-A, not in Pref-B (tunnelled packet needs to travel from ISP-BR-B to E-BR-A, over the primary link between ISP-BR-A and E-BR-A). (ISP A) (ISP B) ISP-BR-A ISP-BR-B | | | | | \-----------------------+ | | | Secondary link | | | | +----------------------|-/ | | | | | | | | | | | | | | | | | +---|--|----------------------|---|--+ | E-BR-A E-BR-B | | | | | +------------------------------------+ o For inbound packets, E-BR-A will advertise (1) Pref-A toward ISP-BR-A with strong preference over primary link, and (2) Pref-B toward ISP- BR-B with weak preference over secondary link. Similarly, E-BR-B will advertise (1) Pref-B toward ISP-BR-B with strong preference over Hagino Expires: January 28, 2000 [Page 3] DRAFT IPv6 multihoming support at site exit routers July 1999 primary link, and (2) Pref-A toward ISP-BR-A with weak preference over secondary link. Note that we always announce Pref-A to ISP-BR-A, and Pref-B to ISP- BR-B. o For outbound packets, ISP-BR-A will advertise (1) default route (or specific routes) toward E-BR-A with strong preference over primary link, and (2) default route (or specific routes) toward E-BR-B with weak preference over secondary link. Similarly, ISP-BR-B will advertise (1) default route (or specific routes) toward E-BR-B with strong preference over primary link, and (2) default route (or specific routes) toward E-BR-A with weak preference over secondary link. Under this configuration, both inbound and outbound packet can survive link failure on either side. Routing information with weak preference will be available as backup, for both inbound and outbound cases. 4. Extensions for IPv6 RFC2260 is written for IPv4 and BGP. With IPv6 and BGP4+, or IPv6 and RIPng, similar result can be achieved, without violating IPv6 addressing/routing rules. 4.1. IPv6 rule conformance In RFC2260, we announce Pref-A toward ISP-BR-A only, and Pref-B toward ISP-BR-B only. Therefore, there will be no extra routing announcement to the outside of the site. This conforms to the aggregation requirement in IPv6 documents. Also, RFC2260 does not require portable addresses. 4.2. Address assignment to the nodes In IPv4, it is usually assumed that a node will be assigned single IPv4 address. Therefore, RFC2260 assumed that addresses from Pref-A will be assigned to nodes near E-BR-A, and vice versa (second bullet in the previous section). With IPv6, a node can be assigned multiple IPv6 addresses. So we can assign (1) one address from Pref-A, (2) one address from Pref-B, or (3) two addresses from both address prefixes, to single node in the site. This will allow more flexibility to nodes in the site. However, this may make source address selection on a node more complex. Source address selection itself is out of scope of the document. Hagino Expires: January 28, 2000 [Page 4] DRAFT IPv6 multihoming support at site exit routers July 1999 4.3. Configuration of links With IPv6, primary link can be IPv6 native connectivity, RFC1933 [Gilligan, 1996] IPv6-over-IPv4 configured tunnel, 6to4 [Carpenter, 1999] IPv6-over-IPv4 encapsulation, or some others. If tunnelling-based connectivity is used in some of primary links, administrators may want to avoid IPv6-over-IPv6 tunnels for secondary links. For example, if: o primary links to ISP-A and ISP-B are RFC1933 IPv6-over-IPv4 tunnels, and o ISP-A, ISP-B and the site have IPv4 connectivity with each other, it makes no sense to configure a secondary link by IPv6-over-IPv6 tunnel, since it will actually be IPv6-over-IPv6-over-IPv4 tunnel. In this case, IPv6-over-IPv4 tunnel should be used for secondary link. This configuration has a big win as secondary link will be able to have the same path MTU than the primary link. 4.4. Using RFC2260 with IPv6 and BGP4+ RFC2260 approach on top of IPv6 will work fine as documented in RFC2260. There will be no extra twists necessary. 4.5. Using RFC2260 with IPv6 and RIPng It is possible to run RFC2260-like configuration with RIPng [Malkin, 1997] , with careful control of metric. Routers in the figure needs to increase RIPng metric on secondary link, to make primary link a preferred path. If we denote the RIPng metric for route announcement, from router R1 toward router R2, as metric(R1, R2), the invariants that must hold are: o metric(E-BR-A, ISP-BR-A) < metric(E-BR-B, ISP-BR-A) o metric(E-BR-B, ISP-BR-B) < metric(E-BR-A, ISP-BR-B) o metric(ISP-BR-A, E-BR-A) < metric(ISP-BR-A, E-BR-B) o metric(ISP-BR-B, E-BR-B) < metric(ISP-BR-B, E-BR-A) Note that smaller metric means stronger route in RIPng. Hagino Expires: January 28, 2000 [Page 5] DRAFT IPv6 multihoming support at site exit routers July 1999 5. Issues with ingress filters in ISP If the upstream ISP imposes ingress filters [Ferguson, 1998] to outbound traffic, story becomes much more complex. A packet with source address taken from Pref-A must go out from ISP-BR-A. Similarly, a packet with source address taken from Pref-B must go out from ISP-BR-B. Since none of the routers in the site network will route packets based on source address, packets can easily be routed to incorrect border router. One possible way is to negotiate with both ISPs, to allow both Pref-B and Pref-A to be used as source address. This approach does not work if upstream ISP of ISP-A imposes ingress filtering. Since there will be multiple levels of ISP on top of ISP-A, it will be hard to understand which upstream ISP imposes the filter. In reality, this problem will be very rare, as ingress filter is not suitable for use in large ISPs where smaller ISPs are connected beneath. Another possibility is to use source-based routing at E-BR-A and E-BR-B. In this case, secondary link needs to be IPv6-over-IPv6 tunnel. When an outbound packet arrives to E-BR-A with source address in Pref-B, E-BR-A will forward it to secondary link (tunnel to ISP-BR-B) based on source- based routing decision. The packet will look like this: o Outer IPv6 header: source = address of E-BR-A in Pref-A, dest = ISP- BR-B o Inner IPv6 header: source = address in Pref-B, dest = final dest Tunneled packet will travel across ISP-BR-A toward ISP-BR-B. The packet can go through ingress filter at ISP-BR-A, since it has outer IPv6 source address in Pref-A. Packet will reach ISP-BR-B and decapsulated before ingress filter is applied. Decapsulated packet can go through ingress filter at ISP-BR-B, since it now has source address in Pref-B (from inner IPv6 header). Notice the following facts when configuring this: o Not every router implements source-based routing. o Interaction of normal routing and source-based routing at E-BR-A (and/or E-BR-B) can be vary by router implementations. o Interaction of tunnel egress and filter rules at ISP-BR-B (and/or ISP-BR-A) can be vary by router implementations and filter configurations. 6. Observations We limited the number of ISPs to 2 in the document, but it can easily be extended to the cases where we have 3 or more upstream ISPs. Hagino Expires: January 28, 2000 [Page 6] DRAFT IPv6 multihoming support at site exit routers July 1999 If you have many upstream providers, you would not make all ISPs backup each other, as it requires O(N^2) tunnels for N ISPs. Rather, it is better to make N/2 pairs of ISPs, and let each pair of ISP backup each other. It is important to pick pairs which are unlikely to be down simultaneously. In this way, number of tunnels will be O(N). Suppose that the site is very large and it has ISP links in very distant locations, such as in US and in Japan. In such case, it is wiser to use this technique only among ISP links in US, and only among ISP links in Japan. If you use this technique between ISP A in US and ISP B in Japan, the secondary link make packets travel very long path, for example, from host in the site in US, to E-BR-B in Japan, to ISP-BR-B (again in Japan), and then to the final destination in US. This may not make sense for actual use, due to excessive delay. Similarly, in a large site, addresses must be assigned to end nodes with great care, to minimize delays due to extra path packets may travel. It may be wiser to avoid assigning an address in a prefix assigned from Japanese ISP, to an end node in US. If one of primary link is down for a long time, administrators may want to control source address selection on end hosts so that secondary link is less likely to be used. This can be achieved by marking unwanted prefix as deprecated. Suppose the primary link toward ISP-A has been down. You will issue router advertisement [Thomson, 1998; Narten, 1998] packets from routers, with preferred lifetime set to 0 in prefix information option for Pref-A. End hosts will consider addresses in Pref-A as deprecated, and will not use any of them as source address for future connections. If an end host in the site makes new connection to outside, the host will use an address in Pref-B as source address, and reply packet to the end host will travel primary link from ISP-BR-B toward E-BR-B. Some of non-goals (such as "best" exit link selection) can be achieved by combining technique described in this document, with some other techniques. One example of the technique would be the source/destination address selection heuristics on the end nodes. 7. Security considerations The configuration described in the document introduces no new security problem. If primary links toward ISP-A and ISP-B have different security characteristics (like encrypted link and non-encrypted link), administrators needs to be careful setting up secondary links tunneled on them. Packets may travel unwanted path, if secondary links are configured without care. Hagino Expires: January 28, 2000 [Page 7] DRAFT IPv6 multihoming support at site exit routers July 1999 References Bates, 1998. T. Bates and Y. Rekhter, "Scalable Support for Multi-homed Multi- provider Connectivity" in RFC2260 (January 1998). ftp://ftp.isi.edu/in- notes/rfc2260.txt. Hinden, 1998. R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. Durand, 1999. A. Durand and B. Buclin, "6Bone Routing Practice" in RFC2546 (March 1999). ftp://ftp.isi.edu/in-notes/rfc2546.txt. Gilligan, 1996. R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers" in RFC1933 (April 1996). ftp://ftp.isi.edu/in- notes/rfc1933.txt. Carpenter, 1999. B. Carpenter and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels" in draft-ietf-ngtrans-6to4-02.txt (June 1999). work in progress material. Malkin, 1997. G. Malkin and R. Minnear, "RIPng for IPv6" in RFC2080 (January 1997). ftp://ftp.isi.edu/in-notes/rfc2080.txt. Ferguson, 1998. P. Ferguson and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing" in RFC2267 (January 1998). ftp://ftp.isi.edu/in-notes/rfc2267.txt. Thomson, 1998. S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration" in RFC2462 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2462.txt. Narten, 1998. T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)" in RFC2461 (December 1998). ftp://ftp.isi.edu/in- notes/rfc2461.txt. Acknowledgements The document was made possible by cooperation from people in ipngwg multihoming design team, people in KAME project and George Tsirtsis. Hagino Expires: January 28, 2000 [Page 8] DRAFT IPv6 multihoming support at site exit routers July 1999 Author's address Jun-ichiro Hagino Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku,Tokyo 101-0054, JAPAN Tel: +81-3-5259-6350 Fax: +81-3-5259-6351 email: itojun@iijlab.net Hagino Expires: January 28, 2000 [Page 9]