Dear Tal, I am fully with you that IOAM would also make sense for IPv4, basically my proposed IP measurement option does something similar.
“IP options are no option”, and “the use of IPv4 options on the public Internet is broken” were the general remarks I got in. In my opinion, these are remarks that can carry no great weight, one being a loose remark (the why is missing), and the other to be countered with: what is broken can be fixed. Also, this can only mean that there are (still?) (many?) non-conformant implementations of IPv4 around in routers, which is astonishing 45 years after [RFC791]. Notoriously, the Linux kernel drops packets with unknown IPv4 options (this can be fixed in a single line of code though). Such behaviour should have been adjusted at the latest after [RFC1122] was accepted. From a protocol design point of view, IPv4 options are, in my opinion, a good thing! We have many protocols which allow header extensions, notoriously IPv6, and TCP (use is a requirement for high-speed connections). However, there are some quirks in the specification [RFC791], that are addressed also in [RFC1122], that make it impossible to parse unknown IPv4 options. Notoriously, that IPv4 options are not required to have a length, breaking the possibility to skip over unknown options. This was apparently acknowledged during the writing of [RFC1122], which allows not parsing unknown IPv4 options, potentially handing these over to the higher-level protocol driver. It is my opinion that the latter should not be done, and unknown options should be left unparsed. In conclusion this would mean, that one cannot trust that, e.g. the record route options, are filled by all routers en-route. I would propose to address these topics (again) in an RFC and come to a better common understanding of how to handle IPv4 options. [RFC1122] still leaves place for (mis)interpretation. From a router manufacturer point of view, any protocol with variable header lengths and extensible headers forms a performance problem. Implementing variable parts of the protocols in silicon costs and is then fixed for the lifetime of the boxes. Therefore, the variable part of the protocol must have a fixed maximum length, so that silicon implementations can handle at least that. These backgrounds may be a reason why IPv4 options are deemed to be broken, and the IPv4 implementation certainly is broken on boxes which do not honour the IHL. Many of the options defined in [RFC791] require routers to be active and do something, this is undesirable from a high-performance point of view. Skipping this variable part of the protocol should, in that sense, always be possible, to maintain high performance, especially on internet backbones. This would however require that IPv4 options, when they are defined, can handle non-handling by routers. In addition, a fix should be made to the [RFC791] definitions, such that routers, which wish to implement an amount of options, including such that require router interference, can skip unknown options. Since I think that the IPv4 protocol is there to stay for a few decades at least, I would say that it is late, but not to late, to redefine some of the IP options properties. And I see ways of doing that in a backward compatible way. This would require, that new IPv4 options are to be defined with type+length always. Also, the limited IP option space could be redefined to a 7-bit IP-option number + copy bit. The categories, being optional information also maintainable in an IANA table. Such change of definition could be signalled with an (old style) IPv4 option. Best regards, Tjeerd From: Tal Mizrahi <[email protected]> Sent: Montag, 11. Mai 2026 18:15 To: Pinkert, Tjeerd (SMO RI ML COC SM 2) <[email protected]> Cc: [email protected] Subject: Re: [ippm] Update of I-D IP measurement option Hi Tjeerd, Thanks for the detailed response, At the time, we tried to propose IOAM as an IPv4 option as well: https://datatracker.ietf.org/doc/draft-gafni-ippm-ioam-ipv4-options/ I seem to recall that the only feedback we received was that a new IPv4 option would never be approved. If presently there is enough support to discuss a new IPv4 option, that would be interesting indeed. > one issue from my side would be that the railway industry is also still > strongly under way in the IPv4 world, and IPv4 is not covered, so an IPv4 > option is, imho, still needed. The main challenge is that many existing routers and middleboxes discard packets with unknown options. I assume that this would make it very difficult to deploy a new IPv4 option in such networks that already deploy IPv4 (e.g. in the railway industry as you mentioned). Cheers, Tal. On Mon, May 11, 2026 at 2:38 PM Pinkert, Tjeerd <[email protected]<mailto:[email protected]>> wrote: Dear Tal, one issue from my side would be that the railway industry is also still strongly under way in the IPv4 world, and IPv4 is not covered, so an IPv4 option is, imho, still needed. I think we skipped over the entire IOAM thing, because it is called “Operations, Administration and Maintenance”, which end-hosts typically do not participate in. So, at first sight it was not considered… but it seems it may be interesting after all. If I understand it correctly, IOAM needs support in a so called IOAM-Domain (C1). I have some questions: * As far as I read up now, IOAM can be supported on end-hosts only without a full IOAM domain in-between by use of E2E options? * Does the protocol definition foresee that end-hosts are not part of a provider defined IOAM domain? Is that possible? * There seems to be no possibility to cryptographically sign the data sent by an end-host? that would be a feature I would like to see, and would expect to be useful for our use-cases. * Could a user define a Namespace-ID with the current specification? As far as I see it, for now the definition of IOAM would cover all we would, at the moment, wish for in the IPv6 world. What seems to be lacking / would I comment on? * An indicator that indicates which timestamp type is used? * Would allow hosts not in the end-host IOAM domain, to use the timestamp data of the end-hosts for their own purposes. (You need to know, is it NTP, PTP, Unix?, Are you using TAI or UTC including leap seconds?) I think these may need consideration if you want to read user-domain data in an operator domain. Otherwise, the operator domain must add its own IPv6 header (do I understand that correctly?) or its own IOAM data, putting pressure on the amount of user-space data that can be included in the packet (MTU). * Would allow to go beyond the 32 + 32 bit definitions (This is needed for, e.g., interstellar travel and for high-precision (hardware based) time comparison below the ns, the latter is already reality e.g. in PTP HA extensions, and would need to facilitate at least better than femtoseconds (or even attoseconds) in order to allow optical clock precisions, which I would deem feasible also in the electrical domain at some point, coupling optical clocks to electrical time references, at least for longer integration periods.) * See RFC 8877 section 7. * Possibility to cryptographically sign the data, including parts of the IPv6 header, in order to detect tampering by intermediate nodes. * Would require an out of band management protocol for keys which would become an own RFC (it is also not there in my draft, and was seen as out of scope, for now…) * Possibility of encrypting (and optionally signing) the data, such that foreign entities cannot obtain information from such data. * Would require an out of band management protocol for keys which would become an own RFC (It is also not there in my draft, and was seen as out of scope, for now…) * A reserved user-assigned Namespace-ID range, there is not only an operator, but there are also users of the network (I would hope?). * This would help the network to know when end-users have inserted their own IOAM data. * A 32-bit sequence number would be totally sufficient to detect losses if used together with ns capable timestamps (see my draft for some thoughts on this) * Value 0xFFFFFFFF cannot be used for signalling purposes with NTP timestamps, since it is a valid second and fractional second value in that specification. * This is definitely a no-go in timekeeping land, and SHALL NOT be done!!! At least the reader of a timestamp SHALL NOT interpret this value as being invalid!!! (Coming from the timekeeping community I have strong feelings about this.) * Other means of signalling incapability of putting in a timestamp are needed, if at all. When timestamps are not accurate (say, a few days off), what would a receiver do? It SHOULD read and process it, removing outliers is (at least scientifically speaking) a sin in the timekeeping business. Therefore, any value set for nodes that cannot fill the TS is as good as any other, receivers need to read them anyway and (for proper timekeeping) MUST NOT refute any value. * Specification of RFC 8877 Synchronization aspects are (partially) missing? * Specification of what bit-boundary the timestamp is related to is missing (also from RFC 8877)? * I would choose the start of the first bit of the IP header for this. This allows for independence of insertion / extraction by IP options along the path. * This allows for precise definitions, e.g., the reference to ports (electropedia.org<http://electropedia.org/>) and reference planes in the physical domain. It would be great if these considerations could be taken into account in a next revision. The IOAM protocol is much more elaborate that the simple thing we need, on the other hand, it is already used, which is an advantage. In some cases, it may be prone to clash with the MTU requirements of the EULYNX specification. In particular, the RaSTA protocol on top of UDP requires RaSTA packets to be sent in their entirety, limiting the space available for PDI data. IPv6 with IOAM would put even more pressure on the already tight space for user-data left for this protocol variant (max. MTU=1300 octets, according to EULYNX). Best regards, Tjeerd From: Tal Mizrahi <[email protected]<mailto:[email protected]>> Sent: Freitag, 1. Mai 2026 06:15 To: Pinkert, Tjeerd (SMO RI ML COC SM 2) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [ippm] Update of I-D IP measurement option You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hi Tjeerd, Thanks for sharing these drafts. - Have you considered IOAM [RFC 9197]? It would be useful to explain what in your opinion is missing in IOAM, and possibly define a new IOAM option rather than define a new IP option. - Please note that introducing a new IPv4 option would be a problem, as the IETF does not define new features to IPv4 anymore. Cheers, Tal. On Thu, Apr 30, 2026 at 7:12 PM Pinkert, Tjeerd <[email protected]<mailto:[email protected]>> wrote: Dear WG, I updated the I-D on the IP measurement option as well as the related interlayer protocol. Please have a look at the latest versions: https://datatracker.ietf.org/doc/draft-pinkert-ippm-ip-measurement-option/ https://datatracker.ietf.org/doc/draft-pinkert-ippm-inter-layer-protocol/ They now have a place at Github as well: https://github.com/DutchyatWork/rfc-draft-ip-measurement-option https://github.com/DutchyatWork/rfc-draft-inter-layer-protocol Comments are welcome. With best regards, Dr. Tjeerd Pinkert Siemens Mobility GmbH Mobility Rail Infrastructure System Management 2 SMO RI ML COC SM 2 Ackerstr. 22 38126 Braunschweig, Germany Phone: +49 (1520) 2884088 Mobile: +49 (1520) 2884088 mailto:[email protected] www.siemens.com<https://www.siemens.com/> [Logo] Siemens Mobility GmbH; Chairman of the Supervisory Board: Roland Busch; Management Board: Beatrice Bock, Michael Peter; Registered office: Munich, Germany; Commercial registry Munich, HRB 237219; WEEE-Reg.-No. DE 92917817 _______________________________________________ ippm mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
