rfc3056.txt

RFC 的详细文档！

Network Working Group                                       B. Carpenter
Request for Comments: 3056                                      K. Moore
Category: Standards Track                                  February 2001


               Connection of IPv6 Domains via IPv4 Clouds

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This memo specifies an optional interim mechanism for IPv6 sites to
   communicate with each other over the IPv4 network without explicit
   tunnel setup, and for them to communicate with native IPv6 domains
   via relay routers.  Effectively it treats the wide area IPv4 network
   as a unicast point-to-point link layer.  The mechanism is intended as
   a start-up transition tool used during the period of co-existence of
   IPv4 and IPv6.  It is not intended as a permanent solution.

   The document defines a method for assigning an interim unique IPv6
   address prefix to any site that currently has at least one globally
   unique IPv4 address, and specifies an encapsulation mechanism for
   transmitting IPv6 packets using such a prefix over the global IPv4
   network.

   The motivation for this method is to allow isolated IPv6 domains or
   hosts, attached to an IPv4 network which has no native IPv6 support,
   to communicate with other such IPv6 domains or hosts with minimal
   manual configuration, before they can obtain natuve IPv6
   connectivity.  It incidentally provides an interim globally unique
   IPv6 address prefix to any site with at least one globally unique
   IPv4 address, even if combined with an IPv4 Network Address
   Translator (NAT).








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


Table of Contents

   1. Introduction................................................. 2
   1.1. Terminology................................................ 4
   2. IPv6 Prefix Allocation....................................... 5
   2.1 Address Selection........................................... 6
   3. Encapsulation in IPv4........................................ 6
   3.1. Link-Local Address and NUD................................. 7
   4. Maximum Transmission Unit.................................... 7
   5. Unicast scenarios, scaling, and transition to normal prefixes 8
   5.1 Simple scenario - all sites work the same................... 8
   5.2 Mixed scenario with relay to native IPv6...................  9
   5.2.1 Variant scenario with ISP relay.......................... 12
   5.2.2 Summary of relay router configuration.................... 12
   5.2.2.1. BGP4+ not used........................................ 12
   5.2.2.2. BGP4+ used............................................ 12
   5.2.2.3. Relay router scaling.................................. 13
   5.2.3 Unwilling to relay....................................... 13
   5.3 Sending and decapsulation rules............................ 13
   5.4 Variant scenario with tunnel to IPv6 space................. 14
   5.5 Fragmented Scenarios....................................... 14
   5.6 Multihoming................................................ 16
   5.7 Transition Considerations.................................. 16
   5.8 Coexistence with firewall, NAT or RSIP..................... 16
   5.9 Usage within Intranets..................................... 17
   5.10 Summary of impact on routing.............................. 18
   5.11. Routing loop prevention.................................. 18
   6. Multicast and Anycast....................................... 19
   7. ICMP messages............................................... 19
   8. IANA Considerations......................................... 19
   9. Security Considerations..................................... 19
   Acknowledgements............................................... 20
   References..................................................... 20
   Authors' Addresses............................................. 22
   Intellectual Property.......................................... 22
   Full Copyright Statement....................................... 23

1. Introduction

   This memo specifies an optional interim mechanism for IPv6 sites to
   communicate with each other over the IPv4 network without explicit
   tunnel setup, and for them to communicate with native IPv6 domains
   via relay routers.  Effectively it treats the wide area IPv4 network
   as a unicast point-to-point link layer.  The mechanism is intended as
   a start-up transition tool used during the period of co-existence of
   IPv4 and IPv6.  It is not intended as a permanent solution.





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


   The document defines a method for assigning an interim unique IPv6
   address prefix to any site that currently has at least one globally
   unique IPv4 address, and specifies an encapsulation mechanism for
   transmitting IPv6 packets using such a prefix over the global IPv4
   network.  It also describes scenarios for using such prefixes during
   the co-existence phase of IPv4 to IPv6 transition.  Note that these
   scenarios are only part of the total picture of transition to IPv6.
   Also note that this is considered to be an interim solution and that
   sites should migrate when possible to native IPv6 prefixes and native
   IPv6 connectivity.  This will be possible as soon as the site's ISP
   offers native IPv6 connectivity.

   The basic mechanism described in the present document, which applies
   to sites rather than individual hosts, will scale indefinitely by
   limiting the number of sites served by a given relay router (see
   Section 5.2).  It will introduce no new entries in the IPv4 routing
   table, and exactly one new entry in the native IPv6 routing table
   (see Section 5.10).

   Although the mechanism is specified for an IPv6 site, it can equally
   be applied to an individual IPv6 host or very small site, as long as
   it has at least one globally unique IPv4 address.  However, the
   latter case raises serious scaling issues which are the subject of
   further study [SCALE].

   The motivation for this method is to allow isolated IPv6 sites or
   hosts, attached to a wide area network which has no native IPv6
   support, to communicate with other such IPv6 domains or hosts with
   minimal manual configuration.

   IPv6 sites or hosts connected using this method do not require IPv4-
   compatible IPv6 addresses [MECH] or configured tunnels.  In this way
   IPv6 gains considerable independence of the underlying wide area
   network and can step over many hops of IPv4 subnets.  The abbreviated
   name of this mechanism is 6to4 (not to be confused with [6OVER4]).
   The 6to4 mechanism is typically implemented almost entirely in border
   routers, without specific host modifications except a suggested
   address selection default.  Only a modest amount of router
   configuration is required.

   Sections 2 to 4 of this document specify the 6to4 scheme technically.
   Section 5 discusses some, but not all, usage scenarios, including
   routing aspects, for 6to4 sites.  Scenarios for isolated 6to4 hosts
   are not discussed in this document.  Sections 6 to 9 discuss other
   general considerations.






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


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.1. Terminology

   The terminology of [IPV6] applies to this document.

   6to4 pseudo-interface:
         6to4 encapsulation of IPv6 packets inside IPv4 packets occurs
         at a point that is logically equivalent to an IPv6 interface,
         with the link layer being the IPv4 unicast network.  This point
         is referred to as a pseudo-interface.  Some implementors may
         treat it exactly like any other interface and others may treat
         it like a tunnel end-point.

   6to4 prefix:
         an IPv6 prefix constructed according to the rule in Section 2
         below.

   6to4 address:  an IPv6 address constructed using a 6to4 prefix.

   Native IPv6 address:  an IPv6 address constructed using another type
         of prefix than 6to4.

   6to4 router (or 6to4 border router):
         an IPv6 router supporting a 6to4 pseudo-interface.  It is
         normally the border router between an IPv6 site and a wide-area
         IPv4 network.

   6to4 host:
         an IPv6 host which happens to have at least one 6to4 address.
         In all other respects it is a standard IPv6 host.

   Note: an IPv6 node may in some cases use a 6to4 address for a
   configured tunnel.  Such a node may function as an IPv6 host using a
   6to4 address on its configured tunnel interface, and it may also
   serve as a IPv6 router for other hosts via a 6to4 pseudo-interface,
   but these are distinct functions.

   6to4 site:
         a site running IPv6 internally using 6to4 addresses, therefore
         containing at least one 6to4 host and at least one 6to4 router.








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


   Relay router:
         a 6to4 router configured to support transit routing between
         6to4 addresses and native IPv6 addresses.

   6to4 exterior routing domain:
         a routing domain interconnecting a set of 6to4 routers and
         relay routers.  It is distinct from an IPv6 site's interior
         routing domain, and distinct from all native IPv6 exterior
         routing domains.

