Hi Tjeerd, Please note that the draft does not close the IPv4 options registry (even if this was my initial intent), it only set the currently unspecified registration procedure to "IESG approval". The text has currently a non normative text to set the expectation right `it is expected that the IESG won't approve any new IPv4 option`. This text can be removed anyway or be replaced by `IESG approval will require exceptional use case` or something similar.
I will request "call for adoption" and after the WG adoption, it is up to the WG (and not up to me as author) to set the text. A WGLC will ensure the consensus. Having written the above, for your IPv4 use case, did you consider alternatives ? Such as a specific IPv[46] protocol, UDP port, or simply using the *existing* IPv4 experimental options ? Regards Mvg, -éric (the above written as a individual contributor, i.e., without my AD hat) From: Pinkert, Tjeerd <[email protected]> Date: Tuesday, 16 June 2026 at 17:25 To: Eric Vyncke (evyncke) <[email protected]>; [email protected] <[email protected]> Subject: RE: Closing/updating IPv4-only registries (FW: New Version Notification for draft-vyncke-intarea-legacy-registries-00.txt) 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”. (draft-gafni-ippm-ioam-ipv4-options-00, draft-pinkert-ippm-ip-measurement-option-03) These I-Ds certainly have relevance for use in limited domains, but also over the internet at large. I have the feeling that IPv4 will still be long in existence (another 50 years would not be impossible) so keeping open the flexibility of extending an IPv4 header should be kept alive, and be used. As seen in RFC 6274 it is mainly network owners that do not embrace all IPv4 options, which partially have issues. Blocking of IP options for those, and those options only, is justified, and many routers contain the possibility to selectively block IP options. Note also that this RFC totally debunks the myth that silicon implementations for variable header sizes are not possible, which is also generally used to defame IP options. This is why IPv4 options *appear* broken, but not all IPv4 options are bad, or IMHO, IPv4 options are not at all bad when defined well. Sane IPv4 options, without DoS attack surface or processing penalties (i.e. those that are to be passively transferred by the network) still have valid use cases. In my opinion, the IP option number registry should stay available for such options. IPv4 options have two serious problems for which a solution should be found: 1. The limited number of IP option numbers available due to the option classes that are currently not used. It would be good to propose new numbering rules, where the sections are removed and a 7-bit IPv4 option number space comes into existence. This should be backward compatible with implementations, if not, then an IPv4 option signalling new option definitions can be created. (type + length + (optional) option table numbers (to open up more number space when needed) ) The drawback being that this would eat space in the already limited (10 word) maximum space available. 2. Single octet IP options are a no-go, since unknown options cannot be skipped. All new IPv4 options should contain a type+length definition for approval by the IETF. I would favour it, when rules for the sane use of IPv4 options, in line with RFC 6274 and addressing the weaknesses in the IPv4 option definition, would be fixed in an own RFC concerning only this topic. This should, in my opinion, be possible without breaking backward compatibility, and it would open up the possibility for sane use of IPv4 options in the future, even on the global internet. Alternative means could, in my opinion, be extension headers for IPv4, in a similar way that they are defined for IPv6. At the moment, I deem it to early to close the IP options registry finally and definitely, and still see a bright future for IPv4 options. Best regards, Tjeerd From: Eric Vyncke (evyncke) <[email protected]> Sent: Dienstag, 16. Juni 2026 14:09 To: [email protected] Subject: [Int-area] Closing/updating IPv4-only registries (FW: New Version Notification for draft-vyncke-intarea-legacy-registries-00.txt) You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Dear intarea, At the request of the IESG and in order to clean-up legacy IPv4-only IANA registries, please have a look at this IETF draft (it is a glimpse from the past with Netware!). It is short and hopefully clear. As usual comments are welcome and I will be happy to present it at IETF-126 (time allowing as it is not an adopted draft); alternatively as the draft is rather trivial and non-controversial [1] the call for adoption can be done without IETF-126 presentations. Note: obviously, this is posted as individual contributor and I won't be the responsible AD (another AD will process its publication if the WG agrees with the publication). Regards, -éric [1] happy to be proven wrong of course 😉 From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Tuesday, 16 June 2026 at 13:54 To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>; Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> Subject: New Version Notification for draft-vyncke-intarea-legacy-registries-00.txt A new version of Internet-Draft draft-vyncke-intarea-legacy-registries-00.txt has been successfully submitted by Éric Vyncke and posted to the IETF repository. Name: draft-vyncke-intarea-legacy-registries Revision: 00 Title: Updates to Legacy IPv4-related IANA Registries Date: 2026-06-16 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/archive/id/draft-vyncke-intarea-legacy-registries-00.txt Status: https://datatracker.ietf.org/doc/draft-vyncke-intarea-legacy-registries/ HTML: https://www.ietf.org/archive/id/draft-vyncke-intarea-legacy-registries-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-vyncke-intarea-legacy-registries Abstract: IANA maintains several registries that were created for IPv4 extensions. As the IPv4 core specification is no longer being extended and as some registries do not have a defined IANA registration procedure, these registries need to be updated to indicate a registration procedure or to reflect the current practice that defining such extensions is not recommended. The IETF Secretariat
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
