rfc2893.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   to these tunnels is the formation of the link-local address.

   If an implementation provides bidirectional configured tunnels it
   MUST at least accept and respond to the probe packets used by
   Neighbor Unreachability Detection [7].  Such implementations SHOULD
   also send NUD probe packets to detect when the configured tunnel
   fails at which point the implementation can use an alternate path to
   reach the destination.  Note that Neighbor Discovery allows that the
   sending of NUD probes be omitted for router to router links if the
   routing protocol tracks bidirectional reachability.

   For the purposes of Neighbor Discovery the automatic and configured
   tunnels specified in this document as assumed to NOT have a link-
   layer address, even though the link-layer (IPv4) does have address.
   This means that a sender of Neighbor Discovery packets

   -  SHOULD NOT include Source Link Layer Address options or Target
      Link Layer Address options on the tunnel link.

   -  MUST silently ignore any received SLLA or TLLA options on the
      tunnel link.

4.  Configured Tunneling

   In configured tunneling, the tunnel endpoint address is determined
   from configuration information in the encapsulating node.  For each
   tunnel, the encapsulating node must store the tunnel endpoint
   address.  When an IPv6 packet is transmitted over a tunnel, the



Gilligan & Nordmark         Standards Track                    [Page 18]

RFC 2893               IPv6 Transition Mechanisms            August 2000


   tunnel endpoint address configured for that tunnel is used as the
   destination address for the encapsulating IPv4 header.

   The determination of which packets to tunnel is usually made by
   routing information on the encapsulating node.  This is usually done
   via a routing table, which directs packets based on their destination
   address using the prefix mask and match technique.

4.1.  Default Configured Tunnel

   IPv6/IPv4 hosts that are connected to datalinks with no IPv6 routers
   MAY use a configured tunnel to reach an IPv6 router.  This tunnel
   allows the host to communicate with the rest of the IPv6 Internet
   (i.e. nodes with IPv6-native addresses).  If the IPv4 address of an
   IPv6/IPv4 router bordering the IPv6 backbone is known, this can be
   used as the tunnel endpoint address.  This tunnel can be configured
   into the routing table as an IPv6 "default route".  That is, all IPv6
   destination addresses will match the route and could potentially
   traverse the tunnel.  Since the "mask length" of such a default route
   is zero, it will be used only if there are no other routes with a
   longer mask that match the destination.  The default configured
   tunnel can be used in conjunction with automatic tunneling, as
   described in section 5.4.

4.2.  Default Configured Tunnel using IPv4 "Anycast Address"

   The tunnel endpoint address of such a default tunnel could be the
   IPv4 address of one IPv6/IPv4 router at the border of the IPv6
   backbone.  Alternatively, the tunnel endpoint could be an IPv4
   "anycast address".  With this approach, multiple IPv6/IPv4 routers at
   the border advertise IPv4 reachability to the same IPv4 address.  All
   of these routers accept packets to this address as their own, and
   will decapsulate IPv6 packets tunneled to this address.  When an
   IPv6/IPv4 node sends an encapsulated packet to this address, it will
   be delivered to only one of the border routers, but the sending node
   will not know which one.  The IPv4 routing system will generally
   carry the traffic to the closest router.

   Using a default tunnel to an IPv4 "anycast address" provides a high
   degree of robustness since multiple border router can be provided,
   and, using the normal fallback mechanisms of IPv4 routing, traffic
   will automatically switch to another router when one goes down.
   However, care must be taking when using such a default tunnel to
   prevent different IPv4 fragments from arriving at different routers
   for reassembly.  This can be prevented by either avoiding
   fragmentation of the encapsulated packets (by ensuring an IPv4 MTU of
   at least 1300 bytes) or by preventing frequent changes to IPv4
   routing.



Gilligan & Nordmark         Standards Track                    [Page 19]

RFC 2893               IPv6 Transition Mechanisms            August 2000


4.3.  Ingress Filtering

   The decapsulating node MUST verify that the tunnel source address is
   acceptable before forwarding decapsulated packets to avoid
   circumventing ingress filtering [13].  Note that packets which are
   delivered to transport protocols on the decapsulating node SHOULD NOT
   be subject to these checks.  For bidirectional configured tunnels
   this is done by verifying that the source address is the IPv4 address
   of the other end of the tunnel.  For unidirectional configured
   tunnels the decapsulating node MUST be configured with a list of
   source IPv4 address prefixes that are acceptable.  Such a list MUST
   default to not having any entries i.e. the node has to be explicitly
   configured to forward decapsulated packets received over
   unidirectional configured tunnels.

