rfc2473.txt

RFC 的详细文档！

          Hdr Ext Len:

            Length of the Destination Options extension header in 8-
            octet units, not including the first 8 octets. Set to value
            0, if no other options are present in this destination
            options header.

          Option Type:

            value 4 - see section 4.1.1.

          Opt Data Len:

            value 1 - see section 4.1.1.

          Tun Encap Lim:

            8 bit unsigned integer - see section 4.1.1.

          Option Type:

            value 1 - PadN option, to align the  header  following
            this header.

          Opt Data Len:

            value 1 - one octet of option data.




Conta & Deering             Standards Track                    [Page 18]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


          Option Data:

            value 0 - one zero-valued octet.

6. IPv6 Tunnel State Variables

   The IPv6 tunnel state variables, some of which are or may be
   configured on the tunnel entry-point node, are:

6.1 IPv6 Tunnel Entry-Point Node Address

   The tunnel entry-point node address is one of the valid IPv6 unicast
   addresses of the entry-point node - the validation of the address at
   tunnel configuration time is recommended.

   The tunnel entry-point node address is copied to the source address
   field in the tunnel IPv6 header during packet encapsulation.

6.2 IPv6 Tunnel Exit-Point Node Address

   The tunnel exit-point node address is used as IPv6 destination
   address for the tunnel IPv6 header. A tunnel acts like a virtual
   point to point link between the entry-point node and exit-point node.

   The tunnel exit-point node address is copied to the destination
   address field in the tunnel IPv6 header during packet encapsulation.

   The configuration of the tunnel entry-point and exit-point addresses
   is not subject to IPv6 Autoconfiguration or IPv6 Neighbor Discovery.

6.3 IPv6 Tunnel Hop Limit

   An IPv6 tunnel is modeled as a "single-hop virtual link" tunnel, in
   which the passing of the original packet through the tunnel is like
   the passing of the original packet over a one hop link, regardless of
   the number of hops in the IPv6 tunnel.

   The "single-hop" mechanism should be implemented by having the tunnel
   entry point node set a tunnel IPv6 header hop limit independently of
   the hop limit of the original header.

   The "single-hop" mechanism hides from the original IPv6 packets the
   number of IPv6 hops of the tunnel.

   It is recommended that the tunnel hop limit be configured with a
   value that ensures:





Conta & Deering             Standards Track                    [Page 19]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


        (a)  that tunnel IPv6 packets can reach  the  tunnel  exit-point
             node

        (b)  a quick expiration of the tunnel packet if a  routing  loop
             occurs within the IPv6 tunnel.

   The tunnel hop limit default value for hosts is the IPv6 Neighbor
   Discovery advertised hop limit [ND-Spec].  The tunnel hop limit
   default value for routers is the default IPv6 Hop Limit value from
   the Assigned Numbers RFC (64 at the time of writing this document).

   The tunnel hop limit is copied into the hop limit field of the tunnel
   IPv6 header of each packet encapsulated by the tunnel entry-point
   node.

6.4 IPv6 Tunnel Packet Traffic Class

   The IPv6 Tunnel Packet Traffic Class indicates the value that a
   tunnel entry-point node sets in the Traffic Class field of a tunnel
   header. The default value is zero.  The configured Packet Traffic
   Class can also indicate whether the value of the Traffic Class field
   in the tunnel header is copied from the original header, or it is set
   to the pre-configured value.

6.5 IPv6 Tunnel Flow Label

   The IPv6 Tunnel Flow Label indicates the value that a tunnel entry-
   point node sets in the flow label of a tunnel header. The default
   value is zero.

6.6 IPv6 Tunnel Encapsulation Limit

   The Tunnel Encapsulation Limit value can indicate whether the entry-
   point node is configured to limit the number of encapsulations of
   tunnel packets originating on that node.  The IPv6 Tunnel
   Encapsulation Limit is the maximum number of additional
   encapsulations permitted for packets undergoing encapsulation at that
   entry-point node. Recommended default value is 4. An entry-point node
   configured to limit the number of nested encapsulations prepends a
   Destination Options extension header containing a Tunnel
   Encapsulation Limit option to an original packet undergoing
   encapsulation - see sections 4.1 and 4.1.1.

6.7 IPv6 Tunnel MTU

   The tunnel MTU is set dynamically to the Path MTU between the tunnel
   entry-point and the tunnel exit-point nodes, minus the size of the
   tunnel headers: the maximum size of a tunnel packet payload that can



Conta & Deering             Standards Track                    [Page 20]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   be sent through the tunnel without fragmentation [IPv6-Spec]. The
   tunnel entry-point node performs Path MTU discovery on the path
   between the tunnel entry-point and exit-point nodes [PMTU-Spec],
   [ICMP-Spec]. The tunnel MTU of a nested tunnel is the tunnel MTU of
   the outer tunnel minus the size of the nested tunnel headers.

