rfc3178.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 676 行 · 第 1/2 页


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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Hal Snyder
   Vail Systems, Inc.
   570 Lake Cook Rd, Ste 408
   Deerfield, IL 60015, US

   Phone: [phone]
   EMail: [e-mail]































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]