User assignable IPv4 option numbers
draft-pinkert-intarea-user-assign-ipv4-opt-nrs-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Tjeerd J. Pinkert | ||
| Last updated | 2026-07-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-pinkert-intarea-user-assign-ipv4-opt-nrs-00
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.,
<https://www.iana.org/assignments/ip-parameters/ip-
parameters.xhtml#ip-parameters-1>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/rfc/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[STD3] Internet Standard 3,
<https://www.rfc-editor.org/info/std3>.
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,
<https://www.rfc-editor.org/info/rfc1122>.
Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/info/rfc1123>.
[STD5] Internet Standard 5,
<https://www.rfc-editor.org/info/std5>.
At the time of writing, this STD comprises the following:
Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
Mogul, J., "Broadcasting Internet Datagrams", STD 5,
RFC 919, DOI 10.17487/RFC0919, October 1984,
<https://www.rfc-editor.org/info/rfc919>.
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,
<https://www.rfc-editor.org/info/rfc922>.
Mogul, J. and J. Postel, "Internet Standard Subnetting
Procedure", STD 5, RFC 950, DOI 10.17487/RFC0950, August
1985, <https://www.rfc-editor.org/info/rfc950>.
Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[STD86] Internet Standard 86,
<https://www.rfc-editor.org/info/std86>.
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,
<https://www.rfc-editor.org/info/rfc8200>.
6.2. Informative References
[BCP186] Best Current Practice 186,
<https://www.rfc-editor.org/info/bcp186>.
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,
<https://www.rfc-editor.org/info/rfc7126>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/rfc/rfc8799>.
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]