idnits 2.17.1 draft-gont-6man-ipv6-ula-scope-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8190, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4193, updated by this document, for RFC5378 checks: 2003-08-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 5, 2021) is 1200 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ADDARCH' is mentioned on line 245, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 284, but not defined -- Looks like a reference, but probably isn't: '4' on line 280 == Unused Reference: 'RFC8190' is defined on line 321, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-gont-v6ops-ipv6-addressing-considerations-00 -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft SI6 Networks 4 Updates: 4291, 4193, 8190 (if approved) January 5, 2021 5 Intended status: Standards Track 6 Expires: July 9, 2021 8 Scope of Unique Local IPv6 Unicast Addresses 9 draft-gont-6man-ipv6-ula-scope-00 11 Abstract 13 Unique Local IPv6 Unicast Addresses (ULAs) are formally part of the 14 IPv6 Global Unicast address space. However, the semantics of ULAs 15 clearly contradict the definition of "global scope". This document 16 discusses the why the terminology employed for the specification of 17 ULAs is problematic, along with some practical consequences of the 18 current specification of ULAs. Finally, it formally updates RFC4291 19 and RFC4193 such that the scope of ULAs is defined as "local". 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 9, 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. What Does 'Global Scope' mean? . . . . . . . . . . . . . . . 2 57 3. Scope of Unique Local IPv6 Unicast Addresses . . . . . . . . 3 58 4. Problems with the Definition of the ULA Scope . . . . . . . . 4 59 5. Practical Consequences . . . . . . . . . . . . . . . . . . . 4 60 5.1. Address Attributes in Programming Languages . . . . . . . 5 61 6. Specification Updates . . . . . . . . . . . . . . . . . . . . 5 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 10.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 Unique Local IPv6 Unicast Addresses (commonly referred to as "ULAs") 73 [RFC4193] are formally part of the IPv6 Global Unicast address space. 74 However, the semantics of ULAs clearly contradict the definition of 75 "global scope" [RFC4007]. 77 This document discussed the specification of ULAs and, in particular, 78 of their associated scope. Additionally, it discusses how the 79 semantics of ULAs contradicts their formal address scope along with 80 some and practical consequences of this problematic definition. 81 Finally, this document formally updates RFC4193 and RFC4291, such 82 that ULAs are defined to have "local scope" (larger than link-local, 83 and smaller than "global"). 85 The problematic definition of ULAs was initially encountered when 86 analyzing IPv6 address properties while working on 87 [I-D.gont-v6ops-ipv6-addressing-considerations]. The issue became 88 fully-evident from discussions with Brian Carpenter, both off-list 89 and on-list [v6ops-thread]. 91 2. What Does 'Global Scope' mean? 93 [RFC4007] defines the scope of an address as: 95 "[the] topological span within which the address may be used as a 96 unique identifier for an interface or set of interfaces" 98 And defines the "global scope" to be used for: 100 "uniquely identifying interfaces anywhere in the Internet" 102 3. Scope of Unique Local IPv6 Unicast Addresses 104 [RFC4193] formally specifies Unique Local IPv6 Unicast Addresses. 105 [RFC4193] did not formally update [RFC3513], the current IPv6 106 Addressing Architecture at the time [RFC4193] was published. 107 Therefore, ULAs were specified as a different address type, but 108 rather as part of the Global Unicast address space. 110 [RFC3513] was eventually obsoleted by [RFC4291] (current revision of 111 the IPv6 Addressing Architecture), but still did not formally 112 accommodate ULAs into the IPv6 Addressing Architecture. For 113 instance, Section 2.4 of [RFC4291] notes that the type of an IPv6 114 address is identified by the high-order bits of the address, as 115 follows: 117 Address type Binary prefix IPv6 notation Section 118 ------------ ------------- ------------- ------- 119 Unspecified 00...0 (128 bits) ::/128 2.5.2 120 Loopback 00...1 (128 bits) ::1/128 2.5.3 121 Multicast 11111111 FF00::/8 2.7 122 Link-Local unicast 1111111010 FE80::/10 2.5.6 123 Global Unicast (everything else) 125 and subsequently notes that: 127 "Future specifications may redefine one or more sub-ranges of the 128 Global Unicast space for other purposes, but unless and until that 129 happens, implementations must treat all addresses that do not 130 start with any of the above-listed prefixes as Global Unicast 131 addresses." 133 Therefore, ULAs still formally belong to the Global Unicast address 134 space. 136 Additionally, Section 3.3 of [RFC4193] (the specification of Unique 137 Local IPv6 Unicast Addresses) defines the scope of ULAs as: 139 "By default, the scope of these addresses is global. That is, 140 they are not limited by ambiguity like the site-local addresses 141 defined in [ADDARCH]. Rather, these prefixes are globally unique, 142 and as such, their applicability is greater than site-local 143 addresses." 145 4. Problems with the Definition of the ULA Scope 147 Section 3.3 of [RFC4193] (the specification of Unique Local IPv6 148 Unicast Addresses) defines the scope of ULAs as: 150 "By default, the scope of these addresses is global. That is, 151 they are not limited by ambiguity like the site-local addresses 152 defined in [ADDARCH]. Rather, these prefixes are globally unique, 153 and as such, their applicability is greater than site-local 154 addresses. Their limitation is in the routability of the 155 prefixes, which is limited to a site and any explicit routing 156 agreements with other sites to propagate them (also see 157 Section 4.1). Also, unlike site-locals, a site may have more than 158 one of these prefixes and use them at the same time." 160 However, there is a problem in this analysis: ULA prefixes have a 161 finite probability of being globally unique. For instance, 162 Section 3.2.3 of [RFC4193] computes the probability of collisions 163 *when inter-connecting a limited number of networks employing ULAs*. 164 As such, based on the definition of "scope" and "global scope" (see 165 Section 2), ULAs cannot possibly have a "global scope" -- their scope 166 is certainly smaller than "global". And this non-global scope does 167 limit the global routability of ULAs since, in principle, an address 168 cannot be routed outside of its associated zone. 170 The only ULAs that could possibly have "global scope" are the so- 171 called ULA-C [I-D.ietf-ipv6-ula-central], that have so far *not* 172 been formally specified. 174 It should be noted that the non-global scope of ULAs does not 175 preclude their usage for e.g. inter-site Virtual Private Networks 176 (VPN), as discussed in Section 4.7 of [RFC4193]. For example, the 177 private address space specified in [RFC1918] for IPv4 networks has 178 non-global scope, but still is regularly used for inter-site VPNs. 179 ULAs having a non-global scope simply means that while allocating 180 "Global IDs" from a Pseudo-Random Number Generator (PRNG) reduces the 181 probability of collisions of Global IDs *when a limited number of 182 networks employing ULAs are interconnected*, ULA prefixes cannot be 183 expected to be globally unique. 185 "Global scope" would imply that all ULA prefixes in use by any 186 networks, whether interconnected or not, are unique. 188 5. Practical Consequences 189 5.1. Address Attributes in Programming Languages 191 Python's ipaddress library [Python-ipaddr] defines 'IPv6Address' 192 objects that have a number of attributes, including: 194 o 'True' if the address is allocated for private networks. 196 o 'True' if the address is allocated for public networks. 198 For ULAs, the is_private attribute is 'True', while the is_global 199 attribute is 'False'. This contradicts the definition of ULAs as 200 having "global scope" [RFC4291] [RFC4193], but is in line with the 201 specification update performed by this document (see Section 6). 203 6. Specification Updates 205 The ultimate goal is to employ coherent terminology and definitions 206 throughout the relevant protocol specifications. Probably the only 207 option to achieve this goal is update the definition of ULAs as 208 having "local scope", with "local scope" defined as "larger than 209 link-local, and smaller than global" (based on ULAs being defined as 210 "local addresses"). 212 o [TBD: Analyze possible implications on Default Address Selection 213 for Internet Protocol Version 6 (IPv6) [RFC6724].] 215 The following table from Section 2.4 of [RFC4291]: 217 ---- cut here ---- 218 Address type Binary prefix IPv6 notation Section 219 ------------ ------------- ------------- ------- 220 Unspecified 00...0 (128 bits) ::/128 2.5.2 221 Loopback 00...1 (128 bits) ::1/128 2.5.3 222 Multicast 11111111 FF00::/8 2.7 223 Link-Local unicast 1111111010 FE80::/10 2.5.6 224 Global Unicast (everything else) 225 ---- cut here ---- 227 is replaced with: 229 ---- cut here ---- 230 Address type Binary prefix IPv6 notation Reference 231 ------------ ------------- ------------- --------- 232 Unspecified 00...0 (128 bits) ::/128 Sec. 2.5.2 233 Loopback 00...1 (128 bits) ::1/128 Sec. 2.5.3 234 Unique Local unicast 1111110 FC00::/7 [RFC4193] 235 Multicast 11111111 FF00::/8 Sec. 2.7 236 Link-Local unicast 1111111010 FE80::/10 Sec. 2.5.6 237 Global Unicast (everything else) 238 ---- cut here ---- 240 The following text from Section 3.3 of [RFC4193]: 242 ---- cut here ---- 243 By default, the scope of these addresses is global. That is, they 244 are not limited by ambiguity like the site-local addresses defined in 245 [ADDARCH]. Rather, these prefixes are globally unique, and as such, 246 their applicability is greater than site-local addresses. Their 247 limitation is in the routability of the prefixes, which is limited to 248 a site and any explicit routing agreements with other sites to 249 propagate them (also see Section 4.1). Also, unlike site-locals, a 250 site may have more than one of these prefixes and use them at the 251 same time. 252 ---- cut here ---- 254 is replaced with: 256 ---- cut here ---- 257 The scope of these addresses is 'local', defined to be 'larger than 258 link-local, but smaller than global'. Their limitation is in the 259 routability of the prefixes, generally limited by any explicit 260 routing agreements with other autonomous systems (ASes) to propagate 261 them, and normally limited by the Default-Free Zone (DFZ) (also see 262 Section 4.1). 263 ---- cut here ---- 265 7. IANA Considerations 267 The IANA is instructed to update the "IANA IPv6 Special-Purpose 268 Address Registry" [IANA-ADDR-REG] by adding a "[RFCXXXX]" to the 269 "RFC" column corresponding to the "fc00::/7" address block. 271 Additionally, the following footnote: 273 [4] See [RFC4193] for more details on the routability of Unique- 274 Local addresses. The Unique-Local prefix is drawn from the IPv6 275 Global Unicast Address range, but is specified as not globally 276 routed. 278 must be replaced with: 280 [4] See [RFC4193] for more details on the routability of Unique- 281 Local addresses, and [RFCXXXX] for details on the scope of Unique- 282 Local addresses. 284 NOTE: [RFCXXXX] represents the RFC number assigned by the RFC Editor 285 upon publication of this document as an RFC. 287 8. Security Considerations 289 This document does not introduce any new security considerations. 291 9. Acknowledgements 293 Fernando Gont would like to thank Brian Carpenter and Bob Hinden, for 294 providing valuable comments on earlier versions of this document. 296 Fernando Gont would like to thank Brian Carpenter for his end-less 297 help, and for the discussion that eventually led to this document. 299 10. References 301 10.1. Normative References 303 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 304 and E. Lear, "Address Allocation for Private Internets", 305 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 306 . 308 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 309 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 310 DOI 10.17487/RFC4007, March 2005, 311 . 313 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 314 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 315 . 317 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 318 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 319 2006, . 321 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, 322 "Updates to the Special-Purpose IP Address Registries", 323 BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, 324 . 326 10.2. Informative References 328 [I-D.gont-v6ops-ipv6-addressing-considerations] 329 Gont, F. and G. Gont, "IPv6 Addressing Considerations", 330 draft-gont-v6ops-ipv6-addressing-considerations-00 (work 331 in progress), December 2020. 333 [I-D.ietf-ipv6-ula-central] 334 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 335 Addresses", draft-ietf-ipv6-ula-central-02 (work in 336 progress), June 2007. 338 [IANA-ADDR-REG] 339 IANA, "IANA IPv6 Special-Purpose Address Registry", 340 . 343 [Python-ipaddr] 344 Python 3.3, "ipaddress -- IPv4/IPv6 manipulation library", 345 . 347 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 348 (IPv6) Addressing Architecture", RFC 3513, 349 DOI 10.17487/RFC3513, April 2003, 350 . 352 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 353 "Default Address Selection for Internet Protocol Version 6 354 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 355 . 357 [v6ops-thread] 358 v6ops wg, "[v6ops] I-D Action: draft-gont-v6ops-ipv6- 359 addressing-considerations-00.txt", email thread on the 360 v6ops wg mailing-list, 2020, 361 . 364 Author's Address 366 Fernando Gont 367 SI6 Networks 368 Segurola y Habana 4310, 7mo Piso 369 Villa Devoto, Ciudad Autonoma de Buenos Aires 370 Argentina 372 Email: fgont@si6networks.com 373 URI: https://www.si6networks.com