Dear Eric, Thank you for the explanation, also of the procedures (I’m new to this community) that are followed. This sounds reasonable, and I hope the consensus will fall out positively for IP options. By the way, I would prefer the more neutral formulation, as you would have guessed.
Can it be requested that the IESG makes the decision to free up part of the option numbers for arbitrary private assignment in limited networks? How could that be done? An entirely different architectural direction would be to replace classical IPv4 options with the IPv6 extension header framework, which would also suit. That would even make the re-use of IPv6 code / silicon possible for IPv4. I must honestly say, that I am not in the position to say how easy/hard that would be, or how well the IPv6 extension headers function compared to IPv4 options. From the active developments in that area, I would think they function sufficiently well in limited domains. Yes, we have considered IPv6, which is not entirely in the hands of the network user, and may not be possible for older installations. The use of additional probing packets with e.g. OWAMP, is typically seen very critical, due to the high availability requirements for railway signalling systems. (One element not reachable / disturbed, causes emergency breaks of trains, so that is not favourable -> very high availability required + limitation of all possible disturbers.) For us best way of measuring the actual network performance is thus using the available data connections and their packets (they are required anyway). Due to high costs of safe software development, we prefer to do this kind of auxiliary things in the non-safe part of the systems, where development is easier and cheaper. In practice that means one of the Ethernet, IP, UDP, TCP, TLS protocols should offer possibilities for adding measurement data. The IP protocol is the one unified protocol in the EULYNX stack with end-to-end properties, where we can use one method for all data connections, both for IPv4 and IPv6. Since we noted that measuring networks is a general thing, and well standardized protocols with a broader user base, are favoured over own limited developments, we ended up at IETF as most reasonable standardization organization, also because the IP protocol is standardized at IETF. In that sense, since I learned a bit too, I have looked at the IOAM protocol, and it seems suitable too, when it would be available on IPv4 (still have to check the digital signature parts, and if they would fit the 10 words limit together with the rest of the information we would need). For now, we could use the “experimental” numbers (or any unused number), but this is not a future proof thing once standardization in the railway community comes in view. Then either a privately managed part of the number space, or a globally assigned number would then be required. It may also be a difficult thing when publishing source code for inclusion in the Linux kernel (we aim for that at some point), since, well, the experimental numbers are experimental… Best regards, Tjeerd From: Eric Vyncke (evyncke) <[email protected]> Sent: Donnerstag, 18. Juni 2026 12:04 To: Pinkert, Tjeerd (SMO RI ML COC SM 2) <[email protected]>; [email protected] Subject: Re: Closing/updating IPv4-only registries (FW: New Version Notification for draft-vyncke-intarea-legacy-registries-00.txt) 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]<mailto:[email protected]>> Date: Tuesday, 16 June 2026 at 17:25 To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[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]<mailto:[email protected]>> Sent: Dienstag, 16. Juni 2026 14:09 To: [email protected]<mailto:[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]
