rfc3056.txt

最新的RFC

   protocol type of 41, the same as has been assigned [MECH] for IPv6
   packets that are tunneled inside of IPv4 frames.  The IPv4 header
   contains the Destination and Source IPv4 addresses.  One or both of
   these will be identical to the V4ADDR field of an IPv6 prefix formed
   as specified above (see section 5 for more details).  The IPv4 packet
   body contains the IPv6 header and payload.








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


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version|  IHL  |Type of Service|          Total Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Identification        |Flags|      Fragment Offset    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Time to Live | Protocol 41   |         Header Checksum       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Source Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Destination Address                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Options                    |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            IPv6 header and payload ...              /
     +-------+-------+-------+-------+-------+------+------+

   The IPv4 Time to Live will be set as normal [RFC 791], as will the
   encapsulated IPv6 hop limit [IPv6].  Other considerations are as
   described in Section 4.1.2 of [MECH].

3.1. Link-Local Address and NUD

   The link-local address of a 6to4 pseudo-interface performing 6to4
   encapsulation would, if needed, be formed as described in Section 3.7
   of [MECH].  However, no scenario is known in which such an address
   would be useful, since a peer 6to4 gateway cannot determine the
   appropriate link-layer (IPv4) address to send to.

   Neighbor Unreachability Detection (NUD) is handled as described in
   Section 3.8 of [MECH].

4. Maximum Transmission Unit

   MTU size considerations are as described for tunnels in [MECH].

   If the IPv6 MTU size proves to be too large for some intermediate
   IPv4 subnet, IPv4 fragmentation will ensue.  While undesirable, this
   is not necessarily disastrous, unless the fragments are delivered to
   different IPv4 destinations due to some form of IPv4 anycast.  The
   IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulating
   IPv4 header.








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


5. Unicast scenarios, scaling, and transition to normal prefixes

5.1 Simple scenario - all sites work the same

   The simplest deployment scenario for 6to4 is to use it between a
   number of sites, each of which has at least one connection to a
   shared IPv4 Internet.  This could be the global Internet, or it could
   be a corporate IP network.  In the case of the global Internet, there
   is no requirement that the sites all connect to the same Internet
   service provider.  The only requirement is that any of the sites is
   able to send IPv4 packets with protocol type 41 to any of the others.
   By definition, each site has an IPv6 prefix in the format defined in
   Section 2.  It will therefore create DNS records for these addresses.
   For example, site A which owns IPv4 address 192.1.2.3 will create DNS
   records with the IPv6 prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48
   (i.e., 2002:c001:0203::/48).  Site B which owns address 9.254.253.252
   will create DNS records with the IPv6 prefix
   {FP=001,TLA=0x0002,NLA=9.254.253.252}/48 (i.e., 2002:09fe:fdfc::/48).

   When an IPv6 host on site B queries the DNS entry for a host on site
   A, or otherwise obtains its address, it obtains an address with the
   prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48 and whatever SLA and
   Interface ID applies.  The converse applies when a host on site A
   queries the DNS for a host on site B.  IPv6 packets are formed and
   transmitted in the normal way within both sites.

                            _______________________________
                           |                               |
                           |  Wide Area IPv4 Network       |
                           |_______________________________|
                                  /                    \
                        192.1.2.3/         9.254.253.252\
 _______________________________/_   ____________________\____________
