]> Cisco

De Kleetlaan, 6A Diegem Belgium evyncke@cisco.com

Internet int-area Internet-Draft IANA maintains several registries that were created for IPv4. As the IPv4 core specification is no longer being extended and as some other registries do not have a defined IANA registration procedure, these registries need to be updated to indicate a registration procedure or to reflect the current practice that defining such extensions is not recommended. Discussion Venues Discussion of this document takes place on the Internet Area Working Group Working Group mailing list (int-area@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Several registries were created for IPv4-related protocol elements . These registries were created by , which in turn was obsoleted by which handed these registries to IANA. The IPv4 core specification is no longer being extended (see also ) and more modern mechanisms are defined to manage names. Also, some IANA registries do not have a defined registration policy (). Therefore, this document closes some relevant IANA registries and changes the registration procedure for others. See more in . The information in the closed registries is still valid and registrations already in these registries can still be updated per the guidance in .

Justification The justifications for the changes to IANA registries listed in are as follows:

:

Registrations are to be closed as Netware is not extended anymore.

:

It is commonly understood that the use of IPv4 options is broken . The registration procedure is set to "IESG approval" (); it is expected that the IESG won't approve any new IPv4 option.

:

This registry should not have been created as the IPv4 Time to Live (TTL) () header field can be freely selected by source nodes.

and :

There are no defined registration procedures for these two registries. Moreover, there were no registrations made to these registries in the last two decades. This document specifies the registration procedure as "First Come First Served" ().

Operational Considerations As one registry is closed, it cannot be extended but the existing values are still valid (i.e., unless they are deprecated by a future document, they can still be used). These changes do not impact existing operations that use already registered values. The use of IPv4 options on the public Internet is broken. Solutions that rely on defining such options will probably not be reliable. More robust alternative means should be explored.

Security Considerations There is no new security considerations introduced by this document except for the registries whose registration policy is changed to "First Come First Served". Concretely, registrations are still possible to such registries with the risk of having unusable non-sensible data added to it, but the IANA policy is to apply common sense filtering on the content and amount of registrations.

IANA Considerations This document requests IANA to close the following registry per and add a reference to this document:

• The "NetWare/IP Option Type 63 Sub-Option Codes" registry under the "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters" registry group .

This document requests IANA to set the registration procedure to "IESG approval" () with a reference to this document for the following registry:

• The "IP Option Numbers" registry under the "Internet Protocol Version 4 (IPv4) Parameters" registry group .

This document requests IANA to set the registration procedure to "First Come First Served" () with a reference to this document for the following registries:

• The "Machine Names" registry group .
• The "Terminal Type Names" registry group .

This document also requests IANA to completely remove the "IP Time to Live Parameter" registry under the "Internet Protocol Version 4 (IPv4) Parameters" registry group . If not possible, then IANA is requested to replace the existing note with the following note:

• There is no registry for the IPv4 Time To Live (TTL) as it is set by the node operating system or the node application. Recommended default TTL value for IPv4 is 64 .

References Normative References Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. 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] Informative References IANA IANA IANA IANA IANA This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community.

Acknowledgments Thanks to Mohamed Boucadair for the initial idea and deep review. Thanks also to Amanda Baber for the initial list of legacy registries or registries without any specified registration procedures. Other thanks for reviewers: Brian Carpenter, Tommy Jensen, Dave Thaler.