On 06-Mar-19 05:42, Tom Herbert wrote: > 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?
Yes. I'd rather see them defined as IPv6 extension headers patched for IPv4, with no duplication of other parts of the definitions. Otherwise there'll be a risk of them drifting apart. Brian > > 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
