rfc2893.txt

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

        if (IPv4 path MTU - 20) is less than or equal to 1280
                if packet is larger than 1280 bytes
                        Send IPv6 ICMP "packet too big" with MTU = 1280.
                        Drop packet.
                else
                        Encapsulate but do not set the Don't Fragment
                        flag in the IPv4 header.  The resulting IPv4
                        packet might be fragmented by the IPv4 layer on
                        the encapsulating node or by some router along
                        the IPv4 path.
                endif
        else
                if packet is larger than (IPv4 path MTU - 20)
                        Send IPv6 ICMP "packet too big" with
                        MTU = (IPv4 path MTU - 20).
                        Drop packet.
                else



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


                        Encapsulate and set the Don't Fragment flag
                        in the IPv4 header.
                endif
        endif

   Encapsulating nodes that have a large number of tunnels might not be
   able to store the IPv4 Path MTU for all tunnels.  Such nodes can, at
   the expense of additional fragmentation in the network, avoid using
   the IPv4 Path MTU algorithm across the tunnel and instead use the MTU
   of the link layer (under IPv4) in the above algorithm instead of the
   IPv4 path MTU.

   In this case the Don't Fragment bit MUST NOT be set in the
   encapsulating IPv4 header.

3.3.  Hop Limit

   IPv6-over-IPv4 tunnels are modeled as "single-hop".  That is, the
   IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the
   tunnel.  The single-hop model serves to hide the existence of a
   tunnel.  The tunnel is opaque to users of the network, and is not
   detectable by network diagnostic tools such as traceroute.

   The single-hop model is implemented by having the encapsulating and
   decapsulating nodes process the IPv6 hop limit field as they would if
   they were forwarding a packet on to any other datalink.  That is,
   they decrement the hop limit by 1 when forwarding an IPv6 packet.
   (The originating node and final destination do not decrement the hop
   limit.)

   The TTL of the encapsulating IPv4 header is selected in an
   implementation dependent manner.  The current suggested value is
   published in the "Assigned Numbers RFC.  Implementations MAY provide
   a mechanism to allow the administrator to configure the IPv4 TTL such
   as the one specified in the IP Tunnel MIB [17].

3.4.  Handling IPv4 ICMP errors

   In response to encapsulated packets it has sent into the tunnel, the
   encapsulating node might receive IPv4 ICMP error messages from IPv4
   routers inside the tunnel.  These packets are addressed to the
   encapsulating node because it is the IPv4 source of the encapsulated
   packet.








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


   The ICMP "packet too big" error messages are handled according to
   IPv4 Path MTU Discovery [8] and the resulting path MTU is recorded in
   the IPv4 layer.  The recorded path MTU is used by IPv6 to determine
   if an IPv6 ICMP "packet too big" error has to be generated as
   described in section 3.2.

   The handling of other types of ICMP error messages depends on how
   much information is included in the "packet in error" field, which
   holds the encapsulated packet that caused the error.

   Many older IPv4 routers return only 8 bytes of data beyond the IPv4
   header of the packet in error, which is not enough to include the
   address fields of the IPv6 header.  More modern IPv4 routers are
   likely to return enough data beyond the IPv4 header to include the
   entire IPv6 header and possibly even the data beyond that.

   If the offending packet includes enough data, the encapsulating node
   MAY extract the encapsulated IPv6 packet and use it to generate an
   IPv6 ICMP message directed back to the originating IPv6 node, as
   shown below:

                  +--------------+
                  | IPv4 Header  |
                  | dst = encaps |
                  |       node   |
                  +--------------+
                  |     ICMP     |
                  |    Header    |
           - -    +--------------+
                  | IPv4 Header  |
                  | src = encaps |
          IPv4    |       node   |
                  +--------------+   - -
          Packet  |    IPv6      |
                  |    Header    |   Original IPv6
           in     +--------------+   Packet -
                  |  Transport   |   Can be used to
          Error   |    Header    |   generate an
                  +--------------+   IPv6 ICMP
                  |              |   error message
                  ~     Data     ~   back to the source.
                  |              |
           - -    +--------------+   - -

      IPv4 ICMP Error Message Returned to Encapsulating Node






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


