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"....
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..
Regards,
Alex
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
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