7. IPv6 Tunnel Packet Size Issues

   Prepending a tunnel header increases the size of a packet, therefore
   a tunnel packet resulting from the encapsulation of an IPv6 original
   packet may require fragmentation.

   A tunnel IPv6 packet resulting from the encapsulation of an original
   packet is considered an IPv6 packet originating from the tunnel
   entry-point node. Therefore, like any source of an IPv6 packet, a
   tunnel entry-point node must support fragmentation of tunnel IPv6
   packets.

   A tunnel intermediate node that forwards a tunnel packet to another
   node in the tunnel follows the general IPv6 rule that it must not
   fragment a packet undergoing forwarding.

   A tunnel exit-point node receiving tunnel packets at the end of the
   tunnel for decapsulation applies the strict left-to-right processing
   rules for extension headers. In the case of a fragmented tunnel
   packet, the fragments are reassembled into a complete tunnel packet
   before determining that an embedded packet is present.

   Note:

   A particular problem arises when the destination of a fragmented
   tunnel packet is an exit-point node identified by an anycast address.
   The problem, which is similar to that of original fragmented IPv6
   packets destined to nodes identified by an anycast address, is that
   all the fragments of a packet must arrive at the same destination
   node for that node to be able to perform a successful reassembly, a
   requirement that is not necessarily satisfied by packets sent to an
   anycast address.

7.1 IPv6 Tunnel Packet Fragmentation

   When an IPv6 original packet enters a tunnel, if the original packet
   size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel
   entry-point and the tunnel exit-point, minus the size of the tunnel
   header(s)), it is handled as follows:






Conta & Deering             Standards Track                    [Page 21]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


        (a)  if the original IPv6 packet size is larger  than  the  IPv6
             minimum link MTU [IPv6-Spec], the entry-point node discards
             the packet and sends an ICMPv6 "Packet Too Big" message to
             the source address of the original packet with the
             recommended MTU size field set to the tunnel MTU or the
             IPv6 minimum link MTU, whichever is larger, i.e. max
             (tunnel MTU, IPv6 minimum link MTU).  Also see sections 6.7
             and 8.2.

        (b)  if the original IPv6 packet is equal or  smaller  than  the
             IPv6 minimum link MTU, the tunnel entry-point node
             encapsulates the original packet, and subsequently
             fragments the resulting IPv6 tunnel packet into IPv6
             fragments that do not exceed the Path MTU to the tunnel
             exit-point.

7.2 IPv4 Tunnel Packet Fragmentation

   When an IPv4 original packet enters a tunnel, if the original packet
   size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel
   entry-point and the tunnel exit-point, minus the size of the tunnel
   header(s)), it is handled as follows:

        (a)  if in the original IPv4 packet header the Don't Fragment  -
             DF - bit flag is SET, the entry-point node discards the
             packet and returns an ICMP message.  The ICMP message has
             the type = "unreachable", the code = "packet too big", and
             the recommended MTU size field set to the size of the
             tunnel MTU - see sections 6.7 and 8.3.

        (b)  if in the original packet header the Don't Fragment - DF  -
             bit flag is CLEAR, the tunnel entry-point node encapsulates
             the original packet, and subsequently fragments the
             resulting IPv6 tunnel packet into IPv6 fragments that do
             not exceed the Path MTU to the tunnel exit-point.

8. IPv6 Tunnel Error Processing and Reporting

   IPv6 Tunneling follows the general rule that an error detected during
   the processing of an IPv6 packet is reported through an ICMP message
   to the source of the packet.

   On a forwarding path that includes IPv6 tunnels, an error detected by
   a node that is not in any tunnel is directly reported to the source
   of the original IPv6 packet.






Conta & Deering             Standards Track                    [Page 22]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   An error detected by a node inside a tunnel is reported to the source
   of the tunnel packet, that is, the tunnel entry-point node.  The ICMP
   message sent to the tunnel entry-point node has as ICMP payload the
   tunnel IPv6 packet that has the original packet as its payload.

   The cause of a packet error encountered inside a tunnel can be a
   problem with:

        (a)  the tunnel header, or

        (b)  the tunnel packet.

   Both tunnel header and tunnel packet problems are reported to the
   tunnel entry-point node.

   If a tunnel packet problem is a consequence of a problem with the
   original packet, which is the payload of the tunnel packet, then the
   problem is also reported to the source of the original packet.

   To report a problem detected inside the tunnel to the source of an
   original packet, the tunnel entry point node must relay the ICMP
   message received from inside the tunnel to the source of that
   original IPv6 packet.

   An example of the processing that can take place in the error
   reporting mechanism of a node is illustrated in Fig.7, and Fig.8:

   Fig.7 path #0 and Fig.8 (a) - The IPv6 tunnel entry-point receives an
   ICMP packet from inside the tunnel, marked Tunnel ICMPv6 Message in
   Fig.7. The tunnel entry-point node IPv6 layer passes the received
   ICMP message to the ICMPv6 Input. The ICMPv6 Input, based on the ICMP
   type and code [ICMP-Spec] generates an internal "error code".

   Fig.7 path #1 - The internal error code, is passed with the "ICMPv6
   message payload" to the upper-layer protocol - in this case the IPv6
   tunnel upper-layer error input.















Conta & Deering             Standards Track                    [Page 23]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


 +-------+   +-------+   +-----------------------+
 | Upper |   | Upper |   | Upper                 |
 | Layer |   | Layer |   | Layer                 |
 | Proto.|   | Proto |   | IPv6 Tunnel           |
 | Error |   | Error |   | Error                 |
 | Input |   | Input |   | Input                 |
 |       |   |       |   |       Decapsulate     |
 |       |   |       |   |  -->--ICMPv6--#2->--  |
 |       |   |       |   |  |    Payload      |  |
 +-------+   +-------+   +--|-----------------|--+