rfc3056.txt

最新的RFC

   the visibility of the relay router in that domain.

   IPv6 packets received by the relay router whose next hop IPv6 address
   matches 2002::/16 will be routed to its 6to4 pseudo-interface and
   treated according to the sending rule of Section 5.1.

5.2.2.1. BGP4+ not used

   If BGP4+ is not deployed in the 6to4 exterior routing domain (option
   2.1 of Section 5.2), the relay router will be configured to accept
   and relay all IPv6 traffic only from its client 6to4 sites.  Each
   6to4 router served by the relay router will be configured with a
   default IPv6 route to the relay router (for example, Site A's default
   IPv6 route ::/0 would point to the relay router's address under
   prefix 2002:09fe:fdfc::/48).

5.2.2.2. BGP4+ used

   If BGP4+ is deployed in the 6to4 exterior routing domain (option 2.2
   of Section 5.2), the relay router advertises IPv6 native routing
   prefixes on its 6to4 pseudo-interface, peering only with the 6to4
   routers that it serves.  (An alternative is that these routes could
   be advertised along with IPv4 routes using BGP4 over IPv4, rather
   than by running a separate BGP4+ session.)  The specific routes



Carpenter & Moore           Standards Track                    [Page 12]

RFC 3056       Connection of IPv6 Domains via IPv4 Clouds  February 2001


   advertised depend on applicable routing policy, but they must be
   chosen from among those reachable through the relay router's native
   IPv6 interface.  In the simplest case, a default route to the whole
   IPv6 address space could be advertised.  When multiple relay routers
   are in use, more specific routing prefixes would be advertised
   according to the desired routing policy.  The usage of BGP4+ is
   completely standard so is not discussed further in this document.

5.2.2.3. Relay router scaling

   Relay routers introduce the potential for scaling issues.  In general
   a relay router should not attempt to serve more sites than any other
   transit router, allowing for the encapsulation overhead.

5.2.3 Unwilling to relay

   It may arise that a site has a router with both 6to4 pseudo-
   interfaces and native IPv6 interfaces, but is unwilling to act as a
   relay router.  Such a site MUST NOT advertise any 2002:: routing
   prefix into the native IPv6 domain and MUST NOT advertise any native
   IPv6 routing prefixes or a default IPv6 route into the 6to4 domain.
   Within the 6to4 domain it will behave exactly as in the basic 6to4
   scenario of Section 5.1.

5.3 Sending and decapsulation rules

   The only change to standard IPv6 forwarding is that every 6to4 router
   (and only 6to4 routers) MUST implement the following additional
   sending and decapsulation rules.

   In the sending rule, "next hop" refers to the next IPv6 node that the
   packet will be sent to, which is not necessarily the final
   destination, but rather the next IPv6 neighbor indicated by normal
   IPv6 routing mechanisms.  If the final destination is a 6to4 address,
   it will be considered as the next hop for the purpose of this rule.
   If the final destination is not a 6to4 address, and is not local, the
   next hop indicated by routing will be the 6to4 address of a relay
   router.

   ADDITIONAL SENDING RULE for 6to4 routers

        if the next hop IPv6 address for an IPv6 packet
           does match the prefix 2002::/16, and
           does not match any prefix of the local site
               then
               apply any security checks (see Section 8);
               encapsulate the packet in IPv4 as in Section 3,




Carpenter & Moore           Standards Track                    [Page 13]

RFC 3056       Connection of IPv6 Domains via IPv4 Clouds  February 2001


               with IPv4 destination address = the NLA value V4ADDR
               extracted from the next hop IPv6 address;
               queue the packet for IPv4 forwarding.

   A simple decapsulation rule for incoming IPv4 packets with protocol
   type 41 MUST be implemented:

   ADDITIONAL DECAPSULATION RULE for 6to4 routers

          apply any security checks (see Section 8);
          remove the IPv4 header;
          submit the packet to local IPv6 routing.

5.4 Variant scenario with tunnel to IPv6 space

   A 6to4 site which has no IPv6 connections to the "native" IPv6
   Internet can acquire effective connectivity to the v6 Internet via a
   "configured tunnel" (using the terminology in [MECH]) to a
   cooperating router which does have IPv6 access, but which does not
   need to be a 6to4 router. Such tunnels could be autoconfigured using
   an IPv4 anycast address, but this is outside of the scope of this
   document.  Alternatively a tunnel broker can be used.  This scenario
   would be suitable for a small user-managed site.

   These mechanisms are not described in detail in this document.

