rfc2473.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,626 行 · 第 1/5 页

   The increase in the size of a tunnel IPv6 packet due to nested
   encapsulations may require fragmentation [IPv6-Spec] at a tunnel
   entry point - see section 7.  Furthermore, each fragmentation, due to
   nested encapsulation, of an already fragmented tunnel packet results
   in a doubling of the number of fragments.  Moreover, it is probable
   that once this fragmentation begins, each new nested encapsulation
   results in yet additional fragmentation.  Therefore limiting nested
   encapsulation is recommended.

   The proposed mechanism for limiting excessive nested encapsulation is
   a "Tunnel Encapsulation Limit" option, which is carried in an IPv6
   Destination Options extension header accompanying an encapsulating
   IPv6 header.








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


4.1.1 Tunnel Encapsulation Limit Option

   A tunnel entry-point node may be configured to include a Tunnel
   Encapsulation Limit option as part of the information prepended to
   all packets entering a tunnel at that node.  The Tunnel Encapsulaton
   Limit option is carried in a Destination Options extension header
   [IPv6-Spec] placed between the encapsulating IPv6 header and the IPv6
   header of the original packet.  (Other IPv6 extension headers may
   also be present preceding or following the Destination Options
   extension header, depending on configuration information at the
   tunnel entry-point node.)

   The Tunnel Encapsulation Limit option specifies how many additional
   levels of encapsulation are permitted to be prepended to the packet
   -- or, in other words, how many further levels of nesting the packet
   is permitted to undergo -- not counting the encapsulation in which
   the option itself is contained.  For example, a Tunnel Encapsulation
   Limit option containing a limit value of zero means that a packet
   carrying that option may not enter another tunnel before exiting the
   current tunnel.

   The Tunnel Encapsulation Limit option has the following format:

      Option Type     Opt Data Len   Opt Data Len
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 1 0 0|       1       | Tun Encap Lim |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Option Type decimal value 4

                       - the highest-order two bits - set to 00 -
                       indicate "skip over this option if the option is
                       not recognized".

                        - the third-highest-order bit - set to 0 -
                       indicates that the option data in this option
                       does not change en route to the packet's
                       destination [IPv6-Spec].

      Opt Data Len value 1 - the data portion of the Option is one octet
                       long.

      Opt Data Value the Tunnel Encapsulation Limit value - 8-bit
                       unsigned integer specifying how many further
                       levels of encapsulation are permitted for the




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


   Tunnel Encapsulation Limit options are of interest only to tunnel
   entry points.  A tunnel entry-point node is required to execute the
   following procedure for every packet entering a tunnel at that node:

        (a)  Examine the packet to see if a Tunnel  Encapsulation  Limit
             option is present following its IPv6 header.  The headers
             following the IPv6 header must be examined in strict
             "left-to-right" order, with the examination stopping as
             soon as any one of the following headers is encountered:
             (i) a Destination Options extension header containing a
             Tunnel Encapsulation Limit, (ii) another IPv6 header, (iii)
             a non-extension header, such as TCP, UDP, or ICMP, or (iv)
             a header that cannot be parsed because it is encrypted or
             its type is unknown.  (Note that this requirment is an
             exception to the general IPv6 rule that a Destination
             Options extension header need only be examined by a
             packet's destination node.  An alternative and "cleaner"
             approach would have been to use a Hop-by-Hop extension
             header for this purpose, but that would have imposed an
             undesirable extra processing burden, and possible
             consequent extra delay, at every IPv6 node along the path
             of a tunnel.)

        (b) If a Tunnel Encapsulation Limit option is found in the
             packet entering the tunnel and its limit value is zero, the
             packet is discarded and an ICMP Parameter Problem message
             [ICMP-Spec] is sent to the source of the packet, which is
             the previous tunnel entry-point node.  The Code field of
             the Parameter Problem message is set to zero ("erroneous
             header field encountered") and the Pointer field is set to
             point to the third octet of the Tunnel Encapsulation Limit
             option (i.e., the octet containing the limit value of
             zero).

        (c) If a Tunnel Encapsulation Limit option is found in the
             packet entering the tunnel and its limit value is non-zero,
             an additional Tunnel Encapsulation Limit option must be
             included as part of the encapsulating headers being added
             at this entry point.  The limit value in the encapsulating
             option is set to one less than the limit value found in the
             packet being encapsulated.

        (d) If a Tunnel Encapsulation Limit option is not found in the
             packet entering the tunnel and if an encapsulation limit
             has been configured for this tunnel, a Tunnel Encapsulation
             Limit option must be included as part of the encapsulating
             headers being added at this entry point.  The limit value
             in the option is set to the configured limit.



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


        (e)  If a Tunnel Encapsulation Limit option is not found in  the
             packet  entering  the  tunnel and if no encapsulation limit
             has  been  configured  for  this  tunnel,  then  no  Tunnel
             Encapsulation  Limit  option  is  included  as  part of the
             encapsulating headers being added at this entry point.

   A Tunnel Encapsulation Limit option added at a tunnel entry-point
   node is removed as part of the decapsulation process at that tunnel's
   exit-point node.

   Two cases of encapsulation that should be avoided are described
   below:

4.1.2 Loopback Encapsulation

   A particular case of encapsulation which must be avoided is the
   loopback encapsulation.  Loopback encapsulation takes place when a
   tunnel IPv6 entry-point node encapsulates tunnel IPv6 packets
   originated from itself, and destined to itself.  This can generate an
   infinite processing loop in the entry-point node.

   To avoid such a case, it is recommended that an implementation have a
   mechanism that checks and rejects the configuration of a tunnel in
   which both the entry-point and exit-point node addresses belong to
   the same node. It is also recommended that the encapsulating engine
   check for and reject the encapsulation of a packet that has the pair
   of tunnel entry-point and exit-point addresses identical with the
   pair of original packet source and final destination addresses.

4.1.3 Routing-Loop Nested Encapsulation

   In the case of a forwarding path with multiple-level nested tunnels,
   a routing-loop from an inner tunnel to an outer tunnel is
   particularly dangerous when packets from the inner tunnels reenter an
   outer tunnel from which they have not yet exited. In such a case, the
   nested encapsulation becomes a recursive encapsulation with the
   negative effects described in 4.1.  Because each nested encapsulation
   adds a tunnel header with a new hop limit value, the IPv6 hop limit
   mechanism cannot control the number of times the packet reaches the
   outer tunnel entry-point node, and thus cannot control the number of
   recursive encapsulations.

   When the path of a packet from source to final destination includes
   tunnels, the maximum number of hops that the packet can traverse
   should be controlled by two mechanisms used together to avoid the
   negative effects of recursive encapsulation in routing loops:





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


        (a)  the original packet hop limit.

             It is decremented at each forwarding operation performed on
             an original packet. This includes each encapsulation of the
             original packet. It does not include nested encapsulations
             of the original packet

        (b)  the tunnel IPv6 packet encapsulation limit.

             It is decremented at each nested encapsulation of the
             packet.

   For a discussion of the excessive encapsulation risk factors in
   nested encapsulation see Appendix A.

5. Tunnel IPv6 Header

   The tunnel entry-point node fills out a tunnel IPv6 main header
   [IPv6-Spec] as follows:

          Version:

            value 6

          Traffic Class:

            Depending on the entry-point node tunnel configuration, the
            traffic class can be set to that of either the original
            packet or a pre-configured value - see section 6.4.

          Flow Label:

            Depending on the entry-point node tunnel configuration, the
            flow label can be set to a pre-configured value. The typical
            value is zero - see section 6.5.

          Payload Length:

            The original packet length, plus the length of the
            encapsulating (prepended) IPv6 extension headers, if any.

          Next Header:

            The next header value according to [IPv6-Spec] from the
            Assigned Numbers RFC [RFC-1700 or its successors].

            For example, if the original packet is an IPv6 packet, this
            is set to:



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


                 - decimal value 41 (Assigned Next Header number for
                 IPv6) - if there are no tunnel extension headers.

                 - value 0 (Assigned Next Header number for IPv6 Hop by
                 Hop Options extension header) - if a hop by hop options
                 extension header immediately follows the tunnel IPv6
                 header.

                 - decimal value 60 (Assigned Next Header number for
                 IPv6 Destination Options extension header) - if a
                 destination options extension header immediately
                 follows the tunnel IPv6 header.

          Hop Limit:

            The tunnel IPv6 header hop limit is set to a pre-configured
            value - see section 6.3.

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

          Source Address:

            An IPv6 address of the outgoing interface of the tunnel
            entry-point node.  This address is configured as the tunnel
            entry-point node address - see section 6.1.

          Destination Address:

            An IPv6 address of the tunnel exit-point node. This address
            is configured as the tunnel exit-point node address - see
            section 6.2.

5.1 Tunnel IPv6 Extension Headers

   Depending on IPv6 node configuration parameters, a tunnel entry-point
   node may append to the tunnel IPv6 main header one or more IPv6
   extension headers, such as a Hop-by-Hop Options header, a Routing
   header, or others.









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


   To limit the number of nested encapsulations of a packet, if it was
   configured to do so - see section 6.6 - a tunnel entry-point includes
   a Destination Options extension header containing a Tunnel
   Encapsulation Limit option. If that option is the only option present
   in the Destination Options header, the header has the following
   format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |Hdr Ext Len = 0| Opt Type = 4  |Opt Data Len=1 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Tun Encap Lim |PadN Opt Type=1|Opt Data Len=1 |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Next Header:

            Identifies the type of the original packet header.  For
            example, if the original packet is an IPv6 packet, the next
            header protocol value is set to decimal value 41 (Assigned
            payload type number for IPv6).