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