2. IPv6 Prefix Allocation

   Suppose that a subscriber site has at least one valid, globally
   unique 32-bit IPv4 address, referred to in this document as V4ADDR.
   This address MUST be duly allocated to the site by an address
   registry (possibly via a service provider) and it MUST NOT be a
   private address [RFC 1918].

   The IANA has permanently assigned one 13-bit IPv6 Top Level
   Aggregator (TLA) identifier under the IPv6 Format Prefix 001 [AARCH,
   AGGR] for the 6to4 scheme.Its numeric value is 0x0002, i.e., it is
   2002::/16 when expressed as an IPv6 address prefix.

   The subscriber site is then deemed to have the following IPv6 address
   prefix, without any further assignment procedures being necessary:

      Prefix length: 48 bits
      Format prefix: 001
      TLA value: 0x0002
      NLA value: V4ADDR

   This is illustrated as follows:

     | 3 |  13  |    32     |   16   |          64 bits               |
     +---+------+-----------+--------+--------------------------------+
     |FP | TLA  | V4ADDR    | SLA ID |         Interface ID           |
     |001|0x0002|           |        |                                |
     +---+------+-----------+--------+--------------------------------+

   Thus, this prefix has exactly the same format as normal /48 prefixes
   assigned according to [AGGR].  It can be abbreviated as
   2002:V4ADDR::/48.  Within the subscriber site it can be used exactly
   like any other valid IPv6 prefix, e.g., for automated address
   assignment and discovery according to the normal mechanisms such as
   [CONF, DISC], for native IPv6 routing, or for the "6over4" mechanism
   [6OVER4].





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


   Note that if the IPv4 address is assigned dynamically, the
   corresponding IPv6 prefix will also be dynamic in nature, with the
   same lifetime.

2.1 Address Selection

   To ensure the correct operation of 6to4 in complex topologies, source
   and destination address selection must be appropriately implemented.
   If the source IPv6 host sending a packet has at least one 2002::
   address assigned to it, and if the set of IPv6 addresses returned by
   the DNS for the destination host contains at least one 2002::
   address, then the source host must make an appropriate choice of the
   source and destination addresses to be used.  The mechanisms for
   address selection in general are under study at the time of writing
   [SELECT].  Subject to those general mechanisms, the principle that
   will normally allow correct operation of 6to4 is this:

   If one host has only a 6to4 address, and the other one has both a
   6to4 and a native IPv6 address, then the 6to4 address should be used
   for both.

   If both hosts have a 6to4 address and a native IPv6 address, then
   either the 6to4 address should be used for both, or the native IPv6
   address should be used for both.  The choice should be configurable.
   The default configuration should be native IPv6 for both.

3. Encapsulation in IPv4

   IPv6 packets from a 6to4 site are encapsulated in IPv4 packets when
   they leave the site via its external IPv4 connection.  Note that the
   IPv4 interface that is carrying the 6to4 traffic is notionally
   equivalent to an IPv6 interface, and is referred to below as a
   pseudo-interface, although this phrase is not intended to define an
   implementation technique.  V4ADDR MUST be configured on the IPv4
   interface.

   IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4