I also strongly oppose closing the IPv4 options registry. The reference cited does not address the use of IPv4 options within a local subnet where they work just fine. I do agree that, from a practical standpoint, routing IPv4 options on the open Internet is forever broken. But not every use of Ethernet involves routers. Also, note that the router alert option is not just widely used, but necessary for multi-cast; so, you can't just make the claim that there is no such thing as a useful IPv4 option.
Also, there won't be any new options unless this group approves them; so, there is no point to putting out an RFC which either does nothing or becomes wrong as soon as someone comes up with an actual use case where they will work (like for performance improvements on a local subnet). I think it would be useful to say there is a policy that there can't be a new IPv4 option without also defining an IPv6 one (to be up-to-date and solve the routing issue). I should also point out that if both an IPv4 and IPv6 version is defined and users find it useful, it might encourage users who would not otherwise switch to IPv6 to switch. Let's take an example of a useful IPv4 option that does work on a local subnet. When I manage to get enough time to do it, I plan on revising this MCPHINT draft: https://datatracker.ietf.org/doc/draft-robinson-intarea-mcphint/. Do not review this, it's only being presented as an example of a potential IPv4 option that works. My testing of this resulted in 10G/sec IPSec performance between two hosts on the same subnet and that was limited by the 10G Ethernet interface, not CPU. The potential is greater. And it's fairly easy to implement. I have customers who can and will take advantage of this on their local networks. If they want to route it, I can tell them to take it up with their router vendors or use IPv6. Note that my draft does define IPv4 and IPv6 versions of the option to make sure routing is supported (the new rev will not use HBH) and it has been specifically designed to support hardware routing. I have been holding off on updating the MCPHINT spec, because my employer insisted on patenting it and I didn't want to waste anyone's time until the patent went through. The updated draft is coming soon and, unless they changed their mind, my employer plans on making the patent free (it is not my call to approve that). > -----Original Message----- > From: Brian E Carpenter <[email protected]> > Sent: Tuesday, June 16, 2026 4:49 PM > To: [email protected] > Subject: [Int-area] Re: Closing/updating IPv4-only registries (FW: New Version > Notification for draft-vyncke-intarea-legacy-registries-00.txt) > > Penguin Solutions Security Checkpoint: External email. Please make sure you > trust this source before clicking links or opening attachments. > > On 17-Jun-26 03:24, Pinkert, Tjeerd wrote: > > Dear Eric, > > > > I strongly oppose to closing the IPv4 options registry without alternative > means of providing similar features on the network layer level (IP protocol). > > > > As you know there have been several I-Ds the last years requesting IPv4 > > option > numbers, that were refuted/demoted “because IPv4 options are not an option”. > > They weren't an option in 2005, as the reference shows, and they weren't an > option in 1994 on the only occasion that I proposed one. The Internet has been > opaque to IPv4 options for more than 30 years and that isn't going to change. > _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
