Tjeerd, For such a request, indeed a draft in intarea WG is to required.
If your project insists on using IPv4 options, then feel free to use the *existing* EXP code points. Else, I can only repeat my previous suggestions of using either a new IP protocol or a specific UDP port. Regards -éric From: Pinkert, Tjeerd <[email protected]> Date: Monday, 22 June 2026 at 13:55 To: [email protected] <[email protected]>; Internet Area <[email protected]> Subject: [Int-area] INT intarea, appropriateness of I-D requesting 8 - 16 IPv4 option numbers for arbitrary private assignment. Dear Tommy, Éric, Referring to my posts at the intarea mailing list, and the concern that the use of IPv4 options, even on limited domains, will become hard after handover of the IP option number table to IESG. Would it fit the topic of the intarea working group to submit an I-D that proposes the assignment of 4 to 16 IPv4 option numbers, from one of the now reserved categories?, for free assignment on limited domain and for limited end-host domains using the public internet, or would this better fit another working group? I think such an I-D would not contradict the proposal to put the governance of the IP option number IANA table in the hands of the IESG? For the end-host to end-host over the public internet category (I would assume that) only “transparent” IP options (is that the right term for options not changed by routers) come into the question. This would not collide with BCP 186, section 4.23 on “Other IP Options” as far as I see it, while allowing the use of option numbers other than those reserved for experiments. The only requirement must be that all options in this category, even privately defined options, must be type + length, to enable routers to skip them appropriately. In this way, limited domain owners as well as limited end-host domains would gain access to the possibility of using x arbitrary options on their domain or over the public internet. In addition, this would open up the possibility for those groups of users, to define IP options more easily, and would release the pressure on the limited availability of IP option numbers as well as the pressure on IETF to cater limited domain owners. This would also allow router manufacturers, select this range of IPv4 option numbers for “free relay” (that should already be so according to BCP 186). For IPv4 I would think 16 different options should be sufficient given the limited (40 octets) space in the IPv4 header. Would you recommend that I would write such an I-D for IPv4 only, or may this also be relevant for the IPv6 protocol? (For IPv6 it would be a question what is a useful number, but any (from 4 to 32) could make sense.) 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
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
