doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

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]
+