Hi Brian, On Mon, Mar 4, 2019 at 5:37 PM Brian E Carpenter <[email protected]> wrote: > > Hi, > Hi Brian,
Thanks for the comments! > This is an interesting draft, but I must say I have serious doubts about > the IETF working on any significant update to IPv4 at the IP header level, > or of any such updates ever making it into the operational network. > I understand the concern. It's probably true that extension headers in IPv4 wouldn't be very usable in today's Internet. Undoubtedly, many middleboxes would block them. But that's not because middleboxes are concerned about a threat of extension headers in IPv4, it's more because some middleboxes drop packets with any protocols they don't understand (pretty much leaving only TCP and UDP as being usable protocols on the Internet). There are some potential mitigations to be pointed out: - IPv4 already supports at least two extension headers, namely ESP and AH. They might not be called extension headers, but they have the same format and function as IPv6 cognates. - There's no concept of HBH options in IPv4 as needing to be processed by every node in the path, so the relaxed processing requirement of RFC8200 can be set from the start without legacy issues. - This doesn't actually change IP header, it is just enabling new values in the protocol field. In a host implementation this is very straightforward and in some ways it's a simplification to to be more like IPv6. - UDP encapsulation of extension headers could serve to make extension headers transparent to middleboxes. - It is conceivable to only allow extension headers in UDP encapsulation thereby eliminating the problem of making a core update to IPv4. IPv4 extension headers would be defined as part of an encapsulation protocol. - IPv4 extension headers could be another use case for limited domains. > On the other hand, I think the idea of a UDP encapsulation of extension > headers is very interesting. I'm not sure I understand all the implications > yet, and I'm not sure why the format can't be defined simply by a normative > reference to RFC8200. The idea of having a duplicate format definition > is a bit scary. Some implications are described in the document. When encapsulating transport packets within UDP the IP header for the encapsulated transport header needs to be deterministic, how to deal with NAT and encapsulated transport checksum needs a solution. Intermediate nodes parsing HBH embedded options is tricky since that requires them to inspect UDP payloads and potential modify the payload. For that, a magic number is used to minimize the possibility of misinterpretation of UDP payload type. If you think of other implications please bring them up. I'm not sure what the comment on duplicate format definition refers to. Perhaps this is about the the description of extension headers for IPv4 in the draft? Thanks, Tom > > Regards > Brian Carpenter > > On 28-Feb-19 09:19, [email protected] wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : IPv4 Extension Headers and UDP Encapsulated > > Extension Headers > > Author : Tom Herbert > > Filename : draft-herbert-ipv4-udpencap-eh-00.txt > > Pages : 27 > > Date : 2019-02-27 > > > > Abstract: > > This specification defines extension headers for IPv4 and a method to > > encapsulate extension headers in UDP to facilitate transmission over > > the Internet. The goal is to provide a uniform and feasible method of > > extensibility that is shared between IPv4 and IPv6. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-herbert-ipv4-udpencap-eh/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-herbert-ipv4-udpencap-eh-00 > > https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-udpencap-eh-00 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
