Good morning One of the significant push backs i got about ipv8 is that changing the header field length would dramatically break all the silicon forwarding in the world.
https://www.ietf.org/archive/id/draft-thain-ipv8-02.html I also included in BGP8 and all the other routing protocols a variable called cost factor, the incrementally calculates the cost along the path of BGP peering and shares to cost in a protocol called Tsun Tsu I think you'll find options so blocked in the world it's practically unusable. We're on path to demonstrate ipv8 working on user space. We did this with out of band at TCP level with BGP and called the cost factor. Of course of this ever gets implemented it would certainly help us improve the quality of cost factor. We also crypto the NTP path because we use OAuth to configure things and allow basic network separation by user or mab And therefore NDB is reliable but only accurate to about a millisecond. Good luck Jamie openipv8.org On Tue., May 19, 2026, 6:52 a.m. Pinkert, Tjeerd, <tjeerd.pinkert= [email protected]> wrote: > 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]> 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) 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]> > *Sent:* Freitag, 1. Mai 2026 06: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 > > > > You don't often get email from [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 <tjeerd.pinkert= > [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] <[email protected]> > www.siemens.com > [image: 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] > To unsubscribe send an email to [email protected] > > _______________________________________________ > Int-area mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