5.  Automatic Tunneling

   In automatic tunneling, the tunnel endpoint address is determined by
   the IPv4-compatible destination address of the IPv6 packet being
   tunneled.  Automatic tunneling allows IPv6/IPv4 nodes to communicate
   over IPv4 routing infrastructures without pre-configuring tunnels.

5.1.  IPv4-Compatible Address Format

   IPv6/IPv4 nodes that perform automatic tunneling are assigned IPv4-
   compatible address.  An IPv4-compatible address is identified by an
   all-zeros 96-bit prefix, and holds an IPv4 address in the low-order
   32-bits.  IPv4-compatible addresses are structured as follows:

          |              96-bits                 |   32-bits    |
          +--------------------------------------+--------------+
          |            0:0:0:0:0:0               | IPv4 Address |
          +--------------------------------------+--------------+
                       IPv4-Compatible IPv6 Address Format

   IPv4-compatible addresses are assigned exclusively to nodes that
   support automatic tunneling.  A node SHOULD be configured with an
   IPv4-compatible address only if it is prepared to accept IPv6 packets
   destined to that address encapsulated in IPv4 packets destined to the
   embedded IPv4 address.

   An IPv4-compatible address is globally unique as long as the IPv4
   address is not from the private IPv4 address space [15].  An
   implementation SHOULD behave as if its IPv4-compatible address(es)
   are assigned to the node's automatic tunneling interface, even if the
   implementation does not implement automatic tunneling using a concept
   of interfaces.  Thus the IPv4-compatible address SHOULD NOT be viewed
   as being attached to e.g. an Ethernet interface i.e. implications



Gilligan & Nordmark         Standards Track                    [Page 20]

RFC 2893               IPv6 Transition Mechanisms            August 2000


   should not use the Neighbor Discovery mechanisms like NUD [7] at the
   Ethernet.  Any such interactions should be done using the
   encapsulated packets i.e. over the automatic tunneling (conceptual)
   interface.

5.2.  IPv4-Compatible Address Configuration

   An IPv6/IPv4 node with an IPv4-compatible address uses that address
   as one of its IPv6 addresses, while the IPv4 address embedded in the
   low-order 32-bits serves as the IPv4 address for one of its
   interfaces.

   An IPv6/IPv4 node MAY acquire its IPv4-compatible IPv6 addresses via
   IPv4 address configuration protocols.  It MAY use any IPv4 address
   configuration mechanism to acquire its IPv4 address, then "map" that
   address into an IPv4-compatible IPv6 address by pre-pending it with
   the 96-bit prefix 0:0:0:0:0:0.  This mode of configuration allows
   IPv6/IPv4 nodes to "leverage" the installed base of IPv4 address
   configuration servers.

   The specific algorithm for acquiring an IPv4-compatible address using
   IPv4-based address configuration protocols is as follows:

   1) The IPv6/IPv4 node uses standard IPv4 mechanisms or protocols to
      acquire the IPv4 address for one of its interfaces.  These
      include:

      -  The Dynamic Host Configuration Protocol (DHCP) [2]

      -  The Bootstrap Protocol (BOOTP) [1]

      -  The Reverse Address Resolution Protocol (RARP) [9]

      -  Manual configuration

      -  Any other mechanism which accurately yields the node's own IPv4
         address

   2) The node uses this address as the IPv4 address for this interface.

   3) The node prepends the 96-bit prefix 0:0:0:0:0:0 to the 32-bit IPv4
      address that it acquired in step (1).  The result is an IPv4-
      compatible IPv6 address with one of the node's IPv4-addresses
      embedded in the low-order 32-bits.  The node uses this address as
      one of its IPv6 addresses.






Gilligan & Nordmark         Standards Track                    [Page 21]

RFC 2893               IPv6 Transition Mechanisms            August 2000


