On 5/23/2017 1:45 PM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:[email protected]] >> Sent: Tuesday, May 23, 2017 1:22 PM >> To: Templin, Fred L <[email protected]>; [email protected] >> 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? > >> 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. :-) Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
