Hi Fernando, > -----Original Message----- > From: Fernando Gont [mailto:fg...@si6networks.com] > Sent: Friday, October 11, 2013 10:04 AM > To: Templin, Fred L; Ray Hunter; brian.e.carpen...@gmail.com > Cc: 6man Mailing List; ietf@ietf.org > Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> > (Implications of Oversized IPv6 Header Chains) to Proposed Standard > > On 10/11/2013 12:36 PM, Templin, Fred L wrote: > >> FWIW, my idea of the I-D is that it says "look, if you don't put all > >> this info into the first fragment, it's extremely likely that your > >> packets will be dropped". That doesn't mean that a middle-box may > want > >> to look further. But looking further might imply > >> reassemble-inspect-and-refragment... or even reassemble the TCP > stream > >> (e.g. think about a SSL/TCP-based VPN...) > > > > We definitely don't want that. That is why we would prefer for > > the entire header chain (starting from the outermost IP header > > up to and including the headers inserted by the original host) > > to fit within the first fragment even if there are multiple > > encapsulations on the path. > > The problem is that if you have multiple encapsulations, you can always > hit the MTU limit and fail to comply with this requirement.
Yes you can, which is what I just said to Ray. But, I am not talking about a *requirement* - I am talking about a best practice that works in most cases. The question is how many layers of encapsulation do you need? Let's say you want 5 layers of encapsulation. That would still allow enough room for all of the hosts headers to fit in the first fragment if the host limits its header chain to 1024 bytes. But, now let's say that you want 10 layers of encapsulation. That means that the first 5 middleboxes that examine the outermost encapsulations will not be able to see the entire header chain, but the last 5 middleboxes that examine the innermost encapsulations will. So, there is a limit to the levels of defense-in-depth. But, that limit is greater than 1. Remember also that the 1280/1500 also assumed that there would be "just a few" layers of nested encapsulations. What I am suggesting allows for endless recursion but limited (and reasonable) defense in depth. > That's why this I-D says what it says. I'm not sure this discussion was taken into account, and what the draft says now is not friendly to tunnels. > P.S.: Reegarding enforcing a limit on the length of the header chain, I > must say I symphatize with that (for instance, check the last > individual > version of this I-D, and you'll find exactly that). But the wg didn't > want that in -- and I did raise the issue a few times. So what we have > is what the 6man wg had consensus on. It is not too late to get this right, and to give reasonable treatment to tunnels that the current draft does not give. Thanks - Fred fred.l.temp...@boeing.com > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > >
