rfc3178.txt

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

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]