Movatterモバイル変換

Internet Engineering Task Force (IETF)                         R. BonicaRequest for Comments: 8190                              Juniper NetworksBCP: 153                                                       M. CottonUpdates:6890                                                        PTICategory: Best Current Practice                              B. HabermanISSN: 2070-1721                                 Johns Hopkins University                                                               L. Vegoda                                                                   ICANN                                                               June 2017Updates to the Special-Purpose IP Address RegistriesAbstract   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 updatesRFC 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 inSection 2 of RFC 7841.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc8190.Bonica, et al.            Best Current Practice                 [Page 1]

RFC 8190           Special-Purpose Address Registries          June 2017Copyright Notice   Copyright (c) 2017 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .32.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .32.1.  Definition of Globally Reachable  . . . . . . . . . . . .32.2.  Updates to the IPv4 Special-Purpose Address Registry  . .42.3.  Updates to the IPv6 Special-Purpose Address Registry  . .43.  Security Considerations . . . . . . . . . . . . . . . . . . .44.  References  . . . . . . . . . . . . . . . . . . . . . . . . .54.1.  Normative References  . . . . . . . . . . . . . . . . . .54.2.  Informative References  . . . . . . . . . . . . . . . . .5   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .5   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .6Bonica, et al.            Best Current Practice                 [Page 2]

RFC 8190           Special-Purpose Address Registries          June 20171.  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 Considerations2.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.Bonica, et al.            Best Current Practice                 [Page 3]

RFC 8190           Special-Purpose Address Registries          June 2017   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 withSection 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:      *  SeeSection 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].Bonica, et al.            Best Current Practice                 [Page 4]

RFC 8190           Special-Purpose Address Registries          June 20174.  References4.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.Bonica, et al.            Best Current Practice                 [Page 5]

RFC 8190           Special-Purpose Address Registries          June 2017Authors' 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.orgBonica, et al.            Best Current Practice                 [Page 6]