Hi Fernando,
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.
Thanks - Fred
fred(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com
-----Original Message-----
From: Fernando Gont [mailto:fgont(_at_)si6networks(_dot_)com]
Sent: Tuesday, October 15, 2013 4:30 PM
To: Templin, Fred L; Ronald Bonica; Brian E Carpenter
Cc: 6man Mailing List; ietf(_at_)ietf(_dot_)org; Ray Hunter; 6man-
chairs(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt>
(Implications of Oversized IPv6 Header Chains) to Proposed Standard
On 10/14/2013 02:39 PM, Templin, Fred L wrote:
Is there a way to decouple this discussion from draft-ietf-6man-
oversized-header-chain? I would be glad to discuss it in the context
of
a separate draft.
I don't know if there is a way to decouple it. I believe I have shown
a way to not mess up tunnels while at the same time not messing up
your
draft. That should be a win-win. In what way would imposing a 1K
limit
on the IPv6 header chain not satisfy the general case?
6man had consensus multiple times on *not* to impose this sort of
limits
in this document (that's why the original limit of 1280 bytes was
removed from earlier versions of this I-D in the first place).
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492