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]

 



Fred,

> To repeat what has already been said many times (and hopefully for
> just one final time), if the host is permitted to include an MTU-sized
> header chain and if there is a tunnel on the path that needs to fragment
> for whatever reason, then that header chain is going to spill into a
> second fragment. Then, middleboxes that wish to examine the entire
> header chain in the first fragment for whatever reason will be unable
> to do so. Consensus or no, those are the facts.

absolutely.

the outer IPv6 header is a new datalink for the inner IPv6 header. there is no architectural difference if that L2 is IPv6, IPv4 or PPP. take IPv4 or PPP as an example, if PPP provides fragmentation, then there is no expectation that the PPP or IPv4 layer keeps the payload IPv6 header chain in one PPP or IPv4 fragment.

the rules in this document are not recursive. the header chain terminates as soon as another IPv6 header is encountered.

does that clarification help?
I'm not quite sure if the document is clear enough on this point.

Best regards,
Ole

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


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