From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3178.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc3178.txt (limited to 'doc/rfc/rfc3178.txt') diff --git a/doc/rfc/rfc3178.txt b/doc/rfc/rfc3178.txt new file mode 100644 index 0000000..02f5ed3 --- /dev/null +++ b/doc/rfc/rfc3178.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group J. Hagino +Request for Comments: 3178 Research Laboratory, IIJ +Category: Informational H. Snyder + Vail Systems + October 2001 + + + IPv6 Multihoming Support at Site Exit Routers + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + The document describes a mechanism for basic IPv6 multihoming + support, and its operational requirements. Unlike currently- + practiced IPv4 multihoming, the technique does not impact the + worldwide routing table size, nor IGP (Interior Gateway Protocol) + routing table size in upstream ISPs. The mechanism can be combined + with more sophisticated (or complex) multihoming support mechanisms, + and can be used as a foundation for other mechanisms. The document + is largely based on RFC 2260 by Tony Bates. + +1. Problem + + Routing table size has been a major issue for both IPv4 and IPv6. As + IPv6 addresses are 4 times larger in bit width than IPv4, the routing + table size issue would have more serious negative effects on router + memory usage, as well as routing table lookup performance. To cope + with this problem, the IPv6 addressing architecture [Hinden, 1998] is + designed to take advantage of aggregated routing announcements to + reduce the number of routes in default-free zone. Also, 6bone + operation guideline [Rockell, 2000] (which is the currently-practiced + guideline for IPv6 network operation) suggests that ASes not announce + non-aggregatable announcements to the default-free zone, if there is + no special agreement with the peer. + + In IPv4, a multihomed site uses either of the following techniques to + achieve better reachability: + + + + + +Hagino & Snyder Informational [Page 1] + +RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 + + + o Obtain a portable IPv4 address prefix, and announce it from + multiple upstream providers. + + o Obtain a single IPv4 address prefix from ISP A, and announce it + from multiple upstream providers the site is connected to. + + Since the above two methodologies effectively inject additional + routes to the worldwide routing table, they have negative impact on + the worldwide routing table size issue. They also are not compatible + with current IPv6 operational practice. + + This document provides a way to configure site exit routers and ISP + routers, so that the site can achieve better reachability from + multihomed connectivity, without impacting worldwide routing table + size issues. The technique uses multiple distinct IPv6 address + prefixes, assigned from multiple upstream ISPs. The technique uses + an already-defined routing protocol (BGP or RIPng) and tunneling of + IPv6 packets; therefore, this document introduces no new protocol + standard (the document describes how to operate the configuration). + + This document is largely based on RFC 2260 [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 the site exit links are down. + + Non goals are: + + o Choose the "best" exit link as possible. Note that there can be + no common definition of the "best" exit link. + + o Achieve load-balancing between multiple exit links. + + o Cope with breakage of any of the upstream ISPs. + +3. Basic mechanisms + + We use the technique described in RFC 2260 section 5.2 in our + configuration. To summarize, for IPv4-only networks, RFC 2260 says + that: + + o We assume that our site is connected to 2 ISPs, ISP-A and ISP-B. + + + + + + +Hagino & Snyder Informational [Page 2] + +RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 + + + o We are assigned IP address prefixes, 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 exchange routes for Pref-A and Pref-B, so + that hosts in the site can communicate with each other without + using external link. + + o ISP-A and our site are connected by a "primary link" between ISP + router ISP-BR-A and our router E-BR-A. ISP B and our site are + connected by a 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. The secondary link usually is an + IP-over-IP tunnel. It is important to have the secondary link on + top of a different medium than the primary link, so that one of + them survives link failure. For example, the secondary link + between ISP-BR-A and E-BR-B should go through a different medium + than the primary link between ISP-BR-A and E-BR-A. If the + secondary link is an IPv4-over-IPv4 tunnel, the tunnel endpoint at + E-BR-A needs to be an address in Pref-A, not in Pref-B (tunneled + packet needs to travel from ISP-BR-B to E-BR-A, over the primary + link between ISP-BR-A and E-BR-A). + + + + + + + + + + + + + + +Hagino & Snyder Informational [Page 3] + +RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 + + + (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 the over primary link, and (2) Pref-B + toward ISP-BR-B with weak preference over the secondary link. + Similarly, E-BR-B will advertise (1) Pref-B toward ISP-BR-B with + strong preference over the primary link, and (2) Pref-A toward + ISP-BR-A with weak preference over the 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 the + primary link, and (2) default route (or specific routes) toward + E-BR-B with weak preference over the secondary link. Similarly, + ISP-BR-B will advertise (1) default route (or specific routes) + toward E-BR-B with strong preference over the primary link, and + (2) default route (or specific routes) toward E-BR-A with weak + preference over the secondary link. + + Under this configuration, both inbound and outbound packets 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 + + RFC 2260 is written for IPv4 and BGP. With IPv6 and BGP4+, or IPv6 + and RIPng, similar results can be achieved, without impacting + worldwide IPv6 routing table size. + + + + + +Hagino & Snyder Informational [Page 4] + +RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 + + +4.1. IPv6 rule conformance + + In RFC 2260, 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 meets the suggestions + in 6bone aggregation guidelines [Rockell, 2000]. Also, RFC 2260 does + not require portable addresses. + +4.2. Address assignment to the nodes + + In IPv4, it is usually assumed that a node will be assigned a single + IPv4 address. Therefore, RFC 2260 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, multiple IPv6 addresses can be assigned to a node. So we + can assign (1) one address from Pref-A, (2) one address from Pref-B, + or (3) addresses from both prefixes, to a single node in the site. + This will allow more flexibility in node configuration. + + When multiple IPv6 global addresses are assigned to an IPv6 node, + source address selection must take place on packet transmissions. + Source address selection itself is out of scope of the document. + Refer to a separate draft [Draves, 2001] for more discussions. + + One simplifying approach is to place the site's Internet hosts on + separate subnets, one with addresses in Pref-A and connected to E- + BR-A, the other having addresses in Pref-B and connected to E-BR-B. + This approach generalizes to having E-BR-A and E-BR-B at different + sites, where site A and site B have links to the Internet and to each + other. + +4.3. Configuration of links + + With IPv6, the primary link can be IPv6 native connectivity, RFC 2893 + [Gilligan, 2000] IPv6-over-IPv4 configured tunnel, 6to4 [Carpenter, + 2000] IPv6-over-IPv4 encapsulation, or some others. + + If tunnel-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 RFC 2893 IPv6-over-IPv4 + tunnels, and + + o ISP-A, ISP-B and the site have IPv4 connectivity with each other. + + + + + +Hagino & Snyder Informational [Page 5] + +RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 + + + 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. IPv6-over-IPv4 configuration has a big advantage against + IPv6-over-IPv6-over-IPv4 configuration, as secondary link will be + able to have the same path MTU than the primary link. + + In the figure, ISP-BR-A and E-BR-A are both single points of failure + for inbound traffic to Pref-A. This could be remedied by using + different routers for primary vs. backup links. + +4.4. Using RFC 2260 with IPv6 and BGP4+ + + The RFC 2260 approach on top of IPv6 will work fine as documented in + RFC 2260. There will be no extra twists necessary. Since the + multihomed site is not doing transit, variations are possible that do + not require it to have a public AS number. + +4.5. Using RFC 2260 with IPv6 and RIPng + + It is possible to run an RFC 2260-like configuration with RIPng + [Malkin, 1997] , with careful control of metric. Routers in the + figure need to increase RIPng metric on the secondary link, to make + the 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. + +5. Issues with ingress filters in ISP + + If the upstream ISP imposes ingress filters [Ferguson, 1998] to + outbound traffic, the 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. + + + +Hagino & Snyder Informational [Page 6] + +RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 + + + 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. Here we assume that IPv6-over-IPv6 tunnel is used for + secondary links. When an outbound packet arrives to E-BR-A with + source address in Pref-B, E-BR-A will forward it to the 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 + + A 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. The packet will reach ISP-BR-B and be + 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 The interaction between normal routing and source-based routing at + E-BR-A (and/or E-BR-B) varies by router implementations. + + o At ISP-BR-B (and/or ISP-BR-A), the interaction between tunnel + egress processing and filtering rules varies by router + implementations and filter configurations. + +6. Observations + + The document discussed the cases where a site has two upstream ISPs. + The document can easily be extended to the cases where there are 3 or + more upstream ISPs. + + 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 ISPs + + + + + +Hagino & Snyder Informational [Page 7] + +RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 + + + 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 the United States and in Japan. In + such a case, it is wiser to use this technique only among ISP links + in the US, and only among ISP links in Japan. If you use this + technique between ISP link A in the US and ISP link B in Japan, the + secondary link makes packets travel a very long path, for example, + from a host in the site in the US, to E-BR-B in Japan, to ISP-BR-B + (again in Japan), and then to the final destination in the 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 the US. + + If one of the primary links 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 the 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 a new connection to outside, the host will use an + address in Pref-B as source address, and the reply packet to the end + host will travel the primary link from ISP-BR-B toward E-BR-B. A + great care must be taken when you try to automate this by using + router renumbering protocols [Crawford, 2000] , as the approach could + lead your site into very unstable state if any of the links flap. + The author does not recommend to automate it. + + Some of non-goals (such as "best" exit link selection) can be + achieved by combining the technique described in this document, with + some other techniques. One example of the technique would be the + source/destination address selection [Draves, 2001] on the end nodes. + +7. Operational experiences + + Hal Snyder has been running the technique, with two upstream ISPs + (lava.net and iijlab), using 2 RFC 2893 IPv6-over-IPv4 tunnels to + each of them (in total 4 tunnels), and BGP4+ peering over them. + + + + + +Hagino & Snyder Informational [Page 8] + +RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 + + + As expected, when the primary links goes down the routing switches to + the secondary link within BGP hold time, i.e., we see approximately + the relations: + + o (hold time - keepalive time) < failover time + + o failover time < hold time + + o failback time < keepalive time + + This has been tested with keepalive and hold times from as low as 3 + and 10 seconds respectively, up to 60 and 180 seconds respectively. + + The routing change will affect ISP-BR-A (or B) only. Because route + instability is not propagated beyond one ISP, it should be feasible + to use lower hold and keepalive times than in a conventional IPv4 + setting. If primary and backup links terminate on the same router at + the ISP, then failover from primary to backup link need not affect + reachability information upstream of that router. + + Many of the existing IPv6 networks (connected to worldwide 6bone) are + assigned multiple IPv6 prefixes from multiple upstreams. In many + cases people assign global IPv6 addresses generated from multiple + address prefixes. There has been almost no problems raised about + complication due to source address selection. + +8. 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 need to be careful setting up secondary links tunneled + on them. Packets may travel an unwanted path, if secondary links are + configured without care. + +References + + [Bates, 1998] Bates, T. and Y. Rekhter, "Scalable Support for + Multi-homed Multi-provider Connectivity", RFC 2260, + January 1998. + + [Hinden, 1998] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + + + + + +Hagino & Snyder Informational [Page 9] + +RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 + + + [Rockell, 2000] Rockell, R. and B. Fink, "6Bone Backbone Routing + Guidelines", RFC 2772, February 2000. + + [Draves, 2001] Draves, R., "Default Address Selection for IPv6", + Work in Progress. + + [Gilligan, 2000] Gilligan, R. and E. Nordmark, "Transition + Mechanisms for IPv6 Hosts and Routers", RFC 2893, + August 2000. + + [Carpenter, 2000] Carpenter, B. and K. Moore, "Connection of IPv6 + Domains via IPv4 Clouds", RFC 3056, February 2001. + + [Malkin, 1997] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC + 2080, January 1997. + + [Ferguson, 1998] Ferguson, P. and D. Senie, "Network Ingress + Filtering: Defeating Denial of Service Attacks + which employ IP Source Address Spoofing", RFC 2267, + January 1998. + + [Thomson, 1998] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [Narten, 1998] Narten, T., Nordmark, E. and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, + December 1998. + + [Crawford, 2000] Crawford, M., "Router Renumbering for IPv6", RFC + 2894, August 2000. + +Acknowledgements + + The document was made possible by cooperation from people + participated in JEPG-IP IPv6 multihoming study meeting (1999), people + in ipngwg multihoming design team, people in WIDE/KAME project and + George Tsirtsis. + + + + + + + + + + + + + + +Hagino & Snyder Informational [Page 10] + +RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 + + +Authors' Addresses + + Jun-ichiro itojun Hagino + Research Laboratory, Internet Initiative Japan Inc. + Takebashi Yasuda Bldg., + 3-13 Kanda Nishiki-cho, + Chiyoda-ku, Tokyo 101-0054, JAPAN + + Phone: +81-3-5259-6350 + Fax: +81-3-5259-6351 + EMail: itojun@iijlab.net + + + Hal Snyder + Vail Systems, Inc. + 570 Lake Cook Rd, Ste 408 + Deerfield, IL 60015, US + + Phone: +1-312-360-8245 + EMail: hal@vailsys.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hagino & Snyder Informational [Page 11] + +RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Hagino & Snyder Informational [Page 12] + -- cgit v1.2.3