Vlad,
In RFC 2473, page 14:
"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:...."
".....(Note that this requirement 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.)"
Please note the "exception".
Further, or once more:
The "tunnel encapsulation limit", along with the forwarding/routing and
hop limit information, is part of the "control" information stored by a
tunnel entry-point in the tunnel headers. This information
is used/processed by the nodes in the tunnel, downstream from the tunnel
entry-point, to appropriately forward the tunnel packets towards the
tunnel exit point.
The forwarding/routing information and hop limit in the IPv6 main header
is processed by each and every node. The forwarding/routing information
in a routing header is processed by the nodes which are part of the
source route. The tunnel encapsulation limit is processed by entry-point
nodes in inner nested tunnels, and ignored by other nodes.
Ideally, a tunnel entry-point would specify each tunnel entry point in
inner nested tunnels in a
tunnel routing header. This is however impractical, as a tunnel entry
point MAY not know all the downstream entry-points to inner nested
tunnels. Nevertheless, all entry-points in inner nested tunnels, which
in extremus can be all nodes in a tunnel, MUST have access to the tunnel
encapsulation limit, to avoid the effect of infinite encapsulation. The
tunnel encapsulation limit carried by the tunnel headers of a packet
MUST be put in the tunnel headers of every fragment of that packet, when
the packet gets fragmented.
To conclude, in the context of RFC2473 explained above, the statement in
RFC 2460
" The Unfragmentable Part consists of the IPv6 header plus any
extension headers that must be processed by nodes en route to
the
destination"....
applies fully. Its explanation:
"that is, all headers up to and including the Routing
header if present, else the Hop-by-Hop Options header if
present,
else no extension headers."
if it is to be interpreted strictly ad literam, is excepted.
Alex
Vladislav Yasevich wrote:
>
> Alex
>
> Alex Conta wrote:
> >
> > Thank you for your note Vlad.
> >
> > The interpretation of the RFC 2473 should be done in the context of RFC 2460. Two
> > pieces of text are perhaps more important than others:
> >
> > RFC 2473
> > "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:..."
> >
> > RFC 2460
> > " The Unfragmentable Part consists of the IPv6 header plus any
> > extension headers that must be processed by nodes en route to the
> > destination"....
>
> to continue the paragraph:
> "... destination, that is, all headers up to and including the Routing
> header if present, else the Hop-by-Hop Options header if present,
> else no extension headers."
>
> Also from RFC 2460:
> } "4.1 Extension Header Order
> }
> } When more than one extension header is used in the same packet, it is
> } recommended that those headers appear in the following order:
> }
> } IPv6 header
> } Hop-by-Hop Options header
> } Destination Options header (note 1)
> } Routing header
> } Fragment header
> } Authentication header (note 2)
> } Encapsulating Security Payload header (note 2)
> } Destination Options header (note 3)
> }
> } note 1: for options to be processed by the first destination
> } that appears in the IPv6 Destination Address field
> } plus subsequent destinations listed in the Routing
> } header.
> } ...
> } note 3: for options to be processed only by the final
> } destination of the packet.
> }
> } ...
> } 4.6 Destination Options Header
> }
> } The Destination Options header is used to carry optional information
> } that need be examined only by a packet's destination node(s)...."
>
> Thus, my statement that if you only specify the Destination Option Header (with
> tunnel encapsulation limit option and any other options), then they will go into
> the Fragmentable Part on the packet as per 2460. They will only be in the
> Unfragmentable Part if you specify a Routing Header after the Destination
> Options.
>
> >
> > So, in implementing RFC 2473, particularly the "tunnel encapsulation limit", one
> > must take in consideration the fact that:
> >
> > 1.. the "tunnel encapsulation limit" is part of the tunnel headers - this affects
> > the PMTU calculation, and thus fragmentation.
> > 2.. the information carried by the "tunnel encapsulation limit" may be, at an
> > extreme, significant to every node in the tunnel, if every node in the tunnel is a
> > tunnel entry point. Which means that it may be processed at that extreme, like a
> > "hop by hop" header.
> > 3. the "tunnel encapsulation limit" is part of the "control" information carried by
> > the tunnel headers, addressed to
> > the downstream tunnel nodes, therefore it MUST be available to each and every
> > downstream node in the tunnel, at and for the processing of each and every tunnel
> > header and packet generated by the upstream tunnel entry point..
>
> The tunnel encapsulation header in addressed to the tunnel exit point, not the
> inner tunnels' entry point. Thus, since the inner tunnels' entry point is not
> the destination, then it will not examine the Destination Option header. Also,
> since the packet may be fragmented, it will not be able to examine the
> Destination
> Option Header as I described above. For each tunnel entry point to examine the
> Destination Option header, a Routing Header must be specified after the
> Destination Option Header that would list each tunnel entry point.
>
> Otherwise, you create a special rule on how to process the Destination Option
> Header
> that conatins "tunnel encapsulation limit" option.
>
> >
> > Regards,
> > Alex
>
> -Vlad
>
> >
> > Vladislav Yasevich wrote:
> >
> > > Hello
> > >
> > > After discussing this with a colleague who is trying to implement this spec
> > > I believe there may be a problem with defining Tunnel Encapsulation Limit Option
> > > as a Destination Option. When the packet is fragmented, the destination option
> > > header can be placed in the fragment if no routing header is present in the
> > > packet.
> > >
> > > Now, if you have nested tunnels, entry point for each tunnel will be doing
> > > fragmentation. So, the first tunnel entry point will encapsulate the original
> > > packet, add the destination option, and then fragment to path MTU, palcing
> > > the destination option in one of the fragments. For the inner tunnel
> > > to correctly process the Tunnel Encapsulation Limit Option, the inner
> > > tunnel entry points will have to reassemble the packet, but there is
> > > no guarantee that it will have all the framents.
> > >
> > > There are 3 solutions to this that I can see.
> > > 1. Each entry point will have to add a routing header.
> > > - this is not very clean.
> > > 2. Use Hop by Hop option.
> > > 3. Invent another tunnel specific extension header that will
> > > be placed in every fragment.
> > >
> > > -vlad
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > Vladislav Yasevich Tel: (603) 884-1079
> > > Compaq Computer Corp. Fax: (435) 514-6884
> > > 110 Spit Brook Rd ZK03-3/T07
> > > Nashua, NH 03062
>
> --
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
> Vladislav Yasevich Tel: (603) 884-1079
> Compaq Computer Corp. Fax: (435) 514-6884
> 110 Spit Brook Rd ZK03-3/T07
> Nashua, NH 03062
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
