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.¶

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

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).)¶

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.¶

 +--------+-----------+
 | Option | Option    |
 | number | type name |
 +--------+-----------+
 |     96 |         A |
 |    100 |         D |
 |    101 |         E |
 |    228 |         B |
 |    239 |         C |
 +--------+-----------+

 Figure 1: Option assignment table

+-------------+--------------------+-------------------------------+
| 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

Acknowledgments

The Author wants to thank Siemens Mobility GmbH for enabling this work.¶

Author's Address