]> Siemens Mobility GmbH

Ackerstrasse 22 Braunschweig 38126 tjeerd.pinkert@siemens.com https://www.mobility.siemens.com

IPv4 options private number range 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 . 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 The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

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 , , and , and could also be applied for IPv6 . 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.

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

Variably assignable IP option numbers There are N IP option numbers of Class C reserved in 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 , 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 , 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 .
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 , could be assigned to a variable IP option number, and may be listed in the table with a unique name.

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:

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 or SHALL be handled as specified in 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 .

In case of properly formed variably assigned IP options, the normal rules for IP option interpretation shall be followed as indicated in .

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. An example for the IANA table requested is given here:

Security Considerations Security assessment for IP option types to be defined, may be followed after .

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.

References Normative References This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This memo discusses the utility of "subnets" of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940. This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed. This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK] This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. IANA n.d. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus.

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