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]
--------------------------------------------------------------------