5.3.  Automatic Tunneling Operation

   In automatic tunneling, the tunnel endpoint address is determined
   from the packet being tunneled.  If the destination IPv6 address is
   IPv4-compatible, then the packet can be sent via automatic tunneling.
   If the destination is IPv6-native, the packet can not be sent via
   automatic tunneling.

   A routing table entry can be used to direct automatic tunneling.  An
   implementation can have a special static routing table entry for the
   prefix 0:0:0:0:0:0/96.  (That is, a route to the all-zeros prefix
   with a 96-bit mask.)  Packets that match this prefix are sent to a
   pseudo-interface driver which performs automatic tunneling.  Since
   all IPv4-compatible IPv6 addresses will match this prefix, all
   packets to those destinations will be auto-tunneled.

   Once it is delivered to the automatic tunneling module, the IPv6
   packet is encapsulated within an IPv4 header according to the rules
   described in section 3.  The source and destination addresses of the
   encapsulating IPv4 header are assigned as follows:

      Destination IPv4 address:

         Low-order 32-bits of IPv6 destination address

      Source IPv4 address:

         IPv4 address of interface the packet is sent via

   The automatic tunneling module always sends packets in this
   encapsulated form, even if the destination is on an attached
   datalink.

   The automatic tunneling module MUST NOT send to IPv4 broadcast or
   multicast destinations.  It MUST drop all IPv6 packets destined to
   IPv4-compatible destinations when the embedded IPv4 address is
   broadcast, multicast, the unspecified (0.0.0.0) address, or the
   loopback address (127.0.0.1).  Note that the sender can only tell if
   an address is a network or subnet broadcast for broadcast addresses
   assigned to directly attached links.

5.4.  Use With Default Configured Tunnels

   Automatic tunneling is often used in conjunction with the default
   configured tunnel technique.  "Isolated" IPv6/IPv4 hosts -- those
   with no on-link IPv6 routers -- are configured to use automatic
   tunneling and IPv4-compatible IPv6 addresses, and have at least one
   default configured tunnel to an IPv6 router.  That IPv6 router is



Gilligan & Nordmark         Standards Track                    [Page 22]

RFC 2893               IPv6 Transition Mechanisms            August 2000


   configured to perform automatic tunneling as well.  These isolated
   hosts send packets to IPv4-compatible destinations via automatic
   tunneling and packets for IPv6-native destinations via the default
   configured tunnel.  IPv4-compatible destinations will match the 96-
   bit all-zeros prefix route discussed in the previous section, while
   IPv6-native destinations will match the default route via the
   configured tunnel.  Reply packets from IPv6-native destinations are
   routed back to the an IPv6/IPv4 router which delivers them to the
   original host via automatic tunneling.  Further examples of the
   combination of tunneling techniques are discussed in [12].

5.5.  Source Address Selection

   When an IPv6/IPv4 node originates an IPv6 packet, it must select the
   source IPv6 address to use.  IPv6/IPv4 nodes that are configured to
   perform automatic tunneling may be configured with global IPv6-native
   addresses as well as IPv4-compatible addresses.  The selection of
   which source address to use will determine what form the return
   traffic is sent via.  If the IPv4-compatible address is used, the
   return traffic will have to be delivered via automatic tunneling, but
   if the IPv6-native address is used, the return traffic will not be
   automatic-tunneled.  In order to make traffic as symmetric as
   possible, the following source address selection preference is
   RECOMMENDED:

      Destination is IPv4-compatible:

         Use IPv4-compatible source address associated with IPv4 address
         of outgoing interface

      Destination is IPv6-native:

         Use IPv6-native address of outgoing interface

   If an IPv6/IPv4 node has no global IPv6-native address, but is
   originating a packet to an IPv6-native destination, it MAY use its
   IPv4-compatible address as its source address.

5.6.  Ingress Filtering

   The decapsulating node MUST verify that the encapsulated packets are
   acceptable before forwarding decapsulated packets to avoid
   circumventing ingress filtering [13].  Note that packets which are
   delivered to transport protocols on the decapsulating node SHOULD NOT
   be subject to these checks.  Since automatic tunnels always
   encapsulate to the destination (i.e.  the IPv4 destination will be
   the destination) any packet received over an automatic tunnel SHOULD
   NOT be forwarded.



Gilligan & Nordmark         Standards Track                    [Page 23]

RFC 2893               IPv6 Transition Mechanisms            August 2000


6.  Acknowledgments

   We would like to thank the members of the IPng working group and the
   Next Generation Transition (ngtrans) working group for their many
   contributions and extensive review of this document.  Special thanks
   are due to Jim Bound, Ross Callon, and Bob Hinden for many helpful
   suggestions and to John Moy for suggesting the IPv4 "anycast address"
   default tunnel technique.

7.  Security Considerations