|                              /  | |                     \           |
|IPv4 Site A          ##########  | |IPv4 Site B          ##########  |
| ____________________# 6to4   #_ | | ____________________# 6to4   #_ |
||                    # router # || ||                    # router # ||
||IPv6 Site A         ########## || ||IPv6 Site B         ########## ||
||2002:c001:0203::/48            || ||2002:09fe:fdfc::/48            ||
||_______________________________|| ||_______________________________||
|                                 | |                                 |
|_________________________________| |_________________________________|


   Within a 6to4 site, addresses with the 2002::/16 prefix, apart from
   those with the local 2002:V4ADDR::/48 prefix, will be handled like
   any other non-local IPv6 address, i.e., by a default or explicit
   route towards the 6to4 border router.



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


   When an outgoing packet reaches the 6to4 router, it is encapsulated
   as defined in Section 3, according to the additional sending rule
   defined in Section 5.3.  Incoming packets are decapsulated according
   to the additional decapsulation rule defined in Section 5.3.  The
   additional sending and decapsulation rules are the only changes to
   IPv6 forwarding, and they occur only at border routers.  No IPv4
   routing information is imported into IPv6 routing (nor vice versa).

   In this scenario, any number of 6to4 sites can interoperate with no
   tunnel configuration, and no special requirements from the IPv4
   service.  All that is required is the appropriate DNS entries and the
   additional sending and decapsulation rules configured in the 6to4
   router.  This router SHOULD also generate the appropriate IPv6 prefix
   announcements [CONF, DISC].

   Although site A and site B will each need to run IPv6 routing
   internally, they do not need to run an IPv6 exterior routing protocol
   in this simple scenario; IPv4 exterior routing does the job for them.

   It is RECOMMENDED that in any case each site should use only one IPv4
   address per 6to4 router, and that should be the address assigned to
   the external interface of the 6to4 router.  Single-homed sites
   therefore SHOULD use only one IPv4 address for 6to4 routing.  Multi-
   homed sites are discussed briefly in section 5.6.

   Because of the lack of configuration, and the distributed deployment
   model, there are believed to be no particular scaling issues with the
   basic 6to4 mechanism apart from encapsulation overhead.
   Specifically, it introduces no new entries in IPv4 routing tables.