5.5 Fragmented Scenarios

   If there are multiple relay routers between native IPv6 and the 6to4
   world, different parts of the 6to4 world will be served by different
   relays.  The only complexity that this introduces is in the scoping
   of 2002::/16 routing advertisements within the native IPv6 world.
   Like any BGP4+ advertisements, their scope must be correctly defined
   by routing policy to ensure that traffic to 2002::/16 follows the
   intended paths.

   If there are multiple IPv6 stubs all interconnected by 6to4 through
   the global IPv4 Internet, this is a simple generalization of the
   basic scenarios of sections 5.1. and 5.2 and no new issues arise.
   This is shown in the following figure.  Subject to consistent
   configuration of routing advertisements, there are no known issues
   with this scenario.









Carpenter & Moore           Standards Track                    [Page 14]

RFC 3056       Connection of IPv6 Domains via IPv4 Clouds  February 2001


                    ______________
                   |     AS3      |
                   |_IPv6 Network_| Both AS1 and AS2 advertise
                   | AS1  | AS2   | 2002::/16, but only one of
                   |______|_______| them reaches AS3.
                    //          \\
         __________//_          _\\__________         ______________
        | 6to4 Relay1 |        | 6to4 Relay2 |       | IPv6 Network |
        |_____________|        |_____________|       |    AS4       |
               |                      |              |______________|
       ________|______________________|________             |
      |                                        |      ______|______
      |       Global IPv4 Network              |-----| 6to4 Relay3 |
      |________________________________________|     |_____________|
         |          |            |          |
     ____|___    ___|____    ____|___    ___|____
    |  6to4  |  |  6to4  |  |  6to4  |  |  6to4  |
    | Site A |  | Site B |  | Site C |  | Site D |
    |________|  |________|  |________|  |________|


   If multiple IPv6 stubs are interconnected through multiple, disjoint
   IPv4 networks (i.e., a fragmented IPv4 world) then the 6to4 world is
   also fragmented; this is the one scenario that must be avoided.  It
   is illustrated below to show why it does not work, since the
   2002::/16 advertisement from Relay1 will be invisible to Relay2, and
   vice versa.  Sites A and B therefore have no connectivity to sites C
   and D.

                    ______________
                   |     AS3      |
                   |_IPv6 Network_| Both AS1 and AS2 advertise
                   | AS1  | AS2   | 2002::/16, but sites A and B
                   |______|_______| cannot reach C and D.
                    //          \\
         __________//_          _\\__________
        | 6to4 Relay1 |        | 6to4 Relay2 |
        |_____________|        |_____________|
               |                      |
       ________|_______        _______|________
      | IPv4 Network   |      | IPv4 Network   |
      | Segment 1      |      | Segment 2      |
      |________________|      |________________|
         |          |            |          |
     ____|___    ___|____    ____|___    ___|____
    |  6to4  |  |  6to4  |  |  6to4  |  |  6to4  |
    | Site A |  | Site B |  | Site C |  | Site D |
    |________|  |________|  |________|  |________|



Carpenter & Moore           Standards Track                    [Page 15]

RFC 3056       Connection of IPv6 Domains via IPv4 Clouds  February 2001


5.6 Multihoming

   Sites which are multihomed on IPv4 MAY extend the 6to4 scenario by
   using a 2002:: prefix for each IPv4 border router, thereby obtaining
   a simple form of IPv6 multihoming by using multiple simultaneous IPv6
   prefixes and multiple simultaneous relay routers.

