idnits 2.17.1 draft-ietf-regext-rfc7484bis-06.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 (28 January 2022) is 816 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) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 7484 (Obsoleted by RFC 9224) 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 M. Blanchet 3 Internet-Draft Viagenie 4 Obsoletes: 7484 (if approved) 28 January 2022 5 Intended status: Standards Track 6 Expires: 1 August 2022 8 Finding the Authoritative Registration Data (RDAP) Service 9 draft-ietf-regext-rfc7484bis-06 11 Abstract 13 This document specifies a method to find which Registration Data 14 Access Protocol (RDAP) server is authoritative to answer queries for 15 a requested scope, such as domain names, IP addresses, or Autonomous 16 System numbers. This document obsoletes RFC7484. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 1 August 2022. 35 Copyright Notice 37 Copyright (c) 2022 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Revised BSD License text as 46 described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Revised BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 53 3. Structure of the RDAP Bootstrap Service Registries . . . . . 3 54 4. Bootstrap Service Registry for Domain Name Space . . . . . . 5 55 5. Bootstrap Service Registries for Internet Numbers . . . . . . 6 56 5.1. Bootstrap Service Registry for IPv4 Address Space . . . . 6 57 5.2. Bootstrap Service Registry for IPv6 Address Space . . . . 7 58 5.3. Bootstrap Service Registry for AS Number Space . . . . . 9 59 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 7. Non-existent Entries or RDAP URL Values . . . . . . . . . . . 10 61 8. Deployment and Implementation Considerations . . . . . . . . 10 62 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 10. Formal Definition . . . . . . . . . . . . . . . . . . . . . . 11 64 10.1. Imported JSON Terms . . . . . . . . . . . . . . . . . . 11 65 10.2. Registry Syntax . . . . . . . . . . . . . . . . . . . . 11 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 68 12.1. RDAP Browser Mobile Application . . . . . . . . . . . . 13 69 12.2. ICANN Lookup Web Application . . . . . . . . . . . . . . 13 70 12.3. ARIN Implementation . . . . . . . . . . . . . . . . . . 14 71 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 13.1. Bootstrap Service Registry for IPv4 Address Space . . . 16 73 13.2. Bootstrap Service Registry for IPv6 Address Space . . . 16 74 13.3. Bootstrap Service Registry for AS Number Space . . . . . 16 75 13.4. Bootstrap Service Registry for Domain Name Space . . . . 16 76 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 78 14.2. Informative References . . . . . . . . . . . . . . . . . 17 79 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 80 Changes since RFC7484 . . . . . . . . . . . . . . . . . . . . . . 19 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 Querying and retrieving registration data from registries are defined 86 in Registration Data Access Protocol (RDAP) [RFC7480] [RFC7481] 87 [RFC9082] [RFC9083]. These documents do not specify where to send 88 the queries. This document specifies a method to find which server 89 is authoritative to answer queries for the requested scope. 91 Top-Level Domains (TLDs), Autonomous System (AS) numbers, and network 92 blocks are delegated by IANA to Internet registries such as TLD 93 registries and Regional Internet Registries (RIRs) that then issue 94 further delegations and maintain information about them. Thus, the 95 bootstrap information needed by RDAP clients is best generated from 96 data and processes already maintained by IANA; the relevant 97 registries already exist at [ipv4reg], [ipv6reg], [asreg], and 98 [domainreg]. This document obsoletes [RFC7484]. 100 Per this document, IANA has created new registries based on a JSON 101 format specified in this document, herein named RDAP Bootstrap 102 Service Registries. These new registries are based on the existing 103 entries of the above-mentioned registries. An RDAP client fetches 104 the RDAP Bootstrap Service Registries, extracts the data, and then 105 performs a match with the query data to find the authoritative 106 registration data server and appropriate query base URL. 108 2. Conventions Used in This Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 3. Structure of the RDAP Bootstrap Service Registries 118 The RDAP Bootstrap Service Registries, as specified in Section 13 119 below, have been made available as JSON [RFC8259] objects, which can 120 be retrieved via HTTP from locations specified by IANA. The JSON 121 object for each registry contains a series of members containing 122 metadata about the registry such as a version identifier, a timestamp 123 of the publication date of the registry, and a description. 124 Additionally, a "services" member contains the registry items 125 themselves, as an array. Each item of the array contains a second- 126 level array, with two elements, each of them being a third-level 127 array. 129 Each element of the Services Array is a second-level array with two 130 elements: in order, an Entry Array and a Service URL Array. 132 The Entry Array contains all entries that have the same set of base 133 RDAP URLs. The Service URL Array contains the list of base RDAP URLs 134 usable for the entries found in the Entry Array. Elements within 135 these two arrays are not ordered in any way. 137 An example structure of the JSON output of a RDAP Bootstrap Service 138 Registry is illustrated: 140 { 141 "version": "1.0", 142 "publication": "YYYY-MM-DDTHH:MM:SSZ", 143 "description": "Some text", 144 "services": [ 145 [ 146 ["entry1", "entry2", "entry3"], 147 [ 148 "https://registry.example.com/myrdap/", 149 "http://registry.example.com/myrdap/" 150 ] 151 ], 152 [ 153 ["entry4"], 154 [ 155 "https://example.org/" 156 ] 157 ] 158 ] 159 } 161 The formal syntax is described in Section 10. 163 The "version" corresponds to the format version of the registry. 164 This specification defines version "1.0". 166 The syntax of the "publication" value conforms to the Internet date/ 167 time format [RFC3339]. The value is the latest update date of the 168 registry by IANA. 170 The optional "description" string can contain a comment regarding the 171 content of the bootstrap object. 173 Per [RFC7258], in each array of base RDAP URLs, the secure versions 174 of the transport protocol SHOULD be preferred and tried first. For 175 example, if the base RDAP URLs array contains both HTTPS and HTTP 176 URLs, the bootstrap client SHOULD try the HTTPS version first. 178 Base RDAP URLs MUST have a trailing "/" character because they are 179 concatenated to the various segments defined in [RFC9082]. 181 JSON names MUST follow the format recommendations of section 6 of 182 [RFC7480]. Any unrecognized JSON object properties or values MUST be 183 ignored by implementations. 185 Internationalized Domain Name labels used as entries or base RDAP 186 URLs in the registries defined in this document MUST be only 187 represented using their A-label form as defined in [RFC5890]. 189 All Domain Name labels used as entries or base RDAP URLs in the 190 registries defined in this document MUST be only represented in 191 lowercase. 193 4. Bootstrap Service Registry for Domain Name Space 195 The JSON output of this registry contains domain label entries 196 attached to the root, grouped by base RDAP URLs, as shown in this 197 example. 199 { 200 "version": "1.0", 201 "publication": "2024-01-07T10:11:12Z", 202 "description": "Some text", 203 "services": [ 204 [ 205 ["net", "com"], 206 [ 207 "https://registry.example.com/myrdap/" 208 ] 209 ], 210 [ 211 ["org", "mytld"], 212 [ 213 "https://example.org/" 214 ] 215 ], 216 [ 217 ["xn--zckzah"], 218 [ 219 "https://example.net/rdap/xn--zckzah/", 220 "http://example.net/rdap/xn--zckzah/" 221 ] 222 ] 223 ] 224 } 226 The domain name's authoritative registration data service is found by 227 doing the label-wise longest match of the target domain name with the 228 domain values in the Entry Arrays in the IANA Bootstrap Service 229 Registry for Domain Name Space. The match is done per label, from 230 right to left. If the longest match results in multiple entries, 231 then those entries are considered equivalent. The values contained 232 in the Service URL Array of the matching second-level array are the 233 valid base RDAP URLs as described in [RFC9082]. 235 For example, a domain RDAP query for a.b.example.com matches the com 236 entry in one of the arrays of the registry. The base RDAP URL for 237 this query is then taken from the second element of the array, which 238 is an array of base RDAP URLs valid for this entry. The client 239 chooses one of the base URLs from this array; in this example, it 240 chooses the only one available, "https://registry.example.com/ 241 myrdap/". The segment specified in [RFC9082] is then appended to the 242 base URL to complete the query. The complete query is then 243 "https://registry.example.com/myrdap/domain/a.b.example.com". 245 If a domain RDAP query for a.b.example.com matches both com and 246 example.com entries in the registry, then the longest match applies 247 and the example.com entry is used by the client. 249 If the registry contains entries such as com and goodexample.com, 250 then a domain RDAP query for example.com only matches the com entry 251 because matching is done on a per-label basis. 253 The entry for the root of the domain name space is specified as "". 255 5. Bootstrap Service Registries for Internet Numbers 257 This section discusses IPv4 and IPv6 address space and Autonomous 258 System numbers. 260 For IP address space, the authoritative registration data service is 261 found by doing a longest match of the target address with the values 262 of the arrays in the corresponding RDAP Bootstrap Service Registry 263 for Address Space. The longest match is done the same way as in 264 packet forwarding: the addresses are converted in binary form and 265 then the binary strings are compared to find the longest match up to 266 the specified prefix length. The values contained in the second 267 element of the array are the base RDAP URLs as described in 268 [RFC9082]. The longest match method enables covering prefixes of a 269 larger address space pointing to one base RDAP URL while more 270 specific prefixes within the covering prefix are being served by 271 another base RDAP URL. 273 5.1. Bootstrap Service Registry for IPv4 Address Space 275 The JSON output of this registry contains IPv4 prefix entries, 276 specified in Classless Inter-domain Routing (CIDR) format [RFC4632] 277 and grouped by RDAP URLs, as shown in this example. 279 { 280 "version": "1.0", 281 "publication": "2024-01-07T10:11:12Z", 282 "description": "RDAP Bootstrap file for example registries.", 283 "services": [ 284 [ 285 ["198.51.100.0/24", "192.0.0.0/8"], 286 [ 287 "https://rir1.example.com/myrdap/" 288 ] 289 ], 290 [ 291 ["203.0.113.0/24", "192.0.2.0/24"], 292 [ 293 "https://example.org/" 294 ] 295 ], 296 [ 297 ["203.0.113.0/28"], 298 [ 299 "https://example.net/rdaprir2/", 300 "http://example.net/rdaprir2/" 301 ] 302 ] 303 ] 304 } 306 For example, a query for "192.0.2.1/25" matches the "192.0.0.0/8" 307 entry and the "192.0.2.0/24" entry in the example registry above. 308 The latter is chosen by the client because it is the longest match. 309 The base RDAP URL for this query is then taken from the second 310 element of the array, which is an array of base RDAP URLs valid for 311 this entry. The client chooses one of the base URLs from this array; 312 in this example, it chooses the only one available, 313 "https://example.org/". The {resource} specified in [RFC9082] is 314 then appended to the base URL to complete the query. The complete 315 query is then "https://example.org/ip/192.0.2.1/25". 317 5.2. Bootstrap Service Registry for IPv6 Address Space 319 The JSON output of this registry contains IPv6 prefix entries, using 320 [RFC5952] text representation of the address prefixes format, grouped 321 by base RDAP URLs, as shown in this example. 323 { 324 "version": "1.0", 325 "publication": "2024-01-07T10:11:12Z", 326 "description": "RDAP Bootstrap file for example registries.", 327 "services": [ 328 [ 329 ["2001:db8::/34"], 330 [ 331 "https://rir2.example.com/myrdap/" 332 ] 333 ], 334 [ 335 ["2001:db8:4000::/36", "2001:db8:ffff::/48"], 336 [ 337 "https://example.org/" 338 ] 339 ], 340 [ 341 ["2001:db8:1000::/36"], 342 [ 343 "https://example.net/rdaprir2/", 344 "http://example.net/rdaprir2/" 345 ] 346 ] 347 ] 348 } 350 For example, a query for "2001:db8:1000::/48" matches the 351 "2001:db8::/34" entry and the "2001:db8:1000::/36" entry in the 352 example registry above. The latter is chosen by the client because 353 it is the longest match. The base RDAP URL for this query is then 354 taken from the second element of the array, which is an array of base 355 RDAP URLs valid for this entry. The client chooses one of the base 356 URLs from this array; in this example, it chooses 357 "https://example.net/rdaprir2/" because it's the secure version of 358 the protocol. The segment specified in [RFC9082] is then appended to 359 the base URL to complete the query. The complete query is, 360 therefore, "https://example.net/rdaprir2/ip/2001:db8:1000::/48". If 361 the target RDAP server does not answer, the client can then use 362 another URL prefix from the array. 364 5.3. Bootstrap Service Registry for AS Number Space 366 The JSON output of this registry contains Autonomous Systems number 367 ranges entries, grouped by base RDAP URLs, as shown in this example. 368 The Entry Array is an array containing the list of AS number ranges 369 served by the base RDAP URLs found in the second element. Each 370 element of the array contains two AS numbers represented in decimal 371 format, separated by a hyphen, that represents the range of AS 372 numbers between the two AS numbers (inclusive), where values are in 373 increasing order (e.g. 100-200, not 200-100). A single AS number is 374 represented as a range of two identical AS numbers. AS numbers are 375 represented as 'asplain' as defined in [RFC5396]. Ranges MUST NOT 376 overlap. 378 { 379 "version": "1.0", 380 "publication": "2024-01-07T10:11:12Z", 381 "description": "RDAP Bootstrap file for example registries.", 382 "services": [ 383 [ 384 ["64496-64496"], 385 [ 386 "https://rir3.example.com/myrdap/" 387 ] 388 ], 389 [ 390 ["64497-64510", "65536-65551"], 391 [ 392 "https://example.org/" 393 ] 394 ], 395 [ 396 ["64512-65534"], 397 [ 398 "http://example.net/rdaprir2/", 399 "https://example.net/rdaprir2/" 400 ] 401 ] 402 ] 403 } 405 For example, a query for AS 65411 matches the 64512-65534 entry in 406 the example registry above. The base RDAP URL for this query is then 407 taken from the second element of the array, which is an array of base 408 RDAP URLs valid for this entry. The client chooses one of the base 409 URLs from this array; in this example, it chooses 410 "https://example.net/rdaprir2/". The segment specified in [RFC9082] 411 is then appended to the base URL to complete the query. The complete 412 query is, therefore, "https://example.net/rdaprir2/autnum/65411". If 413 the server does not answer, the client can then use another URL 414 prefix from the array. 416 6. Entity 418 Entities (such as contacts, registrants, or registrars) can be 419 queried by handle as described in [RFC9082]. Since there is no 420 global namespace for entities, this document does not describe how to 421 find the authoritative RDAP server for entities. However, it is 422 possible that, if the entity identifier was received from a previous 423 query, the same RDAP server could be queried for that entity, or the 424 entity identifier itself is a fully qualified URL that can be 425 queried. The mechanism described in [RFC8521] MAY also be used. 427 7. Non-existent Entries or RDAP URL Values 429 The registries may not contain the requested value. In these cases, 430 there is no known RDAP server for that requested value, and the 431 client SHOULD provide an appropriate error message to the user. 433 8. Deployment and Implementation Considerations 435 This method relies on the fact that RDAP clients are fetching the 436 IANA registries to then find the servers locally. Clients SHOULD NOT 437 fetch the registry on every RDAP request. Clients SHOULD cache the 438 registry, but use underlying protocol signaling, such as the HTTP 439 Expires header field [RFC7234], to identify when it is time to 440 refresh the cached registry. 442 Some authorities of registration data may work together on sharing 443 their information for a common service, including mutual redirection 444 [REDIRECT-RDAP]. 446 When a new object is allocated, such as a new AS range, a new TLD, or 447 a new IP address range, there is no guarantee that this new object 448 will have an entry in the corresponding bootstrap RDAP registry, 449 since the setup of the RDAP server for this new entry may become live 450 and registered later. Therefore, the clients should expect that even 451 if an object, such as TLD, IP address range, or AS range is 452 allocated, the existence of the entry in the corresponding bootstrap 453 registry is not guaranteed. 455 9. Limitations 457 This method does not provide a direct way to find authoritative RDAP 458 servers for any other objects than the ones described in this 459 document. In particular, the following objects are not bootstrapped 460 with the method described in this document: 462 * entities 464 * queries using search patterns that do not contain a terminating 465 string that matches some entries in the registries 467 * nameservers 469 * help 471 10. Formal Definition 473 This section is the formal definition of the registries. The 474 structure of JSON objects and arrays using a set of primitive 475 elements is defined in [RFC8259]. Those elements are used to 476 describe the JSON structure of the registries. 478 10.1. Imported JSON Terms 480 * OBJECT: a JSON object, defined in Section 4 of [RFC8259] 482 * MEMBER: a member of a JSON object, defined in Section 4 of 483 [RFC8259] 485 * MEMBER-NAME: the name of a MEMBER, defined as a "string" in 486 Section 4 of [RFC8259] 488 * MEMBER-VALUE: the value of a MEMBER, defined as a "value" in 489 Section 4 of [RFC8259] 491 * ARRAY: an array, defined in Section 5 of [RFC8259] 493 * ARRAY-VALUE: an element of an ARRAY, defined in Section 5 of 494 [RFC8259] 496 * STRING: a "string", as defined in Section 7 of [RFC8259] 498 10.2. Registry Syntax 500 Using the above terms for the JSON structures, the syntax of a 501 registry is defined as follows: 503 * rdap-bootstrap-registry: an OBJECT containing a MEMBER version and 504 a MEMBER publication, an optional MEMBER description, and a MEMBER 505 services-list 507 * version: a MEMBER with MEMBER-NAME "version" and MEMBER-VALUE a 508 STRING 510 * publication: a MEMBER with MEMBER-NAME "publication" and MEMBER- 511 VALUE a STRING 513 * description: a MEMBER with MEMBER-NAME "description" and MEMBER- 514 VALUE a STRING 516 * services-list: a MEMBER with MEMBER-NAME "services" and MEMBER- 517 VALUE a services-array 519 * services-array: an ARRAY, where each ARRAY-VALUE is a service 521 * service: an ARRAY of 2 elements, where the first ARRAY-VALUE is an 522 entry-list and the second ARRAY-VALUE is a service-uri-list 524 * entry-list: an ARRAY, where each ARRAY-VALUE is an entry 526 * entry: a STRING 528 * service-uri-list: an ARRAY, where each ARRAY-VALUE is a service- 529 uri 531 * service-uri: a STRING 533 11. Security Considerations 535 By providing a bootstrap method to find RDAP servers, this document 536 helps to ensure that the end users will get the RDAP data from an 537 authoritative source, instead of from rogue sources. The method has 538 the same security properties as the RDAP protocols themselves. The 539 transport used to access the registries uses TLS [RFC8446]. 541 Additional considerations on using RDAP are described in [RFC7481]. 543 12. Implementation Status 545 NOTE: Please remove this section and the reference to RFC 7942 prior 546 to publication as an RFC. 548 This section records the status of known implementations of the 549 protocol defined by this specification at the time of posting of this 550 Internet-Draft, and is based on a proposal described in [RFC7942]. 552 The description of implementations in this section is intended to 553 assist the IETF in its decision processes in progressing drafts to 554 RFCs. Please note that the listing of any individual implementation 555 here does not imply endorsement by the IETF. Furthermore, no effort 556 has been spent to verify the information presented here that was 557 supplied by IETF contributors. This is not intended as, and must not 558 be construed to be, a catalog of available implementations or their 559 features. Readers are advised to note that other implementations may 560 exist. 562 According to [RFC7942], "this will allow reviewers and working groups 563 to assign due consideration to documents that have the benefit of 564 running code, which may serve as evidence of valuable experimentation 565 and feedback that have made the implemented protocols more mature. 566 It is up to the individual working groups to use this information as 567 they see fit". 569 12.1. RDAP Browser Mobile Application 571 Responsible Organization: Viagenie 573 Author: Marc Blanchet 575 Location: https://viagenie.ca/rdapbrowser/ 577 Description: RDAP Browser is an RDAP client for domain names, IP 578 addresses and AS numbers fetching the IANA registries described in 579 this document to find the right authoritative RDAP server. End 580 user can query any domain name, IP address or AS number and the 581 registration data will be shown on the screen. 583 Level of Maturity: Production (i.e. in the Android and iOS App 584 stores since August 2019) 586 Contact Information: rdapbrowser@viagenie.ca 588 Information last updated: March 2021 590 12.2. ICANN Lookup Web Application 592 Responsible Organization: ICANN 594 Location: https://lookup.icann.org 595 Description: ICANN's Domain Name Registration Data Lookup is an 596 RDAP client for domain names fetching the IANA regis tries 597 described in this document to find the right authoritative RDAP 598 server. End user can query any domain name and the registration 599 data will be shown on the screen. 601 Level of Maturity: Production 603 Information last updated: March 2021 605 12.3. ARIN Implementation 607 Responsible Organization: ARIN 609 Base URL: https://rdap-bootstrap.arin.net/bootstrap ( Sample 610 query: https://rdap-bootstrap.arin.net/bootstrap/autnum/1 ) 612 Description: ARIN RDAP Bootstrap server aids clients by reading 613 the bootstrapping information published by IANA and using it to 614 send HTTP redirects to RDAP queries. RDAP clients 615 https://search.arin.net/ and NicInfo ( https://github.com/arineng/ 616 nicinfo ) use this bootstrap service. The underlying server 617 software is open-sourced at https://github.com/arineng/ 618 rdap_bootstrap_server . 620 Level of Maturity: Production 622 Contact Information: info@arin.net 624 Information Last Updated: Nov 2020 626 13. IANA Considerations 628 IANA has created the RDAP Bootstrap Services Registries, listed 629 below, and made them available as JSON objects. The contents of 630 these registries are described in Section 3, Section 4, and 631 Section 5, with the formal syntax specified in Section 10. The 632 registries MUST be accessible only through HTTPS (TLS [RFC8446]) 633 transport. 635 The process for adding or updating entries in these registries 636 differs from the normal IANA registry processes: these registries are 637 generated from the data, processes, and policies maintained by IANA 638 in their allocation registries ([ipv4reg], [ipv6reg], [asreg], and 639 [domainreg]), with the addition of new RDAP server information. 641 IANA updates RDAP Bootstrap Services Registries entries from the 642 allocation registries as those registries are updated. 644 This document does not change any policies related to the allocation 645 registries; IANA has provided a mechanism for collecting the RDAP 646 server information. 648 IANA has created a new top-level category on the Protocol Registries 649 page, . The group is called 650 "Registration Data Access Protocol (RDAP)". Each of the RDAP 651 Bootstrap Services Registries has been made available for general 652 public on-demand download in the JSON format, and that registry's URI 653 is listed directly on the Protocol Registries page. 655 Other normal registries will be added to this group by other 656 documents, but the reason the URIs for these registries are clearly 657 listed on the main page is to make those URIs obvious to implementers 658 -- these are registries that will be accessed by software, as well as 659 by humans using them for reference information. 661 Because these registries will be accessed by software, the download 662 demand for the RDAP Bootstrap Services Registries may be unusually 663 high compared to normal IANA registries. The technical 664 infrastructure by which registries are published has been put in 665 place by IANA to support the load. Since the publication of 666 [RFC7484], no issue have been reported regarding the load or the 667 service. 669 As discussed in Section 8, software that accesses these registries 670 will depend on the HTTP Expires header field to limit their query 671 rate. It is, therefore, important for that header field to be 672 properly set to provide timely information as the registries change, 673 while maintaining a reasonable load on the IANA servers. 675 The HTTP Content-Type returned to clients accessing these JSON- 676 formatted registries MUST be "application/json", as defined in 677 [RFC8259]. 679 Because of how information in the RDAP Bootstrap Services Registries 680 is grouped and formatted, the registry entries may not be sortable. 681 It is, therefore, not required or expected that the entries be 682 ordered in any way. 684 NOTE TO IANA: Please update the registries to reference this new RFC 685 instead of RFC 7484 once this document is approved by the IESG and 686 published by the RFC Editor". RFC-Editor, please remove this 687 paragraph before publication 689 13.1. Bootstrap Service Registry for IPv4 Address Space 691 Entries in this registry contain at least the following: 693 * a CIDR [RFC4632] specification of the network block being 694 registered. 696 * one or more URLs that provide the RDAP service regarding this 697 registration. 699 13.2. Bootstrap Service Registry for IPv6 Address Space 701 Entries in this registry contain at least the following: 703 * an IPv6 prefix [RFC5952] specification of the network block being 704 registered. 706 * one or more URLs that provide the RDAP service regarding this 707 registration. 709 13.3. Bootstrap Service Registry for AS Number Space 711 Entries in this registry contain at least the following: 713 * a range of Autonomous System numbers being registered. 715 * one or more URLs that provide the RDAP service regarding this 716 registration. 718 13.4. Bootstrap Service Registry for Domain Name Space 720 Entries in this registry contain at least the following: 722 * a domain name attached to the root being registered. 724 * one or more URLs that provide the RDAP service regarding this 725 registration. 727 14. References 729 14.1. Normative References 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, 733 DOI 10.17487/RFC2119, March 1997, 734 . 736 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 737 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 738 . 740 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 741 (CIDR): The Internet Address Assignment and Aggregation 742 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 743 2006, . 745 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of 746 Autonomous System (AS) Numbers", RFC 5396, 747 DOI 10.17487/RFC5396, December 2008, 748 . 750 [RFC5890] Klensin, J., "Internationalized Domain Names for 751 Applications (IDNA): Definitions and Document Framework", 752 RFC 5890, DOI 10.17487/RFC5890, August 2010, 753 . 755 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 756 Address Text Representation", RFC 5952, 757 DOI 10.17487/RFC5952, August 2010, 758 . 760 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 761 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 762 2014, . 764 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 765 Registration Data Access Protocol (RDAP)", STD 95, 766 RFC 7480, DOI 10.17487/RFC7480, March 2015, 767 . 769 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 770 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 771 May 2017, . 773 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 774 Interchange Format", STD 90, RFC 8259, 775 DOI 10.17487/RFC8259, December 2017, 776 . 778 14.2. Informative References 780 [asreg] IANA, "Autonomous System (AS) Numbers", 781 . 783 [domainreg] 784 IANA, "Root Zone Database", 785 . 787 [ipv4reg] IANA, "IPv4 Address Space Registry", 788 . 790 [ipv6reg] IANA, "IPv6 Global Unicast Address Assignments", 791 . 794 [REDIRECT-RDAP] 795 Martinez, C., Zhou, L., and G. Rada, "Redirection Service 796 for Registration Data Access Protocol", Work in Progress, 797 draft-ietf-weirds-redirects-04, July 2014. 799 [RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for 800 Reputation Interchange", RFC 7071, DOI 10.17487/RFC7071, 801 November 2013, . 803 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 804 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 805 RFC 7234, DOI 10.17487/RFC7234, June 2014, 806 . 808 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 809 Registration Data Access Protocol (RDAP)", STD 95, 810 RFC 7481, DOI 10.17487/RFC7481, March 2015, 811 . 813 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 814 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 815 2015, . 817 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 818 Code: The Implementation Status Section", BCP 205, 819 RFC 7942, DOI 10.17487/RFC7942, July 2016, 820 . 822 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 823 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 824 . 826 [RFC8521] Hollenbeck, S. and A. Newton, "Registration Data Access 827 Protocol (RDAP) Object Tagging", BCP 221, RFC 8521, 828 DOI 10.17487/RFC8521, November 2018, 829 . 831 [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access 832 Protocol (RDAP) Query Format", STD 95, RFC 9082, 833 DOI 10.17487/RFC9082, June 2021, 834 . 836 [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the 837 Registration Data Access Protocol (RDAP)", STD 95, 838 RFC 9083, DOI 10.17487/RFC9083, June 2021, 839 . 841 Acknowledgements 843 The WEIRDS working group had multiple discussions on this topic, 844 including a session during IETF 84, where various methods such as 845 in-DNS and others were debated. The idea of using IANA registries 846 was discovered by the author during discussions with his colleagues 847 as well as by a comment from Andy Newton. All the people involved in 848 these discussions are herein acknowledged. Linlin Zhou, Jean- 849 Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott 850 Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy, Tom 851 Harrison, Naoki Kambe, Alexander Mayrhofer, Edward Lewis, Pete 852 Resnick, Alessandro Vesely, Bert Greevenbosch, Barry Leiba, Jari 853 Arkko, Kathleen Moriaty, Stephen Farrell, Richard Barnes, and Jean- 854 Francois Tremblay have provided input and suggestions to this 855 document. Guillaume Leclanche was a coauthor of this document for 856 some revisions; his support is therein acknowledged and greatly 857 appreciated. The section on formal definition was inspired by 858 Section 6.2 of [RFC7071]. This new version got comments and 859 suggestions from: Gavin Brown, Patrick Mevzek, John Levine, Jasdip 860 Singh, George Michaelson, Scott Hollenbeck, Russ Housley, Joel 861 Halpern, Lars Eggert, Benjamin Kaduk, Scott Kelly, Eric Vyncke, John 862 Scudder, Erik Kline, Robert Wilton. Errata of RFC7484 were submitted 863 by Pieter Vandepitte and were applied to this version. 865 Changes since RFC7484 867 There are no substantive changes except for updates to the 868 implementation status and minor clarifications. This update is 869 primarily to meet the requirements for moving to Internet Standard. 871 Author's Address 873 Marc Blanchet 874 Viagenie 875 246 Aberdeen 876 Quebec QC G1R 2E1 877 Canada 878 Email: Marc.Blanchet@viagenie.ca 879 URI: https://viagenie.ca