Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Monday, July 01, 2013 2:34 PM > To: Templin, Fred L > Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area > Subject: Re: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt > > Cutting to the chase... > > On 7/1/2013 2:18 PM, Templin, Fred L wrote: > > If we deprecate IP fragmentation but then at the same time replace > > it with SEAL we will still have the functionality that we need. > > That's replacing fragmentation with fragmentation. The only reason to > want to get rid of fragmentation is to simplify endpoints and/or > simplify forwarding that does DPI. SEAL won't help either of those.
SEAL helps with the DPI because it makes sure that the ULP headers appear in the first fragment - there is no possible way to construct a "runt" first fragment with SEAL. SEAL also takes care of the overlapping fragments attack vector. There is a growing laundry list of other complaints about IP fragmentation (e.g., Identification field length and ID setting strategy) that do not apply to SEAL. > Further, we *have* fragmentation now. Getting rid of it would be > premature until SEAL is required and widely deployed. SEAL is compatible with IP fragmentation, so we can transition to SEAL without having to first decommission IP fragmentation. So, maybe the document should advocate "SEAL transition" rather than "IP fragmentation deprecation". > >>>> > >> > RFC2473 acknowledges > >>>>> > >>>this by using fragmentation at the ingress as a limiting > >>>>> > >>>condition for when the MTU within the tunnel becomes too > >>>>> > >>>small. This can happen for example if there is a 1280 MTU > >>>>> > >>>link within the tunnel, if there are nested encapsulations > >>>>> > >>>within the tunnel, etc. > >>>> > >> > >>>> > >>Yes, but if minMRU == minMTU, then the number of > encapsulations > >>>> > >>supported is zero. > >>> > > > >>> > >Right. That's why IPv6-in-IPv4 transition mechanisms cheat and > >>> > >assume 1500 when the specs say they can only assume 576. > >> > > >> >Agreed. That's why we need*realistic* numbers for that, not merely > >> >those that reflect what's implemented (e.g., for IPv4). > > > > Right, but what I am ultimately after is an unlimited tunnel > > MTU (I think you were on board with this idea from earlier > > discussion). The only difference is that I want fragmentation > > and reassembly out to 1500 bytes only, and then let the bigger > > packets go through unfragmented as long as they fit. "Take care > > of the smalls, and let the bigs take care of themselves." > > We don't disagree on IPv6. My claim is that for IPv4 it is *necessary* > that endpoints support MTUs lower than 567 to allow IPv4 fragmentation > to support IPv4-in-IPv4 tunnels, including IPsec. I think there is way too much deployed base out there now that boldly assumes 1500 that it would be impossible to put them back in the bottle now. > There are two solutions, of course - deploying SEAL would be the other. > But I would expect that fixing incorrect implementations of an existing > standard would be a lot easier than getting new code deployed for > something that isn't yet standard. There are too many compelling reasons to migrate away from IP fragmentation and move toward SEAL. Maybe also look at some of the discussion on the IPv6 list so we can avoid duplication. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
