idnits 2.17.1 draft-bchv-rfc6890bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 2, 2017) is 2551 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 137 -- Looks like a reference, but probably isn't: '7' on line 147 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bonica 3 Internet-Draft Juniper Networks 4 Updates: 6890 (if approved) M. Cotton 5 Intended status: Best Current Practice ICANN 6 Expires: November 3, 2017 B. Haberman 7 Johns Hopkins University 8 L. Vegoda 9 ICANN 10 May 2, 2017 12 Updates to Special-Purpose IP Address Registries 13 draft-bchv-rfc6890bis-07 15 Abstract 17 This memo updates the IANA IPv4 and IPv6 Special-Purpose Address 18 Registries to address issues raised by the definition of a "global" 19 prefix. It also corrects several errors in registry entries to 20 ensure the integrity of the IANA Special-Purpose Address Registries. 22 This memo updates RFC 6890. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 3, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Definition of Global . . . . . . . . . . . . . . . . . . 3 61 2.2. Updates to the IPv4 Special-Purpose Address Registry . . 3 62 2.3. Updates to the IPv6 Special-Purpose Address Registry . . 3 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 65 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 67 5.2. Informative References . . . . . . . . . . . . . . . . . 4 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 In order to support new protocols and practices, the IETF 73 occasionally reserves an address block for a special purpose. For 74 example, [RFC1122] reserves an IPv4 address block (0.0.0.0/8) to 75 represent the local (i.e., "this") network. Likewise, [RFC4291] 76 reserves an IPv6 address block (fe80::/10) to represent link-scoped 77 unicast addresses. 79 Several issues have been raised with the documentation of some of the 80 special-purpose address blocks in [RFC6890]. Specifically, the 81 definition of "global" provided in [RFC6890] was misleading as it 82 slightly differed from the generally accepted definition of "global 83 scope" (i.e., the ability to forward beyond the boundaries of an 84 administrative domain, described as "global unicast" in the IPv6 85 addressing architecture [RFC4291]). 87 This memo updates the definition of "global" from [RFC6890] for the 88 IPv4 and IPv6 Special-Purpose Address Registries, augments the fields 89 contained within the registries in order to address the confusion 90 raised by the definition of "global", and corrects some errors in 91 some of the entries in the Special-Purpose Address Registries. 93 This memo updates [RFC6890]. 95 2. IANA Considerations 97 2.1. Definition of Global 99 [RFC6890] defined the term "global" without taking into consideration 100 the multiple uses of the term. Specifically, IP addresses can be 101 global in terms of allocation scope as well as global in terms of 102 routing/reachability. To address this ambiguity, the use of the term 103 "global" defined in [RFC6890] is replaced with "globally reachable". 104 The following definition replaces the definiton of "global" in the 105 IANA Special-Purpose Address Registries: 107 o Globally Reachable - A boolean value indicating whether an IP 108 datagram whose destination address is drawn from the allocated 109 special-purpose address block is forwardable beyond a specified 110 administrative domain. 112 The same relationship between the value of "Destination" and the 113 values of "Forwardable" and "Global" described in [RFC6890] holds for 114 "Globally Reachable". If the value of "Destination" is FALSE, the 115 values of "Forwardable" and "Globally Reachable" must also be FALSE. 117 The "Global" column in the IPv4 Special-Purpose Address Registry 118 (https://www.iana.org/assignments/iana-ipv4-special-registry) and the 119 IPv6 Special-Purpose Address Registry 120 (https://www.iana.org/assignments/iana-ipv6-special-registry) is 121 renamed to "Globally Reachable". 123 2.2. Updates to the IPv4 Special-Purpose Address Registry 125 o Limited Broadcast prefix (255.255.255.255/32) - The Reserved-by- 126 Protocol value is changed from False to True. This change is made 127 to align the registry with reservation of the limited broadcast 128 address with Section 7 of [RFC0919]. 130 2.3. Updates to the IPv6 Special-Purpose Address Registry 132 The following changes to the IPv6 Special-Purpose Address Registry 133 involves the insertion of two new footnotes. These changes require 134 the footnotes to be re-numbered. 136 o TEREDO prefix (2001::/32) - The Globally Reachable value is 137 changed from False to "N/A [2]". The [2] footnote states: 139 * See Section 5 of [RFC4380] for details. 141 o EID Space for LISP (2001:5::/32) - All footnotes are incremented 142 by 1. 144 o 6to4 (2002::/16) - All footnotes are incremented by 1. 146 o Unique-Local (fc00::/7) - The Globally Reachable value is changed 147 from False to "False [7]". The [7] footnote states: 149 * See [RFC4193] for more details on the routability of Unique- 150 Local addresses. The Unique-Local prefix is drawn from the 151 IPv6 Global Unicast Address range, but is specified as not 152 globally routed. 154 3. Security Considerations 156 This document does not raise any security issues beyond those 157 discussed in [RFC6890]. 159 4. Acknowledgements 161 Brian Carpenter and C.M. Heard provided useful comments on initial 162 versions of this document. Daniel Migault provided an in-depth 163 review that helped strengthen the text within the document. 165 5. References 167 5.1. Normative References 169 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 170 "Special-Purpose IP Address Registries", BCP 153, 171 RFC 6890, DOI 10.17487/RFC6890, April 2013, 172 . 174 5.2. Informative References 176 [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, 177 RFC 919, DOI 10.17487/RFC0919, October 1984, 178 . 180 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 181 Communication Layers", STD 3, RFC 1122, 182 DOI 10.17487/RFC1122, October 1989, 183 . 185 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 186 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 187 . 189 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 190 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 191 2006, . 193 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 194 Network Address Translations (NATs)", RFC 4380, 195 DOI 10.17487/RFC4380, February 2006, 196 . 198 Authors' Addresses 200 Ronald Bonica 201 Juniper Networks 203 Email: rbonica@juniper.net 205 Michelle Cotton 206 ICANN 208 Email: michelle.cotton@icann.org 210 Brian Haberman 211 Johns Hopkins University 213 Email: brian@innovationslab.net 215 Leo Vegoda 216 ICANN 218 Email: leo.vegoda@icann.org