On 5/23/2017 11:49 AM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:[email protected]] >> Sent: Tuesday, May 23, 2017 11:01 AM >> To: Templin, Fred L <[email protected]>; [email protected] >> Subject: Re: IPv6 fragmentation for IPv4 >> >> Hi, Fred (et al.), >> >> On 5/23/2017 9:17 AM, Templin, Fred L wrote: >>> Joe, I wanted to run an idea by you. We all know that IPv4 fragmentation has >>> problems because of the 16-bit ID field. So, why not insert an IPv6 Fragment >>> Header between the IPv4 header and the upper layer protocol data, then >>> use IPv6-style fragmentation instead of IPv4 fragmentation? >> IPv4 fragmentation has several impediments: >> - small ID field >> - lack of a reassembly checksum >> - lack of a fixed-location flow ID >> >> Using IPv6-Frag as the next header solves only the first of these. The >> last is significant - putting a new header would defeat IPv4 flow ECMP >> even for the first fragment. > ECMP gateways could be updated to look at the ULP headers > following the IPv6 Frag header in the first fragment. They could, but...
>> IPv6 includes a flow field that serves this >> purpose. > How does it work for plain-old IPv4 fragmentation? It doesn't. That's part of the problem. > I would think > that ECMP gateways would look at the IP ID and try to associate > the fragments so they all get equal ECMP treatment, i.e., the > same as for vanilla IPv4. AFAICT, they largely either drop fragments or send them based on the base IPv4 header. I wonder whether NATs deal with this issue correctly. I doubt either one keeps per-ID state. (FWIW, IMO, anything that needs to look past the IP header really ought to reassemble - if you think that's not something an IP router should do, neither do I - but then I don't think routers should be looking past the IP header either). Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