3.5.  IPv4 Header Construction

   When encapsulating an IPv6 packet in an IPv4 datagram, the IPv4
   header fields are set as follows:

      Version:

         4

      IP Header Length in 32-bit words:

         5 (There are no IPv4 options in the encapsulating header.)

      Type of Service:

         0. [Note that work underway in the IETF is redefining the Type
         of Service byte and as a result future RFCs might define a
         different behavior for the ToS byte when tunneling.]

      Total Length:

         Payload length from IPv6 header plus length of IPv6 and IPv4
         headers (i.e. a constant 60 bytes).

      Identification:

         Generated uniquely as for any IPv4 packet transmitted by the
         system.

      Flags:

         Set the Don't Fragment (DF) flag as specified in section 3.2.
         Set the More Fragments (MF) bit as necessary if fragmenting.

      Fragment offset:

         Set as necessary if fragmenting.

      Time to Live:

         Set in implementation-specific manner.

      Protocol:

         41 (Assigned payload type number for IPv6)






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


      Header Checksum:

         Calculate the checksum of the IPv4 header.

      Source Address:

         IPv4 address of outgoing interface of the encapsulating node.

      Destination Address:

         IPv4 address of tunnel endpoint.

   Any IPv6 options are preserved in the packet (after the IPv6 header).

3.6.  Decapsulation

   When an IPv6/IPv4 host or a router receives an IPv4 datagram that is
   addressed to one of its own IPv4 address, and the value of the
   protocol field is 41, it reassembles if the packet if it is
   fragmented at the IPv4 level, then it removes the IPv4 header and
   submits the IPv6 datagram to its IPv6 layer code.

   The decapsulating node MUST be capable of reassembling an IPv4 packet
   that is 1300 bytes (1280 bytes plus IPv4 header).

   The decapsulation is shown below:

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

                       Decapsulating IPv6 from IPv4







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


   When decapsulating the packet, the IPv6 header is not modified.
   [Note that work underway in the IETF is redefining the Type of
   Service byte and as a result future RFCs might define a different
   behavior for the ToS byte when decapsulating a tunneled packet.]  If
   the packet is subsequently forwarded, its hop limit is decremented by
   one.

   As part of the decapsulation the node SHOULD silently discard a
   packet with an invalid IPv4 source address such as a multicast
   address, a broadcast address, 0.0.0.0, and 127.0.0.1.  In general it
   SHOULD apply the rules for martian filtering in [18] and ingress
   filtering [13] on the IPv4 source address.

   The encapsulating IPv4 header is discarded.

   After the decapsulation the node SHOULD silently discard a packet
   with an invalid IPv6 source address.  This includes IPv6 multicast
   addresses, the unspecified address, and the loopback address but also
   IPv4-compatible IPv6 source addresses where the IPv4 part of the
   address is an (IPv4) multicast address, broadcast address, 0.0.0.0,
   or 127.0.0.1.  In general it SHOULD apply the rules for martian
   filtering in [18] and ingress filtering [13] on the IPv4-compatible
   source address.

   The decapsulating node performs IPv4 reassembly before decapsulating
   the IPv6 packet.  All IPv6 options are preserved even if the
   encapsulating IPv4 packet is fragmented.

   After the IPv6 packet is decapsulated, it is processed almost the
   same as any received IPv6 packet.  The only difference being that a
   decapsulated packet MUST NOT be forwarded unless the node has been
   explicitly configured to forward such packets for the given IPv4
   source address.  This configuration can be implicit in e.g., having a
   configured tunnel which matches the IPv4 source address.  This
   restriction is needed to prevent tunneling to be used as a tool to
   circumvent ingress filtering [13].

3.7.  Link-Local Addresses

   Both the configured and automatic tunnels are IPv6 interfaces (over
   the IPv4 "link layer") thus MUST have link-local addresses.  The
   link-local addresses are used by routing protocols operating over the
   tunnels.

   The Interface Identifier [14] for such an Interface SHOULD be the
   32-bit IPv4 address of that interface, with the bytes in the same
   order in which they would appear in the header of an IPv4 packet,
   padded at the left with zeros to a total of 64 bits.  Note that the



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


   "Universal/Local" bit is zero, indicating that the Interface
   Identifier is not globally unique.  When the host has more than one
   IPv4 address in use on the physical interface concerned, an
   administrative choice of one of these IPv4 addresses is made.

   The IPv6 Link-local address [14] for an IPv4 virtual interface is
   formed by appending the Interface Identifier, as defined above, to
   the prefix FE80::/64.

   +-------+-------+-------+-------+-------+-------+------+------+
   |  FE      80      00      00      00      00      00     00  |
   +-------+-------+-------+-------+-------+-------+------+------+
   |  00      00   |  00   |  00   |   IPv4 Address              |
   +-------+-------+-------+-------+-------+-------+------+------+

3.8.  Neighbor Discovery over Tunnels

   Automatic tunnels and unidirectional configured tunnels are
   considered to be unidirectional.  Thus the only aspects of Neighbor
   Discovery [7] and Stateless Address Autoconfiguration [5] that apply