Re: [Int-area] IPv6 fragmentation for IPv4

["Templin, Fred L" <[e-mail]>]

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Tuesday, May 23, 2017 1:17 PM
> To: Templin, Fred L <[e-mail]>; [e-mail]
> Subject: Re: IPv6 fragmentation for IPv4
> 
> 
> 
> On 5/23/2017 11:49 AM, Templin, Fred L wrote:
> > Hi Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Tuesday, May 23, 2017 11:01 AM
> >> To: Templin, Fred L <[e-mail]>; [e-mail]
> >> 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 think then it would be the same for both vanilla IPv4 fragmentation
and this hybrid IPv4/6 fragmentation.

> I wonder whether NATs deal with this issue correctly. I doubt either one
> keeps per-ID state.

I heard once long ago about Virtual Fragment Reassembly where the
middlebox collects up fragments until it has all of them, but then
instead of actually reassembling it releases the fragments so that
the final destination has to reassemble. I think it is a cisco thing.
Does anyone know if it is widely deployed?

> (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).

Indeed. 

Thanks - Fred

> Joe
> 
>