5.2 Mixed scenario with relay to native IPv6

   During the transition to IPv6 we can expect some sites to fit the
   model just described (isolated sites whose only connectivity is the
   IPv4 Internet), whereas others will be part of larger islands of
   native or tunneled IPv6 using normal IPv6 TLA address space.  The
   6to4 sites will need connectivity to these native IPv6 islands and
   vice versa.  In the 6to4 model, this connectivity is accomplished by
   IPv6 routers which possess both 6to4 and native IPv6 addresses.
   Although they behave essentially as standard IPv6 routers, for the
   purposes of this document they are referred to as relay routers to
   distinguish them from routers supporting only 6to4, or only native
   IPv6.

   There must be at least one router acting as a relay between the 6to4
   domain and a given native IPv6 domain.  There is nothing special
   about it; it is simply a normal router which happens to have at least




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


   one logical 6to4 pseudo-interface and at least one other IPv6
   interface.  Since it is a 6to4 router, it implements the additional
   sending and decapsulation rules defined in Section 5.3.

   We now have three distinct classes of routing domain to consider:

      1.  the internal IPv6 routing domain of each 6to4 site;
      2.  an exterior IPv6 routing domain interconnecting
          a given set of 6to4 border routers, including relay routers,
          among themselves, i.e., a 6to4 exterior routing domain;
      3.  the exterior IPv6 routing domain of each native IPv6 island.

   1. The internal routing domain of a 6to4 site behaves as described in
   section 5.1.

   2. There are two deployment options for a 6to4 exterior routing
   domain:

   2.1 No IPv6 exterior routing protocol is used.  The 6to4 routers
   using a given relay router each have a default IPv6 route pointing to
   the relay router.  The relay router MAY apply source address based
   filters to accept traffic only from  specific 6to4 routers.

   2.2 An IPv6 exterior routing protocol is used.  The set of 6to4
   routers using a given relay router obtain native IPv6 routes from the
   relay router using a routing protocol such as BGP4+ [RFC 2283,
   BGP4+].  The relay router will advertise whatever native IPv6 routing
   prefixes are appropriate on its 6to4 pseudo-interface.  These
   prefixes will indicate the regions of native IPv6 topology that the
   relay router is willing to relay to.  Their choice is a matter of
   routing policy.  It is necessary for network operators to carefully
   consider desirable traffic patterns and topology when choosing the
   scope of such routing advertisements.  The relay router will
   establish BGP peering only with specific 6to4 routers whose traffic
   it is willing to accept.

   Although this solution is more complex, it provides effective policy
   control, i.e., BGP4+ policy determines which 6to4 routers are able to
   use which relay router.

   3. A relay router MUST advertise a route to 2002::/16 into the native
   IPv6 exterior routing domain.  It is a matter of routing policy how
   far this routing advertisement of 2002::/16 is propagated in the
   native IPv6 routing system.  Since there will in general be multiple
   relay routers advertising it, network operators will require to
   filter it in a managed way.  Incorrect policy in this area will lead
   to potential unreachability or to perverse traffic patterns.




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


   6to4 prefixes more specific than 2002::/16 must not be propagated in
   native IPv6 routing, to prevent pollution of the IPv6 routing table
   by elements of the IPv4 routing table.  Therefore, a 6to4 site which
   also has a native IPv6 connection MUST NOT advertise its 2002::/48
   routing prefix on that connection, and all native IPv6 network
   operators MUST filter out and discard any 2002:: routing prefix
   advertisements longer than /16.

   Sites which have at least one native IPv6 connection, in addition to
   a 6to4 connection, will therefore have at least one IPv6 prefix which
   is not a 2002:: prefix.  Such sites' DNS entries will reflect this
   and DNS lookups will return multiple addresses.  If two such sites
   need to interoperate, whether the 6to4 route or the native route will
   be used depends on IPv6 address selection by the individual hosts (or
   even applications).

   Now consider again the example of the previous section.  Suppose an
   IPv6 host on site B queries the DNS entry for a host on site A, and
   the DNS returns multiple IPv6 addresses with different prefixes.

            ____________________________         ______________________
           |                            |       |                      |
           |  Wide Area IPv4 Network    |       |   Native IPv6        |
           |                            |       |   Wide Area Network  |
           |____________________________|       |______________________|
                /                    \             //
      192.1.2.3/         9.254.253.252\           // 2001:0600::/48
  ____________/_   ____________________\_________//_
             /  | |                     \       //  |
    ##########  | |IPv4 Site B          ##########  |
  __# 6to4   #_ | | ____________________# 6to4   #_ |
    # router # || ||                    # router # ||
    ########## || ||IPv6 Site B         ########## ||
               || ||2002:09fe:fdfc::/48            ||
  __Site A_____|| ||2001:0600::/48_________________||
    as before   | |                                 |
  ______________| |_________________________________|


   If the host picks the 6to4 prefix according to some rule for multiple
   prefixes, it will simply send packets to an IPv6 address formed with
   the prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48.  It is essential
   that they are sourced from the prefix
   {FP=001,TLA=0x0002,NLA=9.254.253.252}/48 for two-way connectivity to
   be possible.  The address selection mechanism of Section 2.1 will
   ensure this.





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


5.2.1 Variant scenario with ISP relay

   The previous scenario assumes that the relay router is provided by a
   cooperative 6to4 user site.  A variant of this is for an Internet
   Service Provider, that already offers native IPv6 connectivity, to
   operate a relay router.  Technically this is no different from the
   previous scenario; site B is simply an internal 6to4 site of the ISP,
   possibly containing only one system, i.e., the relay router itself.

5.2.2 Summary of relay router configuration

   A relay router participates in IPv6 unicast routing protocols on its
   native IPv6 interface and may do so on its 6to4 pseudo-interface, but
   these are independent routing domains with separate policies, even if
   the same protocol, probably BGP4+, is used in both cases.

   A relay router also participates in IPv4 unicast routing protocols on
   its IPv4 interface used to support 6to4, but this is not further
   discussed here.

   On its native IPv6 interface, the relay router MUST advertise a route
   to 2002::/16.  It MUST NOT advertise a longer 2002:: routing prefix
   on that interface.  Routing policy within the native IPv6 routing
   domain determines the scope of that advertisement, thereby limiting