Network Working Group R. Bonica
Internet-Draft Juniper Networks
Updates: 6890 (if approved) M. Cotton
Intended status: Best Current Practice ICANN
Expires: November 3, 2017 B. Haberman
Johns Hopkins University
L. Vegoda
May 2, 2017

Updates to Special-Purpose IP Address Registries


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

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 November 3, 2017.

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

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 ( to represent the local (i.e., "this") network. Likewise, [RFC4291] reserves an IPv6 address block (fe80::/10) to represent link-scoped 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 Global

[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 definiton of "global" in the IANA Special-Purpose Address Registries:

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" column in the IPv4 Special-Purpose Address Registry ( and the IPv6 Special-Purpose Address Registry ( is renamed to "Globally Reachable".

2.2. Updates to the IPv4 Special-Purpose Address Registry

2.3. Updates to the IPv6 Special-Purpose Address Registry

The following changes to the IPv6 Special-Purpose Address Registry involves the insertion of two new footnotes. These changes require the footnotes to be re-numbered.

3. Security Considerations

This document does not raise any security issues beyond those discussed in [RFC6890].

4. Acknowledgements

Brian Carpenter and C.M. Heard provided useful comments on initial versions of this document. Daniel Migault provided an in-depth review that helped strengthen the text within the document.

5. References

5.1. Normative References

[RFC6890] Cotton, M., Vegoda, L., Bonica, R. and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013.

5.2. Informative References

[RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919, DOI 10.17487/RFC0919, October 1984.
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006.

Authors' Addresses

Ronald Bonica Juniper Networks EMail:
Michelle Cotton ICANN EMail:
Brian Haberman Johns Hopkins University EMail:
Leo Vegoda ICANN EMail: