Network Working Group T. J. Pinkert Internet-Draft Siemens Mobility GmbH Intended status: Standards Track 3 July 2026 Expires: 4 January 2027 User assignable IPv4 option numbers draft-pinkert-intarea-user-assign-ipv4-opt-nrs-00 Abstract The use of IPv4 options on the public internet is limited due to the fact that many currently defined IPv4 options have issues, as indicated in [BCP186]. This serves as an argument to refuse new option definitions for IPv4, even if the proposed IP options have no such issues, and have valid use cases on limited domains, or for limited end-host domains communicating over private networks or the public internet. This I-D defines a limited range of N IPv4 option numbers for variable assignment, by the user, to types of IP options to be used on limited domains and for limited end-host domains on the public internet. This will enable the use of IP options in two major use cases, without the need to fully standardize IP options, or register numbers for them in the IANA IP option numbers table. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://DutchyatWork.github.io/rfc-draft-user-assignable-ipv4-option- numbers/draft-pinkert-intarea-user-assign-ipv4-opt-nrs.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-pinkert-intarea-user-assign- ipv4-opt-nrs/. Source for this draft and an issue tracker can be found at https://github.com/DutchyatWork/rfc-draft-user-assignable-ipv4- option-numbers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Pinkert Expires 4 January 2027 [Page 1] Internet-Draft UAIPV4ON July 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Variably assignable IP option numbers . . . . . . . . . . . . 3 3.1. Treatment of malformed variably assigned IP options on the public internet . . . . . . . . . . . . . . . . . . . . . 4 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Pinkert Expires 4 January 2027 [Page 2] Internet-Draft UAIPV4ON July 2026 1. Introduction This I-D defines a limited range of N IP option numbers for variable assignment by the user, to zero or more types of IP options. Such variable assignment of IP options limits the number of world wide unique IP option numbers in the IANA tables that would otherwise have to be handed out for IP options used on limited domains, or by limited end-host domains, and opens up the room for easier experimenting with and use of new IP options without the need of full standardization of these at IETF. The definition is compliant with [BCP186], [STD5], and [STD3], and could also be applied for IPv6 [STD86]. A limited number of requirements is defined for proper interoperability of end-hosts and routers. Guidelines for the handling of non-compliant IP options by end-hosts are provided. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. A *limited end-host domain*, is a domain of 2 or more end-hosts connected through private or public networks, that have a common understanding of certain network properties, by assignment, agreement, or convention. E.g., which IP option type is coupled to which IP option number. In case of a single owner of the end-hosts, properties can be assigned; in case of multiple owners of end-hosts, properties can be agreed upon; in case of general acceptance, properties can be by convention. The latter is not encouraged. 3. Variably assignable IP option numbers There are N IP option numbers of Class C reserved in [IANA-IP-Option-Numbers] for variable IP option type assignment. These are IP option numbers X to Y of Class C, corresponding to value range K to L with an unser copy bit (0) and O to P with a set copy bit (1).. The user can freely choose the value of the copy bit as needed according to the IP option type definition. (As an example, number 0 to 16 of Class 3 would correspond to value range 96 to 111 with an unset copy bit (0), and 224 to 239 with a set copy bit (1).) Pinkert Expires 4 January 2027 [Page 3] Internet-Draft UAIPV4ON July 2026 When used in a limited domain as defined in [RFC8799], the IP option types may define editable contents, since both routers and hosts in the domain share knowledge about how to change particular values of an IP option type. When used in a limited end-hosts domain, IP option types can not define editable contents, since such options are to be left alone, or are to be encapsulated when entering limited domains using IP options. 1. Any option type to be assigned one of the variably assignable IP option numbers SHALL be of the the Case 2 type defined in [RFC791], and have an option-type, an option-length, and (optionally) option data defined. This serves the purpose of interoperability with internet routers which may treat the options as unknown, but may want to read further IP options in the IP header. 2. IP packets with variably assignable IP options SHALL be routed over the pubic internet without modification as specified in [BCP186]. 3. Users of variably assignable IP options in a limited domain SHALL encapsulate IP packets with variably assignable IP options from foreign domains upon reception at the entry node. 4. Users of variably assignable IP options in a limited domain SHALL decapsulate previously encapsulated IP packets with variably assignable IP options upon transmisison at the exit node. 5. IP option types COULD be registered with a unique name in the IANA IP option type table (TO BE DEFINED BY IANA), whith a publicly available specification. 6. A security analysis SHALL be made available for IP option types to be registered by IANA. Note that also existing IP options, e.g. those defined in [RFC791], could be assigned to a variable IP option number, and may be listed in the table with a unique name. 3.1. Treatment of malformed variably assigned IP options on the public internet IP packets with malformed variably assigned IP options shall be handled as specified in this section. The definition of malformed IP options includes valid but unknown Case 1 type options. Systems cannot distinguish if such options are present. The following issues may arise for unknown variable IP options: Pinkert Expires 4 January 2027 [Page 4] Internet-Draft UAIPV4ON July 2026 1. The IP option length (with a Case 1 option this is the wrongly interpreted next option's number) exceeds the IHL. The IP packet SHALL be dropped. 2. The length is in range of the IHL as stored in the IP header, but the next read IP option type (this may be data of another option) is unknown. Interpretation of the IP options SHALL be stopped. The IP packet SHALL NOT be dropped, but SHALL be further relayed according to [BCP186] or SHALL be handled as specified in [STD3] by the end-host. 3. Users of variably assignable IP options in a limited domain encounter unknown IP options on incomming packets. Incoming IP packets with unknown IP options, and no variably assignable IP options, SHALL be transported according to [BCP186]. In case of properly formed variably assigned IP options, the normal rules for IP option interpretation shall be followed as indicated in [BCP186]. 3.2. Examples The variable assignment of IP option numbers can now be performed within limited (end-host) domains as follows. Under the assumption that some option types A to E are to be used, each machine / router in the limited (end-host) domain can be configured with the same option table. An example is given in Figure 1 below. +--------+-----------+ | Option | Option | | number | type name | +--------+-----------+ | 96 | A | | 100 | D | | 101 | E | | 228 | B | | 239 | C | +--------+-----------+ Figure 1: Option assignment table An example for the IANA table requested is given here: Pinkert Expires 4 January 2027 [Page 5] Internet-Draft UAIPV4ON July 2026 +-------------+--------------------+-------------------------------+ | Option type | Option type | Internet reference | | name | specification | | +-------------+--------------------+-------------------------------+ | IOAM-IPv4 | draft-gafni-ippm- | https://datatracker.ietf.org/ | | | ioam-ipv4-options- | doc/draft-gafni-ippm-ioam- | | | 00 | ipv4-options/00/ | +-------------+--------------------+-------------------------------+ Figure 2: Example how the IP option type registry could look. 4. Security Considerations Security assessment for IP option types to be defined, may be followed after [BCP186]. 5. IANA Considerations This document requests IANA to assign a range of IP option numbers X to Y of class C for variable assignment. This document requests IANA to initiate a table for the registration of unique IP option names to enable assignment by agreement or convention. The table should at least have columns for: 1. Unique IP option names, 2. Publication name(s), and 3. (when availble) permanent links to the publication. The requirements for addition to this table SHALL be: 1. A unique, non-discriminating, IP option name, changable upon descretion by IANA upon entry, 2. A valid IP option definition for the foreseen IP protocol, and 3. A reference to the IP option definition that can be assumed to be long-lived, e.g., a scientific publication, or an internet publication on an archive. 4. The referenced publication is stored for long term archiving, is publicly available and is available free of charge. 6. References 6.1. Normative References Pinkert Expires 4 January 2027 [Page 6] Internet-Draft UAIPV4ON July 2026 [IANA-IP-Option-Numbers] IANA, "IP Option Numbers", n.d., . [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [STD3] Internet Standard 3, . At the time of writing, this STD comprises the following: Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [STD5] Internet Standard 5, . At the time of writing, this STD comprises the following: Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919, DOI 10.17487/RFC0919, October 1984, . Pinkert Expires 4 January 2027 [Page 7] Internet-Draft UAIPV4ON July 2026 Mogul, J., "Broadcasting Internet datagrams in the presence of subnets", STD 5, RFC 922, DOI 10.17487/RFC0922, October 1984, . Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, DOI 10.17487/RFC0950, August 1985, . Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, . [STD86] Internet Standard 86, . At the time of writing, this STD comprises the following: Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 6.2. Informative References [BCP186] Best Current Practice 186, . At the time of writing, this BCP comprises the following: Gont, F., Atkinson, R., and C. Pignataro, "Recommendations on Filtering of IPv4 Packets Containing IPv4 Options", BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . Acknowledgments The Author wants to thank Siemens Mobility GmbH for enabling this work. Author's Address Tjeerd J. Pinkert Siemens Mobility GmbH Ackerstrasse 22 Braunschweig Pinkert Expires 4 January 2027 [Page 8] Internet-Draft UAIPV4ON July 2026 Email: tjeerd.pinkert@siemens.com URI: https://www.mobility.siemens.com Pinkert Expires 4 January 2027 [Page 9]