On Tue, May 23, 2017 at 2:19 PM, Joe Touch <[email protected]> wrote: > > > 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?
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 > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
