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.l.templin@xxxxxxxxxx > -----Original Message----- > From: Fernando Gont [mailto:fgont@xxxxxxxxxxxxxxx] > Sent: Tuesday, October 15, 2013 4:30 PM > To: Templin, Fred L; Ronald Bonica; Brian E Carpenter > Cc: 6man Mailing List; ietf@xxxxxxxx; Ray Hunter; 6man- > chairs@xxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > >