rfc2893.txt

<VC++网络游戏建摸与实现>源代码

   -  IPv6/IPv4 node that does not perform tunneling.

   -  IPv6/IPv4 node that performs configured tunneling only.

   -  IPv6/IPv4 node that performs configured tunneling and automatic
      tunneling.





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


2.1.  Address Configuration

   Because they support both protocols, IPv6/IPv4 nodes may be
   configured with both IPv4 and IPv6 addresses.  IPv6/IPv4 nodes use
   IPv4 mechanisms (e.g. DHCP) to acquire their IPv4 addresses, and IPv6
   protocol mechanisms (e.g. stateless address autoconfiguration) to
   acquire their IPv6-native addresses.  Section 5.2 describes a
   mechanism by which IPv6/IPv4 nodes that support automatic tunneling
   MAY use IPv4 protocol mechanisms to acquire their IPv4-compatible
   IPv6 address.

2.2.  DNS

   The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map
   between hostnames and IP addresses.  A new resource record type named
   "A6" has been defined for IPv6 addresses [6] with support for an
   earlier record named "AAAA".  Since IPv6/IPv4 nodes must be able to
   interoperate directly with both IPv4 and IPv6 nodes, they must
   provide resolver libraries capable of dealing with IPv4 "A" records
   as well as IPv6 "A6" and "AAAA" records.

   DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling
   both A6/AAAA and A records.  However, when a query locates an A6/AAAA
   record holding an IPv6 address, and an A record holding an IPv4
   address, the resolver library MAY filter or order the results
   returned to the application in order to influence the version of IP
   packets used to communicate with that node.  In terms of filtering,
   the resolver library has three alternatives:

   -  Return only the IPv6 address to the application.

   -  Return only the IPv4 address to the application.

   -  Return both addresses to the application.

   If it returns only the IPv6 address, the application will communicate
   with the node using IPv6.  If it returns only the IPv4 address, the
   application will communicate with the node using IPv4.  If it returns
   both addresses, the application will have the choice which address to
   use, and thus which IP protocol to employ.

   If it returns both, the resolver MAY elect to order the addresses --
   IPv6 first, or IPv4 first.  Since most applications try the addresses
   in the order they are returned by the resolver, this can affect the
   IP version "preference" of applications.






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


   The decision to filter or order DNS results is implementation
   specific.  IPv6/IPv4 nodes MAY provide policy configuration to
   control filtering or ordering of addresses returned by the resolver,
   or leave the decision entirely up to the application.

   An implementation MUST allow the application to control whether or
   not such filtering takes place.

