Subject: [Int-area] IPv6 fragmentation for IPv4

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 May 2017 16:17:07 +0000

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?

So, the IPv4 Protocol field would be set to '44', the IPv4 header would be
followed by an IPv6 Fragment Header, and the "Next Header" field in the
IPv6 Fragment Header would be set to the Protocol Number for the upper
layer protocol. Then, upon fragmentation, each fragment would have an
IPv4 header followed by an IPv6 Fragment Header.

This format is shown in Figure 6 in Appendix A of the AERO draft:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

Does this look like something that should be broken out and put into a
little standalone document?

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Tue, 23 May 2017 10:38:12 -0700

> use IPv6-style fragmentation instead of IPv4 fragmentation?
Hi Fred,

What is the use case for this? Unlike IPv6, IPv4 fragmentation can be
done a routers so this technique wouldn't work in that case. If the
fragmentation is occurring at tunnel ingress its probably just as easy
to fragment as part of the encapsulation like we do in GUE.

Tom

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 May 2017 17:44:04 +0000

Hi Tom,

I am thinking about source-fragmentation only, then send all fragments with
DF=1 so they won't be further fragmented in the network.

One use case would be for IP-in-IPv4 tunneling when there is no GUE header.
I haven't thought much about other use cases, but it should apply to any IP/X
encapsulations (X could be TCP, for example).

Thanks - Fred

> -----Original Message-----
> From: Tom Herbert [mailto:[email-masked]]
> Sent: Tuesday, May 23, 2017 10:38 AM
> To: Templin, Fred L <[email-masked]>
> Cc: [email-masked]; Joe Touch <[email-masked]>
> Subject: Re: [Int-area] IPv6 fragmentation for IPv4
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 23 May 2017 10:59:06 -0700

> encapsulations (X could be TCP, for example).
Introducing extension headers in IPv4 might be opening a can of worms.
Could this be done in a new IPv4 option?

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 May 2017 11:00:40 -0700

Hi, Fred (et al.),

> 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. IPv6 includes a flow field that serves this
purpose.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 May 2017 11:02:51 -0700

> Could this be done in a new IPv4 option?
Only if you want it dropped by routers.

IPv4 doesn't define a flag that says "ignore this option if it isn't
supported".

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 May 2017 18:49:28 +0000

Hi Joe,

> From: Joe Touch [mailto:[email-masked]]
> Sent: Tuesday, May 23, 2017 11:01 AM
> To: Templin, Fred L <[email-masked]>; [email-masked]
> Subject: Re: IPv6 fragmentation for IPv4
> 
> Hi, Fred (et al.),
> 
> 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.

> IPv6 includes a flow field that serves this
> purpose.

How does it work for plain-old IPv4 fragmentation? 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.

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 May 2017 20:13:13 +0000

Joe,

> From: Int-area [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Tuesday, May 23, 2017 11:49 AM
> To: Joe Touch <[email-masked]>; [email-masked]

Here's another think - since the IPv6 Frag Header already has a
32-bit IP ID that we are using for fragmentation, and since we
are asking the IPv4 header to set DF=1, the 16-bit IP ID field in
the IPv4 header is available for use as a flow field - right?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 May 2017 13:17:21 -0700

> following the IPv6 Frag header in the first fragment.
They could, but...

> How does it work for plain-old IPv4 fragmentation? 
It doesn't. That's part of the problem.

> I would think
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

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 May 2017 13:21:43 -0700

> the IPv4 header is available for use as a flow field - right?
Except for all those devices that look only at the IPv4 header. In that
case, redefining the IPv4 header this way could interfere with
mechanisms to manage NAT traversal based based on ID context.

Finally, how do you know when you can even use this? Legacy devices
could choke on such packets - whether routers or endpoints.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 May 2017 13:21:45 -0700

They could, but...

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 23 May 2017 13:24:59 -0700

> the IPv4 header is available for use as a flow field - right?
Fred,

I think this would over kill. Assuming fragmentation remains the rare
case, getting the ECMP hash over the addresses should be sufficient.
ECMP is a performance optimization, once you're fragmenting that's
already giving up a lot.

Tom

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 May 2017 20:41:03 +0000

Hi Joe,

> Sent: Tuesday, May 23, 2017 1:17 PM

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

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?

> do, neither do I - but then I don't think routers should be looking past

Indeed. 

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 May 2017 20:45:41 +0000

Hi Joe,

> Sent: Tuesday, May 23, 2017 1:22 PM

What was it that your document said about the setting of IP ID when
DF=1? Shouldn't it be OK to set the ID to some value of our own
choosing, e.g., a hash of the 5-tuple of the original packet?

> could choke on such packets - whether routers or endpoints.

That is a real concern, yes. For the same reason that new transports
like SCTP and DCCP have been proven difficult to deploy. With this
proposal, ip-proto-44 would be just another protocol that middleboxes
block. But, maybe it would work in private internetworks such as
an enterprise network.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 May 2017 20:47:08 +0000

Hi Tom,

> Sent: Tuesday, May 23, 2017 1:25 PM
> Cc: Joe Touch <[email-masked]>; [email-masked]

Yes, I don't disagree. But writing a hash of the 5-tuple in the IPv4
ID field of each fragment (and setting DF=1) shouldn't be so hard.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 May 2017 14:19:11 -0700

> choosing, e.g., a hash of the 5-tuple of the original packet?
If DF=1, then the ID should be ignored everywhere.

That's also consistent with the uses that were reported about some
systems just setting DF=1 and using a single ID.

It can't indicate a flow unless you know the next proto=44. But then why
not make next proto=(new number) and just put a proper flow ID (and
reassembly) there?
> block. But, maybe it would work in private internetworks such as
IMO, if you've gotten to the point of upgrading a system to speak a new
variant of IPv4, it ought to be IPv6.

:-)

Joe

---

From: Bob Hinden <[email-masked]>
Date: Tue, 23 May 2017 15:45:10 -0700

>> block. But, maybe it would work in private internetworks such as

Upgrading enterprise networks isn’t so easy these days.  They have many different kinds of devices (some owned by the enterprise, some BYOD) each with different software.  It’s one thing to push out an application, changing the IP stack is difficult.

> variant of IPv4, it ought to be IPv6.

+1

Especially, since most devices have IPv6 already.

Bob

---

From: Tom Herbert <[email-masked]>
Date: Tue, 23 May 2017 19:38:19 -0700

> not make next proto=(new number) and just put a proper flow ID (and

Alternatively, you could encapsulate in GUE with fragmentation option.
Then the packet is UDP/IP which makes intermediate devices happy and
ECMP is taken care of. The receiver needs to be running GUE, but that
is a much easier task than deploying a protocol.

+1

Tom