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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Brian,

> The draft mitigates a known problem with communication paths that
> do not include nested tunnels requiring nested fragmentation,
> where the nested tunnel has to deal with an MTU <1280 *and* where
> the nested tunnel goes through a firewall that wants to analyse
> the complete header chain of the innermost packet.

I want to say one more word on this. You seem to be indicating that
you see what I have been explaining as a corner case. But, I believe
that in order to fix the tunnel MTU issue we will need SEAL or
something very much like it.

SEAL uses fragmentation on the first few packets regardless of the
path MTU to ensure that "middle sized" packets between 1280-1500
get through. It then turns off the fragmentation using a probing
scheme in the spirit of RFC4821. So, those first few packets that
could contain a header chain that spills over into the second
fragment are what concerns me. And, this will not be a corner
case when SEAL is used in wider deployment.

Thanks - Fred
fred.l.templin@xxxxxxxxxx






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]