5.7 Transition Considerations

   If the above rules for routing advertisements and address selection
   are followed, then a site can migrate from using 6to4 to using native
   IPv6 connections over a long period of co-existence, with no need to
   stop 6to4 until it has ceased to be used.  The stages involved are

   1. Run IPv6 on site using any suitable implementation.  True native
   IPv6, [6OVER4], or tunnels are all acceptable.

   2. Configure a border router (or router plus IPv4 NAT) connected to
   the external IPv4 network to support 6to4, including advertising the
   appropriate 2002:: routing prefix locally.  Configure IPv6 DNS
   entries using this prefix.  At this point the 6to4 mechanism is
   automatically available, and the site has obtained a "free" IPv6
   prefix.

   3. Identify a 6to4 relay router willing to relay the site's traffic
   to the native IPv6 world.  This could either be at another
   cooperative 6to4 site, or an ISP service.  If no exterior routing
   protocol is in use in the 6to4 exterior routing domain, the site's
   6to4 router will be configured with a default IPv6 route pointing to
   that relay router's 6to4 address.  If an exterior routing protocol
   such as BGP4+ is in use, the site's 6to4 router will be configured to
   establish appropriate BGP peerings.

   4. When native external IPv6 connectivity becomes available, add a
   second (native) IPv6 prefix to both the border router configuration
   and the DNS configuration.  At this point, an address selection rule
   will determine when 6to4 and when native IPv6 will be used.

   5. When 6to4 usage is determined to have ceased (which may be several
   years later), remove the 6to4 configuration.

5.8 Coexistence with firewall, NAT or RSIP

   The 6to4 mechanisms appear to be unaffected by the presence of a
   firewall at the border router.






Carpenter & Moore           Standards Track                    [Page 16]

RFC 3056       Connection of IPv6 Domains via IPv4 Clouds  February 2001


   If the site concerned has very limited global IPv4 address space, and
   is running an IPv4 network address translator (NAT), all of the above
   mechanisms remain valid.  The NAT box must also contain a fully
   functional IPv6 router including the 6to4 mechanism.  The address
   used for V4ADDR will simply be a globally unique IPv4 address
   allocated to the NAT.  In the example of Section 5.1 above, the 6to4
   routers would also be the sites' IPv4 NATs, which would own the
   globally unique IPv4 addresses 192.1.2.3 and 9.254.253.252.

   Combining a 6to4 router with an IPv4 NAT in this way offers  the site
   concerned a globally unique IPv6 /48 prefix, automatically, behind
   the IPv4 address of the NAT.  Thus every host behind the NAT can
   become an IPv6 host with no need for additional address space
   allocation, and no intervention by the Internet service provider.  No
   address translation is needed by these IPv6 hosts.

   A more complex situation arises if a host is more than one NAT hop
   away from the globally unique IPv4 address space, since only the
   outermost NAT has a unique IPv4 address.  All IPv6 hosts in this
   situation must use addresses derived from the 2002: prefix
   constructed from the global IPv4 address of the outermost NAT.  The
   IPv4 addresses of the inner NATs are not globally unique and play no
   part in the 6to4 mechanism, and 6to4 encapsulation and decapsulation
   can only take place at the outermost NAT.

   The Realm-Specific IP (RSIP) mechanism [RSIP] can also co-exist with
   6to4.  If a 6to4 border router is combined with an RSIP border
   router, it can support IPv6 hosts using 6to4 addresses, IPv4 hosts
   using RSIP, or dual stack hosts using both.  The RSIP function
   provides fine-grained management of dynamic global IPv4 address
   allocation and the 6to4 function provides a stable IPv6 global
   address to each host.  As with NAT, the IPv4 address used to
   construct the site's 2002:  prefix will be one of the global
   addresses of the RSIP border router.

5.9 Usage within Intranets

   There is nothing to stop the above scenario being deployed within a
   private corporate network as part of its internal transition to IPv6;
   the corporate IPv4 backbone would serve as the virtual link layer for
   individual corporate sites using 2002:: prefixes.  The V4ADDR MUST be
   a duly allocated global IPv4 address, which MUST be unique within the
   private network.  The Intranet thereby obtains globally unique IPv6
   addresses even if it is internally using private IPv4 addresses [RFC
   1918].






Carpenter & Moore           Standards Track                    [Page 17]

RFC 3056       Connection of IPv6 Domains via IPv4 Clouds  February 2001


5.10 Summary of impact on routing

   IGP (site) routing will treat the local site's 2002::/48  prefix
   exactly like a native IPv6 site prefix assigned to the local site.
   There will also be an IGP route to the generic 2002::/16 prefix,
   which will be a route to the site's 6to4 router, unless this is
   handled as a default route.

   EGP (i.e., BGP) routing will include advertisements for the 2002::/16
   prefix from relay routers into the native IPv6 domain, whose scope is
   limited by routing policy.  This is the only non-native IPv6 prefix