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

[Fernando Gont <[e-mail]>]

Hi, Fred,

Thanks so much for your feedback! -- Please find my comments in-line...

On 10/08/2013 03:33 PM, Templin, Fred L wrote:
>> 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, 

Well, at least in theory, the tunnel could do Path-MTU... In which case,
if the underlying MTU is of, say, 1500 bytes, then you can probably go
through several layers of encapsulation, without problem.

Besides, while one would probably would nto phrase it like this, truth
is that even 512 f headers would be pretty much non-sensical: Headers
are overhead. So at the point in which you have 50$ of overhead in every
single packet, it starts looking that the inforation is probably being
conveyed in thr wrong place.

That is, in the real world, you would not even get to 1K headers even
ater several layers of encapsulation.


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

Yes.

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1