Updates to the Special-Purpose IP Address Registries
Fixes and clarifications to IP address registries for special-purpose addresses.
Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, "Updates to the Special-Purpose IP Address Registries", BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, <https://www.rfc-editor.org/info/rfc8190>.
@misc{rfc8190,
series = {Request for Comments},
number = 8190,
howpublished = {RFC 8190},
publisher = {RFC Editor},
doi = {10.17487/RFC8190},
url = {https://www.rfc-editor.org/info/rfc8190},
author = {R. Bonica and M. Cotton and B. Haberman and L. Vegoda},
title = {{Updates to the Special-Purpose IP Address Registries}},
pagetotal = 6,
year = 2017,
month = jun,
} RFC text
Contents
Internet Engineering Task Force (IETF) R. Bonica
Request for Comments: 8190 Juniper Networks
BCP: 153 M. Cotton
Updates: 6890 PTI
Category: Best Current Practice B. Haberman
ISSN: 2070-1721 Johns Hopkins University
L. Vegoda
ICANN
June 2017
Updates to the Special-Purpose IP Address Registries
Abstract
This memo updates the IANA IPv4 and IPv6 Special-Purpose Address
Registries to address issues raised by the definition of a "global"
prefix. It also corrects several errors in registry entries to
ensure the integrity of the IANA Special-Purpose Address Registries.
This memo updates RFC 6890.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8190.
Copyright Notice
Copyright (c) 2017 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
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definition of Globally Reachable . . . . . . . . . . . . 3
2.2. Updates to the IPv4 Special-Purpose Address Registry . . 4
2.3. Updates to the IPv6 Special-Purpose Address Registry . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Normative References . . . . . . . . . . . . . . . . . . 5
4.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
In order to support new protocols and practices, the IETF
occasionally reserves an address block for a special purpose. For
example, [RFC1122] reserves an IPv4 address block (0.0.0.0/8) to
represent the local (i.e., "this") network. Likewise, [RFC4291]
reserves an IPv6 address block (fe80::/10) for link-local unicast
addresses.
Several issues have been raised with the documentation of some of the
special-purpose address blocks in [RFC6890]. Specifically, the
definition of "global" provided in [RFC6890] was misleading as it
slightly differed from the generally accepted definition of "global
scope" (i.e., the ability to forward beyond the boundaries of an
administrative domain, described as "global unicast" in the IPv6
addressing architecture [RFC4291]).
This memo updates the definition of "global" from [RFC6890] for the
IPv4 and IPv6 Special-Purpose Address Registries, augments the fields
contained within the registries in order to address the confusion
raised by the definition of "global", and corrects some errors in
some of the entries in the Special-Purpose Address Registries.
This memo updates [RFC6890].
2. IANA Considerations
2.1. Definition of Globally Reachable
[RFC6890] defined the term "global" without taking into consideration
the multiple uses of the term. Specifically, IP addresses can be
global in terms of allocation scope as well as global in terms of
routing/reachability. To address this ambiguity, the use of the term
"global" defined in [RFC6890] is replaced with "globally reachable".
The following definition replaces the definition of "global" in the
IANA Special-Purpose Address Registries:
o Globally Reachable - A boolean value indicating whether an IP
datagram whose destination address is drawn from the allocated
special-purpose address block is forwardable beyond a specified
administrative domain.
The same relationship between the value of "Destination" and the
values of "Forwardable" and "Global" described in [RFC6890] holds for
"Globally Reachable". If the value of "Destination" is FALSE, the
values of "Forwardable" and "Globally Reachable" must also be FALSE.
The "Global" columns in the IPv4 Special-Purpose Address Registry
(https://www.iana.org/assignments/iana-ipv4-special-registry) and the
IPv6 Special-Purpose Address Registry
(https://www.iana.org/assignments/iana-ipv6-special-registry) have
been renamed to "Globally Reachable".
2.2. Updates to the IPv4 Special-Purpose Address Registry
o Limited Broadcast prefix (255.255.255.255/32) - The Reserved-by-
Protocol value has changed from False to True. This change was
made to align the registry with reservation of the limited
broadcast address with Section 7 of [RFC919].
2.3. Updates to the IPv6 Special-Purpose Address Registry
The following changes to the "IPv6 Special-Purpose Address Registry"
involved the insertion of two new footnotes. These additions
required that the footnotes be renumbered.
o TEREDO prefix (2001::/32) - The Globally Reachable value has
changed from False to "N/A [2]". The [2] footnote now states:
* See Section 5 of [RFC4380] for details.
o EID Space for LISP (2001:5::/32) - All footnotes have been
incremented by 1.
o 6to4 (2002::/16) - All footnotes have been incremented by 1.
o Unique-Local (fc00::/7) - The Globally Reachable value has changed
from False to "False [7]". The [7] footnote now states:
* See [RFC4193] for more details on the routability of Unique-
Local addresses. The Unique-Local prefix is drawn from the
IPv6 Global Unicast Address range but is specified as not
globally routed.
3. Security Considerations
This document does not raise any security issues beyond those
discussed in [RFC6890].
4. References
4.1. Normative References
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<http://www.rfc-editor.org/info/rfc6890>.
4.2. Informative References
[RFC919] Mogul, J., "Broadcasting Internet Datagrams", STD 5,
RFC 919, DOI 10.17487/RFC0919, October 1984,
<http://www.rfc-editor.org/info/rfc919>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>.
Acknowledgements
Brian Carpenter and C.M. Heard provided useful comments on initial
draft versions of this document. Daniel Migault provided an in-depth
review that helped strengthen the text within the document. Amanda
Baber and Sabrina Tanamal asked questions which resulted in the
authors simplifying the document.
Authors' Addresses
Ronald Bonica
Juniper Networks
Email: rbonica@juniper.net
Michelle Cotton
PTI, an affiliate of ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America
Phone: +1-424-254-5300
Email: michelle.cotton@iana.org
Brian Haberman
Johns Hopkins University
Email: brian@innovationslab.net
Leo Vegoda
ICANN
Email: leo.vegoda@icann.org
AI ELI5
On this page
§1What Are Special-Purpose Addresses
The IETF occasionally reserves specific IP address blocks for special purposes. For example, the IPv4 block 0.0.0.0/8 (as defined in RFC 1122) represents the local or "this" network, and the IPv6 block fe80::/10 (as defined in RFC 4291) is reserved for link-local unicast addresses.
These special-purpose addresses have unique forwarding rules and are documented in IANA registries. RFC 6890 documented the IPv4 and IPv6 Special-Purpose Address Registries and listed which addresses could be forwarded globally. However, the definition of "global" in RFC 6890 was misleading because it did not clearly distinguish between allocation scope (whether the address space is allocated globally) and routing/reachability scope (whether packets with those addresses can be forwarded beyond administrative domain boundaries).
The internet has special addresses with unusual rules, like 127.0.0.1 which means your own computer. There is a list that says which special addresses are allowed on the regular internet and which are not. But the words used were confusing.
§2The Problem with "Global"
RFC 6890 defined the term "global" without accounting for its multiple meanings in networking. Specifically, an IP address can be global in two different ways:
Global allocation scope: The address block is allocated at the global level by IANA, meaning it is recognized throughout the Internet as reserved for a specific purpose.
Global reachability: An IP datagram with a destination address from that block can be forwarded beyond the boundaries of a single administrative domain (such as a local network or organization).
RFC 6890's definition mixed these concepts, creating confusion about which special-purpose addresses could legitimately be routed across the public Internet. This RFC clarifies by replacing all instances of "global" with "globally reachable", defined as a boolean value indicating whether datagrams to that address can be forwarded beyond an administrative domain.
"Global" is a confusing word. It could mean the address was given out by the world's governing body, or it could mean the address works on the whole internet. This fixes it by using a clearer word: "globally reachable" means whether it can be sent across the internet.
§3Registry Structure and Relationships
Both the IPv4 and IPv6 Special-Purpose Address Registries include columns for "Destination" (whether the address block is suitable as a destination address), "Forwardable" (whether it may be forwarded), and the newly-clarified "Globally Reachable" (whether it can be forwarded beyond administrative boundaries).
RFC 6890 established a relationship between these fields: if "Destination" is FALSE, then both "Forwardable" and "Globally Reachable" must also be FALSE. This same relationship is preserved in RFC 8190. The change affects only the terminology and a few specific registry entries where errors existed or ambiguity needed clarification.
Each special address has three yes/no properties: can you send it as a destination, can you forward it, and can you send it far away. If one of them is no, the others must be no too. The registries now use clearer words for these.
§4IPv4 Registry Updates
The primary IPv4 registry change affects the limited broadcast prefix (255.255.255.255/32). RFC 8190 updates the "Reserved-by-Protocol" flag for this address from FALSE to TRUE, aligning the registry with the reservation of the limited broadcast address documented in Section 7 of RFC 919.
The limited broadcast address is used by hosts to send datagrams to all hosts on the local network segment without knowing the network's broadcast address. It is reserved and handled specially by all IP implementations, so marking it as "Reserved-by-Protocol" more accurately reflects its nature.
The address 255.255.255.255 is special because it sends a message to everyone on your local network. The registry now correctly marks it as reserved by the protocol.
§5IPv6 Registry Updates
Several IPv6 special-purpose address blocks required updates to the registry:
TEREDO prefix (2001::/32): The "Globally Reachable" value changed from FALSE to "N/A [2]", with a new footnote referencing RFC 4380. TEREDO is a mechanism for tunneling IPv6 over UDP through Network Address Translations (NATs), and its reachability is context-dependent.
Unique-Local addresses (fc00::/7): The "Globally Reachable" value changed from FALSE to "False [7]", with a footnote explaining that while Unique-Local addresses are drawn from the IPv6 Global Unicast Address range, they are specifically designed not to be globally routed. This clarifies that they have global allocation scope but not global reachability.
EID Space for LISP (2001:5::/32) and 6to4 (2002::/16): Both entries required footnote renumbering to accommodate the new entries but did not have substantive changes to their registry properties.
Several special IPv6 addresses needed fixes: one (TEREDO) changed because its reachability depends on context, and one (Unique-Local) changed to clarify that it is globally allocated but locally used, like a private office phone number.
§6Impact and Best Current Practice
RFC 8190 is published as a Best Current Practice (BCP), making it guidance for operators and implementers rather than a mandatory standard. The clarifications help ensure that anyone consulting the IANA Special-Purpose Address Registries understands which addresses can be routed across the public Internet and which are restricted to specific contexts.
This RFC updates RFC 6890 but does not change the fundamental properties of the special-purpose addresses themselves. Implementations that already handle these addresses correctly will continue to work. The changes primarily benefit documentation, registry maintenance, and clarity for operators maintaining routing policies and firewall rules.
This is guidance (not a requirement) for people who manage networks. It does not break anything that already works, but it makes the rules clearer and more accurate.
§7Security Implications
RFC 8190 notes that it does not raise any security issues beyond those discussed in RFC 6890. The clarifications about which addresses are "globally reachable" help with security policy: administrators who want to prevent certain traffic from leaving their networks can use the registry to identify which address ranges should be blocked at border routers.
For example, Unique-Local addresses (fc00::/7) are now explicitly noted as not globally routed, which helps security administrators understand that filtering them at a border router is appropriate. Conversely, understanding that TEREDO reachability is context-dependent helps with understanding tunnel endpoints and potential security implications.
The clearer rules help network administrators write better rules about which internet addresses to block or allow, making networks safer.