idnits 2.17.1 draft-arends-private-use-tld-02.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 (June 08, 2020) is 1418 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) -- Obsolete informational reference (is this intentional?): RFC 8499 (ref. 'BCP-219') (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission R. Arends 3 Internet-Draft E. Lewis 4 Intended status: Best Current Practice ICANN 5 Expires: December 10, 2020 June 08, 2020 7 Top-level Domains for Private Internets 8 draft-arends-private-use-tld-02 10 Abstract 12 There are no defined private-use namespaces in the Domain Name System 13 (DNS). For a domain name to be considered private-use, it needs to 14 be future-proof in that its top-level domain will never be delegated 15 from the root zone. The lack of a private-use namespace has led to 16 locally configured namespaces with a top-level domain that is not 17 future proof. 19 The DNS needs an equivalent of the facilities provided by BCP 5 (RFC 20 1918) for private internets, i.e. a range of short, semantic-free 21 top-level domains that can be used in private internets without the 22 risk of being globally delegated from the root zone. 24 The ISO 3166 standard is used for the definition of eligible 25 designations for country-code top-level Domains. This standard is 26 maintained by the ISO 3166 Maintenance Agency. The ISO 3166 standard 27 includes a set of user-assigned code elements that can be used by 28 those who need to add further names to their local applications. 30 Because of the rules set out by ISO in their standard, it is 31 extremely unlikely that these user-assigned code elements would ever 32 conflict with delegations in the root zone under current practices. 33 This document explicitly reserves these code elements to be safely 34 used as top-level domains for private DNS resolution. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 10, 2020. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. The ISO 3166-1 alpha-2 and Two-Letter Top-Level Domains . . . 4 72 3. ISO 3166-1 alpha-2 User-assigned Code Elements . . . . . . . 4 73 4. Examples of Current Uses of the User-assigned Code Elements. 5 74 5. Private-use top-level Domains . . . . . . . . . . . . . . . . 8 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 9. Informative References . . . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 In private networks where a hostname has no utility in the global 84 namespace, it is convenient to have a private-use namespace. Such 85 deployments could theoretically use sub-domains of a domain 86 registered for the specific hosting entity, though not all such 87 configurations have such a domain available. When the hostname is 88 solely used in a private network, it is not necessary that it 89 resolves globally. 91 Another situation is where applications use identifiers that are 92 similar in appearance to domain names, and may be interpreted by 93 software as domain names, but are not intended to use the global DNS 94 resolution service. Using a private-use namespace helps guard 95 against conflicts with the global DNS resolution system. 97 Note that a private-use namespace is not a subset of a registered 98 special use namespace [IANA-Special]. There is no facility to 99 register a specific label using the process defined in [RFC6761]. 100 The process in RFC 6761 requires that a label has some kind of 101 special handling in order to be considered special. A private-use 102 namespace can be considered special on a policy level, but not on a 103 technical or protocol level. 105 Many protocols outside the DNS have a defined set of elements for 106 private use, or an identifier that indicates private use, such as 107 "X-headers" MIME types [RFC2045], addresses for private internets 108 [BCP-5], the "x-" sub-tag in private-use language tags [BCP-47], 109 private-use Autonomous System Numbers [BCP-6], and private-use DNS 110 RRTypes and RCODEs [BCP-42]. 112 There is currently no such facility for the DNS namespace. A user is 113 required to resort to registering a globally unique domain where a 114 locally unique domain would suffice, or may configure a domain name 115 that is not currently delegated from the root zone. Additionally, 116 there are plenty of examples of device vendors that ship networking 117 devices with a default setting for DHCP [RFC2131] option 15 (domain 118 name) [RFC2132], containing a top-level domain that is believed to 119 not be delegated in the root zone. 121 In practice, the lack of a private-use namespace facility has led to 122 the deployment of arbitrary, unregistered, semantically meaningful 123 top-level domains, such as ".home", ".dhcp", ".lan", ".localdomain", 124 ".internal", ".dlink", ".ip" and ".corp" [ITHI]. These examples of 125 locally configured strings are derived from traffic to the ICANN 126 Managed Root Servers [IMRS] and are part of the most popular observed 127 query names [BCP-219]. 129 While these commonly chosen strings currently do not exist in the 130 root zone, there is no guarantee that these strings will not be 131 delegated in the root zone in the future. Therefore, there is no 132 guarantee that the local use of these strings (or other strings that 133 might be chosen for private use) will be stable, safe, and secure. 134 Similarly, there is no guarantee that any of these strings will be 135 deemed special-use via an application according to [RFC6761]. 137 There are many uses for private-use names. It is not feasible to 138 assign a semantically meaningful, relatively short top-level label to 139 each individual private-use of a namespace in multiple languages. 140 Similar to "X-headers" MIME types, and analogous in concept to 141 address allocation for private internets, this document defines a 142 range of abstract, two-letter labels that are aligned with the user- 143 assigned two-letter code elements in the ISO 3166-1 alpha-2 144 [ISO3166-1] standard. 146 2. The ISO 3166-1 alpha-2 and Two-Letter Top-Level Domains 148 IANA's practice of governing the delegation of ASCII two-letter 149 domain names in the DNS [STD13] root zone is to align it with 150 assignment of two-letter (known as "alpha-2") code elements in the 151 ISO 3166-1 standard [ISO3166-1]. The ISO 3166-1 standard contains 152 many categories of code elements, with the "officially assigned" and 153 some "exceptionally reserved" code elements being used in the DNS to 154 represent entities as country-code top-level domains (ccTLDs) 155 [RFC1591]. The interrelationship is documented in "ICANN and the 156 ISO, A Common Interest in ISO Standard 3166" [ICANNISO]. 158 In addition to the assigned, available, and reserved code elements, 159 there are code elements designated as "user-assigned". The intent of 160 user-assigned code elements is to provide the user with a code 161 element when no other code element satisfies the intended use. 163 3. ISO 3166-1 alpha-2 User-assigned Code Elements 165 The ISO 3166-1 standard states in section 5.2: 167 "In addition, exactly 42 alpha-2 code elements are not used in the 168 ISO 3166, AA, QM to QZ, XA to XZ, ZZ." 170 And explains in clause 8.1 "Special Provisions": 172 "Users sometimes need to extend or alter the use of country-code 173 elements for special purposes. The following provisions give 174 guidance for meeting such needs within the framework of this part 175 of ISO 3166. " 177 And finally, clause 8.1.3 "User assigned code element": 179 "If users need code elements to represent country names not 180 included in this part of ISO 3166, the series of letters AA, QM to 181 QZ, XA to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ, XAA 182 to XZZ, and ZZA to ZZZ respectively and the series of numbers 900 183 to 999 are available. NOTE Users are advised that the above 184 series of codes are not universals, those code elements are not 185 compatible between different entities." 187 As shown above, the ISO 3166-1 user-assigned alpha-2 code elements 188 are defined to be AA, QM to QZ, XA to XZ, and ZZ. The ranges ("to") 189 are alphabetic and contain only characters in the US-ASCII definition 190 [STD80]. 192 It is unlikely that the user-assigned range will change. 194 4. Examples of Current Uses of the User-assigned Code Elements. 196 Using code elements to represent an entity other than a country name 197 may appear to deviate from the intended use of the ISO 3166-1 198 standard. However, many organizations, including the IETF and the 199 ISO, have used the user-assigned range to represent entities other 200 than country names. The following list is not exhaustive but 201 illustrates the wide variety of current uses of codes within the ISO 202 3166-1 user-assigned alpha-2 range. 204 o The International Standard Recording Code (ISRC) [ISO3901] uses 205 code element "ZZ" from the User-assigned range for direct 206 registrants independent of any country. 208 o The ISO Currency Codes standard [ISO4217] uses code elements "XA" 209 to "XZ" from the user-assigned range for transactions and precious 210 metals. 212 o International Securities Identification Numbers [ISO6166] uses the 213 following code elements from the user-assigned range: 215 QS: internally used by Euroclear France 217 QT: internally used in Switzerland 219 QW: internally used in WM Datenservice Germany for historical data 221 XA: CUSIP Global Services substitute agencies 223 XB: NSD Russia substitute agencies 225 XC: WM Datenservice Germany substitute agencies 227 XD: SIX Telekurs substitute agencies 229 XF: internally assigned, non-unique numbers 231 XS: Euroclear and Clearstream international securities 233 o The International Civil Aviation Organization [ICAO] Machine 234 Readable Travel Documents standard uses code element "ZZ" from the 235 user-assigned range for UN travel documents. 237 o The World Intellectual Property Organization [WIPO] Standard 3 238 uses the following code elements from the user-assigned range: 240 QZ: Community Plant Variety Office (European Union) (CPVO). 242 XN: Nordic Patent Institute (NPI). 244 XU: International Union for the Protection of New Varieties of 245 Plants (UPOV). 247 XV: Visegrad Patent Institute (VPI) 249 XX: recommended to refer to unknown states, other entities or 250 organizations. 252 o The United Nations Code for Trade and Transport Locations 253 [UNLOCODE] uses the code element "XZ" from the user-assigned range 254 for international waters in accordance with ISO 3166-1 clause 255 8.1.3: 257 "3.2.5 In cases where no ISO 3166 country-code element is 258 available, e.g. installations in international waters or 259 international cooperation zones, the code element "XZ", available 260 for user assignment in accordance with clause 8.1.3 of ISO 261 3166-1/1997, will be used." 263 o The World Bank Country API [WORLDBANK] uses the following code 264 elements from the User-assigned range: 266 XC: Euro area 268 XD: High income 270 XE: Heavily indebted poor countries (HIPC) 272 XF: International Bank for Reconstruction and Development 274 XH: Blend 276 XI: International Development Association 278 XJ: Latin America and Caribbean (excluding high income) 280 XL: Least developed countries: UN classification 282 XM: Low income 284 XN: Lower middle income 286 XO: Low & middle income 288 XP: Middle income 289 XQ: Middle East & North Africa (excluding high income) 291 XT: Upper middle income 293 XU: North America 295 XX: Not classified 297 XY: Not Classified 299 o The Interpol Implementation data format for the interchange of 300 fingerprint, facial & scar-mark-tattoo information [INTERPOL] uses 301 code element "ZZ" from the user-assigned range as follows: 302 Destination Agency Identifier "ZZ/ALL" is reserved for 303 transactions which shall be distributed by INTERPOL AFIS to all 304 INTERPOL member states." 306 o The Certificate Authority Browser Forum Baseline Requirements for 307 the Issuance and Management of Publicly-Trusted Certificates 308 [CABForum] states that if a country is not represented by an 309 official ISO 3166-1 alpha-2 country-code, the CA may specify the 310 user-assigned code element "XX" to indicate that an official code 311 element has not been assigned. 313 o The UNICODE Common Locale Data Repository (CLDR) [UNICODE] version 314 37 uses the following code elements from the user-assigned range: 316 QO: Outlying Oceania; countries in Oceania that do not have a 317 subcontinent. 319 XA: Pseudo-Accents; special code indicating derived testing locale 320 with English + added accents and lengthened. 322 XB: Pseudo-Bidi; special code indicating derived testing locale 323 with forced RTL English. 325 ZZ: Unknown Region; used in APIs or as a replacement for invalid 326 code. 328 o The IETF Best Current Practice 47 [BCP-47] contains a section and 329 examples dedicated to private-use subtags, using code elements 330 from the user-assigned range: 332 "For example, the region subtags 'AA', 'ZZ', and those in the 333 ranges 'QM'-'QZ' and 'XA'-'XZ' (derived from the ISO 3166-1 334 alpha-2 private use codes) can be used to form a language tag. A 335 tag such as "zh-Hans-XQ" conveys a great deal of public, 336 interchangeable information about the language material" 338 o The IETF Proposed Standard "Internationalized Domain Names for 339 Applications" [RFC5890] uses the XN-- prefix. The method that was 340 used to decide on the prefix was explained in an email from the 341 IANA to the IETF IDN Working Group list [XNIDN]: 343 "The following steps will be used to select the two-character 344 code: 346 The code will be selected from among a subset of the entries on 347 the ISO 3166-1, clause 8.1.3 User-assigned alpha-2 code elements: 348 AA, QM to QZ, XA to XZ, and ZZ. The selection is limited to these 349 codes because of the following: 351 The use of ISO 3166-1 User-assigned elements removes the 352 possibility that the code will duplicate a present or future ccTLD 353 code." 355 5. Private-use top-level Domains 357 The user-assigned classification of these code elements in the ISO 358 3166-1 alpha-2 standard allows for the assumption that these code 359 elements will not risk delegation as country-code top-level Domains 360 through future assignments to represent a country or territory. To 361 quote [XNIDN]: 363 "The use of ISO 3166-1 User-assigned elements removes the 364 possibility that the code will duplicate a present or future ccTLD 365 code." 367 Using these code elements as top-level domains for the purpose of 368 private-use TLDs is in line with the intended use of these code 369 elements and follows the many examples of other standards and 370 protocols. Furthermore, they are short and free of any semantic 371 meaning. 373 This document does not recommend any specific ISO 3166-1 alpha-2 374 user-assigned code as a private use, but instead proposes that any of 375 them can be used by a network or application for private use. That 376 is, there is no attempt to choose just one of the ISO 3166-1 Alpha-2 377 user-assigned codes for use as private-use TLDs, just as other 378 organizations use multiple user-assigned codes for many internal 379 purposes. 381 Note that there may be software that treats labels beginning with XN 382 differently due to the use of the XN-- prefix in internationalized 383 domain names [RFC5890]. 385 6. IANA Considerations 387 This document makes the observation that the policy of assigning 388 ccTLD labels is to align with the ISO-3166-1 alpha-2 standard 389 [RFC1591], which includes user-assigned code elements that will never 390 be assigned to a territory [ISO3166-1]. This is then consistent with 391 existing policies that those user-assigned codes will never be 392 delegated from the DNS root zone and, for that reason, will never 393 give rise to collisions with any future new TLD. 395 7. Security Considerations 397 Use of private-use identifiers of any sort almost always results in 398 unexpected collisions in practice. This has repeatedly been shown 399 for private-use addresses, private-use identifiers (such as "x- 400 headers") and private-use names in the DNS. These unexpected 401 collisions can easily have security ramifications that are well 402 beyond what the user understands. 404 8. Acknowledgements 406 This document is based on an earlier draft by Ed Lewis. David 407 Conrad, Paul Hoffman, Sion Lloyd, Alain Durand, Jaap Akkerhuis, Kal 408 Feher, Andrew Sullivan, Joe Abley, Petr Spacek, Patrick Mevzek and 409 Kim Davies have played a role. 411 9. Informative References 413 [BCP-219] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 414 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 415 January 2019, . 417 [BCP-42] Eastlake 3rd, D., "Domain Name System (DNS) IANA 418 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 419 April 2013, . 421 [BCP-47] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 422 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 423 September 2009, . 425 [BCP-5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 426 and E. Lear, "Address Allocation for Private Internets", 427 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 428 . 430 [BCP-6] Mitchell, J., "Autonomous System (AS) Reservation for 431 Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 432 2013, . 434 [CABForum] 435 "CA/Browser Forum Baseline Requirements for the Issuance 436 and Management of Publicly-Trusted Certificates, version 437 1.6.9", March 2020, . 440 [IANA-Special] 441 "Special-Use Domain Names", n.d., 442 . 445 [ICANNISO] 446 "ICANN and the International Organization for 447 Standardization (ISO)", n.d., 448 . 451 [ICAO] "International Civil Aviation Organization, Machine 452 Readable Travel Documents, Part 3; Specifications Common 453 to all MRTDs", n.d., . 456 [IMRS] "ICANN Managed Root Server", n.d., 457 . 459 [INTERPOL] 460 "Interpol Implementation data format for the interchange 461 of fingerprint, facial & smt information", n.d., 462 . 465 [ISO3166-1] 466 "ISO 3166-1:2013 Codes for the representation of names of 467 countries and their subdivisions - Part 1: Country codes", 468 2013, . 470 [ISO3901] "Information and documentation -- International Standard 471 Recording Code (ISRC)", n.d., . 474 [ISO4217] "ISO 4217; Codes for the representation of currencies and 475 funds", n.d., . 478 [ISO6166] "Securities and related financial instruments -- 479 International securities identification numbering system 480 (ISIN)", n.d., . 482 [ITHI] "ICANN's Identifier Technology Health Indicator; Queries 483 to frequently leaked strings", n.d., 484 . 486 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 487 RFC 1591, DOI 10.17487/RFC1591, March 1994, 488 . 490 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 491 Extensions (MIME) Part One: Format of Internet Message 492 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 493 . 495 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 496 RFC 2131, DOI 10.17487/RFC2131, March 1997, 497 . 499 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 500 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 501 . 503 [RFC5890] Klensin, J., "Internationalized Domain Names for 504 Applications (IDNA): Definitions and Document Framework", 505 RFC 5890, DOI 10.17487/RFC5890, August 2010, 506 . 508 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 509 RFC 6761, DOI 10.17487/RFC6761, February 2013, 510 . 512 [STD13] Mockapetris, P., "Domain names - concepts and facilities", 513 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 514 . 516 [STD80] Cerf, V., "ASCII format for network interchange", STD 80, 517 RFC 20, DOI 10.17487/RFC0020, October 1969, 518 . 520 [UNICODE] "CLDRv37 - Unicode Common Locale Data Repository version 521 37", April 2020, 522 . 524 [UNLOCODE] 525 "United Nations Code for Trade and Transport Locations; 526 UN/LOCODE Manual", n.d., 527 . 530 [WIPO] "World Intellectual Property Organization; Recommended 531 standard on two-letter codes for the representation of 532 states, other entities and intergovernmental 533 organizations.", n.d., 534 . 537 [WORLDBANK] 538 "Worldbank API V2 Country API", n.d.. 540 [XNIDN] "Results of IANA Selection of IDNA Prefix", February 2003, 541 . 543 Authors' Addresses 545 Roy Arends 546 ICANN 548 Email: roy.arends@icann.org 550 Ed Lewis 551 ICANN 553 Email: ed.lewis@icann.org