RFC 8190

Updates to the Special-Purpose IP Address Registries 🦋

okay bestie, this is RFC 8190 💖 It's a Best Current Practice (BCP 153) and it updates RFC 6890. It came out in June 2017 (ISSN 2070-1721), and the authors are R. Bonica from Juniper Networks, M. Cotton from PTI, B. Haberman from Johns Hopkins University, and L. Vegoda from ICANN. It's giving careful housekeeping energy 🧹✨

Abstract

okay so this memo tidies up the IANA IPv4 and IPv6 Special-Purpose Address Registries 🎀 The main drama is that the word "global" in a certain prefix definition was confusing people, so it gets fixed. It also corrects a bunch of mistakes in registry entries so the registries stay accurate 💅

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 ✨

okay so the IETF sometimes sets aside an address block for a special job, so new protocols and practices have room to work 🌈 For example, [RFC1122] reserves the IPv4 block 0.0.0.0/8 to mean the local ("this") network. And [RFC4291] reserves the IPv6 block fe80::/10 for link-local unicast addresses 🫶

Some people raised issues with how a few of those special-purpose blocks were documented in [RFC6890] 🙈 The real problem was the definition of "global". The one in [RFC6890] was kinda misleading because it didn't quite match the usual meaning of "global scope". The usual meaning is being able to forward beyond the boundaries of an administrative domain, which the IPv6 addressing architecture [RFC4291] calls "global unicast".

So this memo updates the definition of "global" from [RFC6890] for the IPv4 and IPv6 Special-Purpose Address Registries 💅 It also adds fields to the registries to clear up the confusion, and fixes some errors in some of the entries.

This memo updates [RFC6890].

2. IANA Considerations 🍓

2.1. Definition of Globally Reachable 👑

[RFC6890] defined the term "global" without thinking about all the different ways people use it. IP addresses can be global in terms of allocation scope, and they can also be global in terms of routing and reachability. To fix this mix-up, the term "global" from [RFC6890] is replaced with "globally reachable". The following definition replaces the definition of "global" in the IANA Special-Purpose Address Registries:

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

• Limited Broadcast prefix (255.255.255.255/32): the Reserved-by-Protocol value has changed from False to True. This was done so the registry lines up with the reservation of the limited broadcast address in Section 7 of [RFC919] 💜

2.3. Updates to the IPv6 Special-Purpose Address Registry 🦋

okay so this part got a little busy 😭 Two new footnotes were inserted, which meant the existing footnotes had to be renumbered.

• TEREDO prefix (2001::/32): the Globally Reachable value has changed from False to "N/A [2]". The [2] footnote now says:
  • See Section 5 of [RFC4380] for details.
• EID Space for LISP (2001:5::/32): all footnotes have been incremented by 1 🔢
• 6to4 (2002::/16): all footnotes have been incremented by 1 🔢
• Unique-Local (fc00::/7): the Globally Reachable value has changed from False to "False [7]". The [7] footnote now says:
  • 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 🔐

⚠️ Serious security note, bestie: this document does not raise any security issues beyond those discussed in [RFC6890]. Read that one too before you do anything with these registries 🙏

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 gave useful comments on early drafts 💜 Daniel Migault did an in-depth review that made the text stronger ✨ Amanda Baber and Sabrina Tanamal asked questions that led the authors to simplify 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