Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Monday, July 01, 2013 3:21 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 > > > > On 7/1/2013 2:50 PM, Templin, Fred L wrote: > > 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 > > You can't know that unless you parse the IPv6 header chain. And adding > SEAL inbetween IPv6 and the inner IPv6 adds one more step to that > chain.
The SEAL first fragment MUST contain at least 256 bytes (or up to the end of the packet) according to the specs. If that is not large enough to include sufficient ULP headers then the packet should probably be dropped anyway. > Either way, DPI has to follow the chain step-by-step, vs. in a single > leap as with IPv4. Right, but how long can those chains be and still be considered a "realistic" IPv6 packet? > > - 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. > > Yes, but support for (vs not interfering with) DPI isn't one of them. This comes to whether it is possible to set a maximum upper bound on the length of a chain of IPv6 extension headers. And, if 256 is too small SEAL the spec can still be changed to push it to 512. Maybe what is needed is a specification of the maximum IPv6 header length the same as we have a specification for the maximum IPv4 header length? I would propose 256 bytes, but I could live with something somewhat larger like 512. > >> 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". > > You can talk to Ron about that. But AFAICT that won't solve the overall > problems his draft is seeking to address (whether they can or should be > addressed is debatable, IMO). > > ... > >>>>>>> Right. That's why IPv6-in-IPv4 transition mechanisms cheat and > >>>>>>> assume 1500 when the specs say they can only assume 576. > >>>>> > ... > >> > >> 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. > > Then your table should have said IPv4 has a minMRU of 1500, but it > doesn't. That's widely deployed, but cannot be assumed. Esp. on > low-powered/low-mem devices. About the 1500/576, I'm just repeating what I read in RFCs 791 and 1122. I think we need to stop debating about IPv4 tunnels. They're widely deployed, and we can't put them back in the bottle. > >> 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. > > I agree that SEAL is better than IP at fragmentation, but it's still a > network fragmentation layer when used for IP tunnels. It doesn't solve > the issues that some are concerned about recently. As we have discussed in the ipv6 list, I am proposing SEAL as a general fragmentation/reassembly framework for all applications and not just tunneling. The SEAL header has the same footprint as IPv6 frag header and can be used for the same purpose, whether it be in tunnel-mode or transport-mode. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
