| Internet-Draft | Legacy IANA IPv4 Registries | June 2026 |
| Vyncke | Expires 18 December 2026 | [Page] |
IANA maintains several registries that were created for IPv4 extensions. As the IPv4 core specification is no longer being extended and as some 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.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Internet Area Working Group Working Group mailing list (int-area@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/int-area/.¶
Source for this draft and an issue tracker can be found at https://github.com/evyncke/draft-vyncke-intarea-legacy-registries.¶
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 18 December 2026.¶
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.¶
Several registries were created for IPv4-related protocol elements [RFC791]. These registries were created by [RFC1700], which in turn was obsoleted by [RFC3232] which handed these registries to IANA.¶
The IPv4 core specification [RFC791] is no longer being extended (see also [IAB_IPV4]) and more modern mechanisms are defined to manage names. Also, some IANA registries do not have a defined registration policy (Section 4 of [RFC8126]). Therefore, this document closes some relevant IANA registries and changes the registration procedure for others. See more in Section 1.1.¶
The information in the closed registries is still valid and registrations already in these registries can still be updated per the guidance in Section 9.6 of [RFC8126].¶
The justifications for the changes to IANA registries listed in Section 4 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 [NOT_AN_OPTION]. The registration procedure is set to "IESG approval" ([RFC8126], Section 4.10); 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) (Section 3.1 of [RFC791]) header field can be freely selected by source nodes.¶
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" ([RFC8126], Section 4.4).¶
As some registries are closed, they 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 are not reliable. More robust alternative means should be explored.¶
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.¶
This document requests IANA to close the following registry per Section 9.6 of [RFC8126] 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 [DHC_NETWARE].¶
This document requests IANA to set the registration procedure to "IESG approval" ([RFC8126], Section 4.10) 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 [IP_OPTIONS].¶
This document requests IANA to set the registration procedure to "First Come First Served" ([RFC8126], Section 4.4) with a reference to this document for the following registries:¶
The "Machine Names" registry group [MACHINE_NAMES].¶
The "Terminal Type Names" registry group [TERMINAL_TYPES].¶
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 [IP_TTL]. If not possible, then IANA is requested to replace the existing note with the following note:¶
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: Tommy Jensen.¶