RE: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard

["Templin, Fred L" <[e-mail]>]

Hi Ole,

> -----Original Message-----
> From: Ole Troan [mailto:[e-mail]]
> Sent: Tuesday, October 08, 2013 9:17 AM
> To: Templin, Fred L
> Cc: [e-mail]; IETF-Announce; [e-mail]
> Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt>
> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
> 
> Fred,
> 
> > Hi, I would like to make a small amendment to what I said in my
> > previous message as follows:
> >
> > 4) Section 5, change the final paragraph to:
> >
> >   "As a result of the above mentioned requirements, a packet's header
> >   chain length MUST fit within the Path MTU associated with its
> >   destination.  Hosts MAY discover the Path MTU, using procedures
> such
> >   as those defined in [RFC1981] and [RFC4821]. However, if a host
> does
> >   not discover the Path MTU, it MUST assume the IPv6 minumum MTU of
> >   1280 bytes [RFC2460]. The host MUST then limit each packet's header
> >   chain length to the Path MTU minus 256 bytes in case additional
> >   encapsulation headers are inserted by tunnels on the path."
> 
> I would claim that additional encapsulation headers are already
> considered in the 1280 minimum MTU.
> as in: 1500 - 1280.

It is kind of like that, but what I am concerned about is tunnels
in the path that fragment either because they cannot meet the IPv6
minimum MTU without doing so, or because they are trying to allow
a larger-sized MTU when the path doesn't support it due to the
addition of the encapsulating headers.

Take the simplest case when the host assumes a path MTU of 1280.
If there is a tunnel in the path that crosses another 1280 link,
then the tunnel has to fragment, and the header chain might not
all fit within the first fragment if the host does not allow
headspace room. If the host limits the size of its header chain
to 1280 - 512 = 1024 bytes, then the entire chain should fit
within the first fragment even if there are multiple nested
tunnel ingresses on the path and each one of them fragments.

That said, I am wondering how this document relates to the
discussions we had earlier and the resulting draft from Mark
Andrews on what to do when the header chain spans multiple
fragments? Are we trying to keep the header chain all within
the first fragment or not?

Thanks - Fred
[e-mail]

> cheers,
> Ole