Re: [Int-area] IPv6 fragmentation for IPv4

On Tue, May 23, 2017 at 2:19 PM, Joe Touch <touch@isi.edu> wrote:
>
>
> On 5/23/2017 1:45 PM, Templin, Fred L wrote:
>> Hi Joe,
>>
>>> -----Original Message-----
>>> From: Joe Touch [mailto:touch@isi.edu]
>>> Sent: Tuesday, May 23, 2017 1:22 PM
>>> To: Templin, Fred L <Fred.L.Templin@boeing.com>; int-area@ietf.org
>>> Subject: Re: IPv6 fragmentation for IPv4
>>>
>>>
>>>
>>> On 5/23/2017 1:13 PM, Templin, Fred L wrote:
>>>> 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?
>>> 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.
>> 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?
> 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?

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.

>>
>>> Finally, how do you know when you can even use this? Legacy devices
>>> 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.
> IMO, if you've gotten to the point of upgrading a system to speak a new
> variant of IPv4, it ought to be IPv6.
>

+1

Tom

> :-)
>
> Joe
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area