2.3.  Advertising Addresses in the DNS

   There are some constraint placed on the use of the DNS during
   transition.  Most of these are obvious but are stated here for
   completeness.

   The recommendation is that A6/AAAA records for a node should not be
   added to the DNS until all of these are true:

      1) The address is assigned to the interface on the node.

      2) The address is configured on the interface.

      3) The interface is on a link which is connected to the IPv6
         infrastructure.

   If an IPv6 node is isolated from an IPv6 perspective (e.g. it is not
   connected to the 6bone to take a concrete example) constraint #3
   would mean that it should not have an address in the DNS.

   This works great when other dual stack nodes tries to contact the
   isolated dual stack node.  There is no IPv6 address in the DNS thus
   the peer doesn't even try communicating using IPv6 but goes directly
   to IPv4 (we are assuming both nodes have A records in the DNS.)

   However, this does not work well when the isolated node is trying to
   establish communication.  Even though it does not have an IPv6
   address in the DNS it will find A6/AAAA records in the DNS for the
   peer.  Since the isolated node has IPv6 addresses assigned to at
   least one interface it will try to communicate using IPv6.  If it has
   no IPv6 route to the 6bone (e.g. because the local router was
   upgraded to advertise IPv6 addresses using Neighbor Discovery but
   that router doesn't have any IPv6 routes) this communication will
   fail.  Typically this means a few minutes of delay as TCP times out.
   The TCP specification says that ICMP unreachable messages could be
   due to routing transients thus they should not immediately terminate
   the TCP connection.  This means that the normal TCP timeout of a few
   minutes apply.  Once TCP times out the application will hopefully try
   the IPv4 addresses based on the A records in the DNS, but this will
   be painfully slow.



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


   A possible implication of the recommendations above is that, if one
   enables IPv6 on a node on a link without IPv6 infrastructure, and
   choose to add A6/AAAA records to the DNS for that node, then external
   IPv6 nodes that might see these A6/AAAA records will possibly try to
   reach that node using IPv6 and suffer delays or communication failure
   due to unreachability.  (A delay is incurred if the application
   correctly falls back to using IPv4 if it can not establish
   communication using IPv6 addresses.  If this fallback is not done the
   application would fail to communicate in this case.)  Thus it is
   suggested that either the recommendations be followed, or care be
   taken to only do so with nodes that will not be impacted by external
   accessing delays and/or communication failure.

   In the future when a site or node removes the support for IPv4 the
   above recommendations apply to when the A records for the node(s)
   should be removed from the DNS.

3.  Common Tunneling Mechanisms

   In most deployment scenarios, the IPv6 routing infrastructure will be
   built up over time.  While the IPv6 infrastructure is being deployed,
   the existing IPv4 routing infrastructure can remain functional, and
   can be used to carry IPv6 traffic.  Tunneling provides a way to
   utilize an existing IPv4 routing infrastructure to carry IPv6
   traffic.

   IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of
   IPv4 routing topology by encapsulating them within IPv4 packets.
   Tunneling can be used in a variety of ways:

   -  Router-to-Router.  IPv6/IPv4 routers interconnected by an IPv4
      infrastructure can tunnel IPv6 packets between themselves.  In
      this case, the tunnel spans one segment of the end-to-end path
      that the IPv6 packet takes.

   -  Host-to-Router.  IPv6/IPv4 hosts can tunnel IPv6 packets to an
      intermediary IPv6/IPv4 router that is reachable via an IPv4
      infrastructure.  This type of tunnel spans the first segment of
      the packet's end-to-end path.

   -  Host-to-Host.  IPv6/IPv4 hosts that are interconnected by an IPv4
      infrastructure can tunnel IPv6 packets between themselves.  In
      this case, the tunnel spans the entire end-to-end path that the
      packet takes.

   -  Router-to-Host.  IPv6/IPv4 routers can tunnel IPv6 packets to
      their final destination IPv6/IPv4 host.  This tunnel spans only
      the last segment of the end-to-end path.



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


   Tunneling techniques are usually classified according to the
   mechanism by which the encapsulating node determines the address of
   the node at the end of the tunnel.  In the first two tunneling
   methods listed above -- router-to-router and host-to-router -- the
   IPv6 packet is being tunneled to a router.  The endpoint of this type
   of tunnel is an intermediary router which must decapsulate the IPv6
   packet and forward it on to its final destination.  When tunneling to
   a router, the endpoint of the tunnel is different from the
   destination of the packet being tunneled.  So the addresses in the
   IPv6 packet being tunneled can not provide the IPv4 address of the
   tunnel endpoint.  Instead, the tunnel endpoint address must be
   determined from configuration information on the node performing the
   tunneling.  We use the term "configured tunneling" to describe the
   type of tunneling where the endpoint is explicitly configured.

   In the last two tunneling methods -- host-to-host and router-to-host
   -- the IPv6 packet is tunneled all the way to its final destination.
   In this case, the destination address of both the IPv6 packet and the
   encapsulating IPv4 header identify the same node!  This fact can be
   exploited by encoding information in the IPv6 destination address
   that will allow the encapsulating node to determine tunnel endpoint
   IPv4 address automatically.  Automatic tunneling employs this
   technique, using an special IPv6 address format with an embedded IPv4
   address to allow tunneling nodes to automatically derive the tunnel
   endpoint IPv4 address.  This eliminates the need to explicitly
   configure the tunnel endpoint address, greatly simplifying
   configuration.

   The two tunneling techniques -- automatic and configured -- differ
   primarily in how they determine the tunnel endpoint address.  Most of
   the underlying mechanisms are the same:

   -  The entry node of the tunnel (the encapsulating node) creates an
      encapsulating IPv4 header and transmits the encapsulated packet.

   -  The exit node of the tunnel (the decapsulating node) receives the
      encapsulated packet, reassembles the packet if needed, removes the
      IPv4 header, updates the IPv6 header, and processes the received
      IPv6 packet.

   -  The encapsulating node MAY need to maintain soft state information
      for each tunnel recording such parameters as the MTU of the tunnel
      in order to process IPv6 packets forwarded into the tunnel.  Since
      the number of tunnels that any one host or router may be using may
      grow to be quite large, this state information can be cached and
      discarded when not in use.





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


   The remainder of this section discusses the common mechanisms that
   apply to both types of tunneling.  Subsequent sections discuss how
   the tunnel endpoint address is determined for automatic and
   configured tunneling.

3.1.  Encapsulation

   The encapsulation of an IPv6 datagram in IPv4 is shown below:

                                             +-------------+
                                             |    IPv4     |
                                             |   Header    |
             +-------------+                 +-------------+
             |    IPv6     |                 |    IPv6     |
             |   Header    |                 |   Header    |
             +-------------+                 +-------------+
             |  Transport  |                 |  Transport  |
             |   Layer     |      ===>       |   Layer     |
             |   Header    |                 |   Header    |
             +-------------+                 +-------------+
             |             |                 |             |
             ~    Data     ~                 ~    Data     ~
             |             |                 |             |
             +-------------+                 +-------------+

                      Encapsulating IPv6 in IPv4

   In addition to adding an IPv4 header, the encapsulating node also has
   to handle some more complex issues:

   -  Determine when to fragment and when to report an ICMP "packet too
      big" error back to the source.

   -  How to reflect IPv4 ICMP errors from routers along the tunnel path
      back to the source as IPv6 ICMP errors.

   Those issues are discussed in the following sections.

3.2.  Tunnel MTU and Fragmentation

   The encapsulating node could view encapsulation as IPv6 using IPv4 as
   a link layer with a very large MTU (65535-20 bytes to be exact; 20
   bytes "extra" are needed for the encapsulating IPv4 header).  The
   encapsulating node would need only to report IPv6 ICMP "packet too
   big" errors back to the source for packets that exceed this MTU.
   However, such a scheme would be inefficient for two reasons:





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


   1) It would result in more fragmentation than needed.  IPv4 layer
      fragmentation SHOULD be avoided due to the performance problems
      caused by the loss unit being smaller than the retransmission unit
      [11].

   2) Any IPv4 fragmentation occurring inside the tunnel would have to
      be reassembled at the tunnel endpoint.  For tunnels that terminate
      at a router, this would require additional memory to reassemble
      the IPv4 fragments into a complete IPv6 packet before that packet
      could be forwarded onward.

   The fragmentation inside the tunnel can be reduced to a minimum by
   having the encapsulating node track the IPv4 Path MTU across the
   tunnel, using the IPv4 Path MTU Discovery Protocol [8] and recording
   the resulting path MTU.  The IPv6 layer in the encapsulating node can
   then view a tunnel as a link layer with an MTU equal to the IPv4 path
   MTU, minus the size of the encapsulating IPv4 header.

   Note that this does not completely eliminate IPv4 fragmentation in
   the case when the IPv4 path MTU would result in an IPv6 MTU less than
   1280 bytes. (Any link layer used by IPv6 has to have an MTU of at
   least 1280 bytes [4].) In this case the IPv6 layer has to "see" a
   link layer with an MTU of 1280 bytes and the encapsulating node has
   to use IPv4 fragmentation in order to forward the 1280 byte IPv6
   packets.

   The encapsulating node can employ the following algorithm to
   determine when to forward an IPv6 packet that is larger than the
   tunnel's path MTU using IPv4 fragmentation, and when to return an
   IPv6 ICMP "packet too big" message: