summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7484.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7484.txt')
-rw-r--r--doc/rfc/rfc7484.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc7484.txt b/doc/rfc/rfc7484.txt
new file mode 100644
index 0000000..99f0c95
--- /dev/null
+++ b/doc/rfc/rfc7484.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Blanchet
+Request for Comments: 7484 Viagenie
+Category: Standards Track March 2015
+ISSN: 2070-1721
+
+
+ Finding the Authoritative Registration Data (RDAP) Service
+
+Abstract
+
+ This document specifies a method to find which Registration Data
+ Access Protocol (RDAP) server is authoritative to answer queries for
+ a requested scope, such as domain names, IP addresses, or Autonomous
+ System numbers.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ 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
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7484.
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 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.
+
+
+
+
+
+
+
+
+Blanchet Standards Track [Page 1]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
+ 3. Structure of the RDAP Bootstrap Service Registries . . . . . 3
+ 4. Bootstrap Service Registry for Domain Name Space . . . . . . 5
+ 5. Bootstrap Service Registries for Internet Numbers . . . . . . 6
+ 5.1. Bootstrap Service Registry for IPv4 Address Space . . . . 7
+ 5.2. Bootstrap Service Registry for IPv6 Address Space . . . . 8
+ 5.3. Bootstrap Service Registry for AS Number Space . . . . . 9
+ 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 7. Non-existent Entries or RDAP URL Values . . . . . . . . . . . 10
+ 8. Deployment and Implementation Considerations . . . . . . . . 10
+ 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 10. Formal Definition . . . . . . . . . . . . . . . . . . . . . . 11
+ 10.1. Imported JSON Terms . . . . . . . . . . . . . . . . . . 11
+ 10.2. Registry Syntax . . . . . . . . . . . . . . . . . . . . 12
+ 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
+ 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
+ 12.1. Bootstrap Service Registry for IPv4 Address Space . . . 14
+ 12.2. Bootstrap Service Registry for IPv6 Address Space . . . 14
+ 12.3. Bootstrap Service Registry for AS Number Space . . . . . 14
+ 12.4. Bootstrap Service Registry for Domain Name Space . . . . 15
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 13.1. Normative References . . . . . . . . . . . . . . . . . . 15
+ 13.2. Informative References . . . . . . . . . . . . . . . . . 15
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
+
+1. Introduction
+
+ Querying and retrieving registration data from registries are defined
+ in Registration Data Access Protocol (RDAP) [RFC7480] [RFC7482]
+ [RFC7483]. These documents do not specify where to send the queries.
+ This document specifies a method to find which server is
+ authoritative to answer queries for the requested scope.
+
+ Top-Level Domains (TLDs), Autonomous System (AS) numbers, and network
+ blocks are delegated by IANA to Internet registries such as TLD
+ registries and Regional Internet Registries (RIRs) that then issue
+ further delegations and maintain information about them. Thus, the
+ bootstrap information needed by RDAP clients is best generated from
+ data and processes already maintained by IANA; the relevant
+ registries already exist at [ipv4reg], [ipv6reg], [asreg], and
+ [domainreg].
+
+
+
+
+
+
+Blanchet Standards Track [Page 2]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+ Per this document, IANA has created new registries based on a JSON
+ format specified in this document, herein named RDAP Bootstrap
+ Service Registries. These new registries are based on the existing
+ entries of the above mentioned registries. An RDAP client fetches
+ the RDAP Bootstrap Service Registries, extracts the data, and then
+ performs a match with the query data to find the authoritative
+ registration data server and appropriate query base URL.
+
+2. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. Structure of the RDAP Bootstrap Service Registries
+
+ The RDAP Bootstrap Service Registries, as specified in Section 12
+ below, have been made available as JSON [RFC7159] objects, which can
+ be retrieved via HTTP from locations specified by IANA. The JSON
+ object for each registry contains a series of members containing
+ metadata about the registry such as a version identifier, a timestamp
+ of the publication date of the registry, and a description.
+ Additionally, a "services" member contains the registry items
+ themselves, as an array. Each item of the array contains a second-
+ level array, with two elements, each of them being a third-level
+ array.
+
+ Each element of the Services Array is a second-level array with two
+ elements: in order, an Entry Array and a Service URL Array.
+
+ The Entry Array contains all entries that have the same set of base
+ RDAP URLs. The Service URL Array contains the list of base RDAP URLs
+ usable for the entries found in the Entry Array. Elements within
+ these two arrays are not sorted in any way.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet Standards Track [Page 3]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+ An example structure of the JSON output of a RDAP Bootstrap Service
+ Registry is illustrated:
+
+ {
+ "version": "1.0",
+ "publication": "YYYY-MM-DDTHH:MM:SSZ",
+ "description": "Some text",
+ "services": [
+ [
+ ["entry1", "entry2", "entry3"],
+ [
+ "https://registry.example.com/myrdap/",
+ "http://registry.example.com/myrdap/"
+ ]
+ ],
+ [
+ ["entry4"],
+ [
+ "http://example.org/"
+ ]
+ ]
+ ]
+ }
+
+ The formal syntax is described in Section 10.
+
+ The "version" corresponds to the format version of the registry.
+ This specification defines version "1.0".
+
+ The syntax of the "publication" value conforms to the Internet date/
+ time format [RFC3339]. The value is the latest update date of the
+ registry by IANA.
+
+ The optional "description" string can contain a comment regarding the
+ content of the bootstrap object.
+
+ Per [RFC7258], in each array of base RDAP URLs, the secure versions
+ of the transport protocol SHOULD be preferred and tried first. For
+ example, if the base RDAP URLs array contains both HTTPS and HTTP
+ URLs, the bootstrap client SHOULD try the HTTPS version first.
+
+ Base RDAP URLs MUST have a trailing "/" character because they are
+ concatenated to the various segments defined in [RFC7482].
+
+ JSON names MUST follow the format recommendations of [RFC7480]. Any
+ unrecognized JSON object properties or values MUST be ignored by
+ implementations.
+
+
+
+
+Blanchet Standards Track [Page 4]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+ Internationalized Domain Name labels used as entries or base RDAP
+ URLs in the registries defined in this document MUST be only
+ represented using their A-label form as defined in [RFC5890].
+
+ All Domain Name labels used as entries or base RDAP URLs in the
+ registries defined in this document MUST be only represented in
+ lowercase.
+
+4. Bootstrap Service Registry for Domain Name Space
+
+ The JSON output of this registry contains domain label entries
+ attached to the root, grouped by base RDAP URLs, as shown in this
+ example.
+
+ {
+ "version": "1.0",
+ "publication": "YYYY-MM-DDTHH:MM:SSZ",
+ "description": "Some text",
+ "services": [
+ [
+ ["net", "com"],
+ [
+ "https://registry.example.com/myrdap/"
+ ]
+ ],
+ [
+ ["org", "mytld"],
+ [
+ "http://example.org/"
+ ]
+ ],
+ [
+ ["xn--zckzah"],
+ [
+ "https://example.net/rdapxn--zckzah/",
+ "http://example.net/rdapxn--zckzah/"
+ ]
+ ]
+ ]
+ }
+
+ The domain name's authoritative registration data service is found by
+ doing the label-wise longest match of the target domain name with the
+ domain values in the Entry Arrays in the IANA Bootstrap Service
+ Registry for Domain Name Space. The match is done per label, from
+ right to left. If the longest match results in multiple entries,
+ then those entries are considered equivalent. The values contained
+
+
+
+
+Blanchet Standards Track [Page 5]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+ in the Service URL Array of the matching second-level array are the
+ valid base RDAP URLs as described in [RFC7482].
+
+ For example, a domain RDAP query for a.b.example.com matches the com
+ entry in one of the arrays of the registry. The base RDAP URL for
+ this query is then taken from the second element of the array, which
+ is an array of base RDAP URLs valid for this entry. The client
+ chooses one of the base URLs from this array; in this example, it
+ chooses the only one available, "https://registry.example.com/
+ myrdap/". The segment specified in [RFC7482] is then appended to the
+ base URL to complete the query. The complete query is then
+ "https://registry.example.com/myrdap/domain/a.b.example.com".
+
+ If a domain RDAP query for a.b.example.com matches both com and
+ example.com entries in the registry, then the longest match applies
+ and the example.com entry is used by the client.
+
+ If the registry contains entries such as com and goodexample.com,
+ then a domain RDAP query for example.com only matches the com entry
+ because matching is done on a per-label basis.
+
+ The entry for the root of the domain name space is specified as "".
+
+5. Bootstrap Service Registries for Internet Numbers
+
+ This section discusses IPv4 and IPv6 address space and Autonomous
+ System numbers.
+
+ For IP address space, the authoritative registration data service is
+ found by doing a longest match of the target address with the values
+ of the arrays in the corresponding RDAP Bootstrap Service Registry
+ for Address Space. The longest match is done the same way as for
+ routing: the addresses are converted in binary form and then the
+ binary strings are compared to find the longest match up to the
+ specified prefix length. The values contained in the second element
+ of the array are the base RDAP URLs as described in [RFC7482]. The
+ longest match method enables covering prefixes of a larger address
+ space pointing to one base RDAP URL while more specific prefixes
+ within the covering prefix are being served by another base RDAP URL.
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet Standards Track [Page 6]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+5.1. Bootstrap Service Registry for IPv4 Address Space
+
+ The JSON output of this registry contains IPv4 prefix entries,
+ specified in Classless Inter-domain Routing (CIDR) format [RFC4632]
+ and grouped by RDAP URLs, as shown in this example.
+
+ {
+ "version": "1.0",
+ "publication": "2024-01-07T10:11:12Z",
+ "description": "RDAP Bootstrap file for example registries.",
+ "services": [
+ [
+ ["1.0.0.0/8", "192.0.0.0/8"],
+ [
+ "https://rir1.example.com/myrdap/"
+ ]
+ ],
+ [
+ ["28.2.0.0/16", "192.0.2.0/24"],
+ [
+ "http://example.org/"
+ ]
+ ],
+ [
+ ["28.3.0.0/16"],
+ [
+ "https://example.net/rdaprir2/",
+ "http://example.net/rdaprir2/"
+ ]
+ ]
+ ]
+ }
+
+ For example, a query for "192.0.2.1/25" matches the "192.0.0.0/8"
+ entry and the "192.0.2.0/24" entry in the example registry above.
+ The latter is chosen by the client given the longest match. The base
+ RDAP URL for this query is then taken from the second element of the
+ array, which is an array of base RDAP URLs valid for this entry. The
+ client chooses one of the base URLs from this array; in this example,
+ it chooses the only one available, "http://example.org/". The
+ {resource} specified in [RFC7482] is then appended to the base URL to
+ complete the query. The complete query is then "https://example.org/
+ ip/192.0.2.1/25".
+
+
+
+
+
+
+
+
+Blanchet Standards Track [Page 7]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+5.2. Bootstrap Service Registry for IPv6 Address Space
+
+ The JSON output of this registry contains IPv6 prefix entries, using
+ [RFC4291] text representation of the address prefixes format, grouped
+ by base RDAP URLs, as shown in this example.
+
+ {
+ "version": "1.0",
+ "publication": "2024-01-07T10:11:12Z",
+ "description": "RDAP Bootstrap file for example registries.",
+ "services": [
+ [
+ ["2001:0200::/23", "2001:db8::/32"],
+ [
+ "https://rir2.example.com/myrdap/"
+ ]
+ ],
+ [
+ ["2600::/16", "2100:ffff::/32"],
+ [
+ "http://example.org/"
+ ]
+ ],
+ [
+ ["2001:0200:1000::/36"],
+ [
+ "https://example.net/rdaprir2/",
+ "http://example.net/rdaprir2/"
+ ]
+ ]
+ ]
+ }
+
+ For example, a query for "2001:0200:1000::/48" matches the
+ "2001:0200::/23" entry and the "2001:0200:1000::/36" entry in the
+ example registry above. The latter is chosen by the client given the
+ longest match. The base RDAP URL for this query is then taken from
+ the second element of the array, which is an array of base RDAP URLs
+ valid for this entry. The client chooses one of the base URLs from
+ this array; in this example, it chooses "https://example.net/
+ rdaprir2/" because it's the secure version of the protocol. The
+ segment specified in [RFC7482] is then appended to the base URL to
+ complete the query. The complete query is, therefore,
+ "https://example.net/rdaprir2/ip/2001:0200:1000::/48". If the target
+ RDAP server does not answer, the client can then use another URL
+ prefix from the array.
+
+
+
+
+
+Blanchet Standards Track [Page 8]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+5.3. Bootstrap Service Registry for AS Number Space
+
+ The JSON output of this contains Autonomous Systems number ranges
+ entries, grouped by base RDAP URLs, as shown in this example. The
+ Entry Array is an array containing the list of AS number ranges
+ served by the base RDAP URLs found in the second element. The array
+ always contains two AS numbers represented in decimal format that
+ represents the range of AS numbers between the two elements of the
+ array. A single AS number is represented as a range of two identical
+ AS numbers.
+
+ {
+ "version": "1.0",
+ "publication": "2024-01-07T10:11:12Z",
+ "description": "RDAP Bootstrap file for example registries.",
+ "services": [
+ [
+ ["2045-2045"],
+ [
+ "https://rir3.example.com/myrdap/"
+ ]
+ ],
+ [
+ ["10000-12000", "300000-400000"],
+ [
+ "http://example.org/"
+ ]
+ ],
+ [
+ ["64512-65534"],
+ [
+ "http://example.net/rdaprir2/",
+ "https://example.net/rdaprir2/"
+ ]
+ ]
+ ]
+ }
+
+ For example, a query for AS 65411 matches the 64512-65534 entry in
+ the example registry above. The base RDAP URL for this query is then
+ taken from the second element of the array, which is an array of base
+ RDAP URLs valid for this entry. The client chooses one of the base
+ URLs from this array; in this example, it chooses
+ "https://example.net/rdaprir2/". The segment specified in [RFC7482]
+ is then appended to the base URL to complete the query. The complete
+ query is, therefore, "https://example.net/rdaprir2/autnum/65411". If
+ the server does not answer, the client can then use another URL
+ prefix from the array.
+
+
+
+Blanchet Standards Track [Page 9]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+6. Entity
+
+ Entities (such as contacts, registrants, or registrars) can be
+ queried by handle as described in [RFC7482]. Since there is no
+ global namespace for entities, this document does not describe how to
+ find the authoritative RDAP server for entities. However, it is
+ possible that, if the entity identifier was received from a previous
+ query, the same RDAP server could be queried for that entity, or the
+ entity identifier itself is a fully referenced URL that can be
+ queried.
+
+7. Non-existent Entries or RDAP URL Values
+
+ The registries may not contain the requested value. In these cases,
+ there is no known RDAP server for that requested value, and the
+ client SHOULD provide an appropriate error message to the user.
+
+8. Deployment and Implementation Considerations
+
+ This method relies on the fact that RDAP clients are fetching the
+ IANA registries to then find the servers locally. Clients SHOULD NOT
+ fetch the registry on every RDAP request. Clients SHOULD cache the
+ registry, but use underlying protocol signaling, such as the HTTP
+ Expires header field [RFC7234], to identify when it is time to
+ refresh the cached registry.
+
+ If the query data does not match any entry in the client cached
+ registry, then the client may implement various methods, such as the
+ following:
+
+ o In the case of a domain object, the client may first query the DNS
+ to see if the respective entry has been delegated or if it is
+ mistyped information by the user. The DNS query could be to fetch
+ the NS records for the TLD domain. If the DNS answer is negative,
+ then there is no need to fetch the new version of the registry.
+ However, if the DNS answer is positive, this may mean that the
+ currently cached registry is no longer current. The client could
+ then fetch the registry, parse, and then do the normal matching as
+ specified above. This method may not work for all types of RDAP
+ objects.
+
+ o If the client knows the existence of an RDAP aggregator or
+ redirector and its associated base URL, and trusts that service,
+ then it could send the query to the redirector, which would
+ redirect the client if it knows the authoritative server that
+ client has not found.
+
+
+
+
+
+Blanchet Standards Track [Page 10]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+ Some authorities of registration data may work together on sharing
+ their information for a common service, including mutual redirection
+ [REDIRECT-RDAP].
+
+ When a new object is allocated, such as a new AS range, a new TLD, or
+ a new IP address range, there is no guarantee that this new object
+ will have an entry in the corresponding bootstrap RDAP registry,
+ since the setup of the RDAP server for this new entry may become live
+ and registered later. Therefore, the clients should expect that even
+ if an object, such as TLD, IP address range, or AS range is
+ allocated, the existence of the entry in the corresponding bootstrap
+ registry is not guaranteed.
+
+9. Limitations
+
+ This method does not provide a direct way to find authoritative RDAP
+ servers for any other objects than the ones described in this
+ document. In particular, the following objects are not bootstrapped
+ with the method described in this document:
+
+ o entities
+
+ o queries using search patterns that do not contain a terminating
+ string that matches some entries in the registries
+
+ o nameservers
+
+ o help
+
+10. Formal Definition
+
+ This section is the formal definition of the registries. The
+ structure of JSON objects and arrays using a set of primitive
+ elements is defined in [RFC7159]. Those elements are used to
+ describe the JSON structure of the registries.
+
+10.1. Imported JSON Terms
+
+ o OBJECT: a JSON object, defined in Section 4 of [RFC7159]
+
+ o MEMBER: a member of a JSON object, defined in Section 4 of
+ [RFC7159]
+
+ o MEMBER-NAME: the name of a MEMBER, defined as a "string" in
+ Section 4 of [RFC7159]
+
+ o MEMBER-VALUE: the value of a MEMBER, defined as a "value" in
+ Section 4 of [RFC7159]
+
+
+
+Blanchet Standards Track [Page 11]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+ o ARRAY: an array, defined in Section 5 of [RFC7159]
+
+ o ARRAY-VALUE: an element of an ARRAY, defined in Section 5 of
+ [RFC7159]
+
+ o STRING: a "string", as defined in Section 7 of [RFC7159]
+
+10.2. Registry Syntax
+
+ Using the above terms for the JSON structures, the syntax of a
+ registry is defined as follows:
+
+ o rdap-bootstrap-registry: an OBJECT containing a MEMBER version and
+ a MEMBER publication, an optional MEMBER description, and a MEMBER
+ services-list
+
+ o version: a MEMBER with MEMBER-NAME "version" and MEMBER-VALUE a
+ STRING
+
+ o publication: a MEMBER with MEMBER-NAME "publication" and MEMBER-
+ VALUE a STRING
+
+ o description: a MEMBER with MEMBER-NAME "description" and MEMBER-
+ VALUE a STRING
+
+ o services-list: a MEMBER with MEMBER-NAME "services" and MEMBER-
+ VALUE a services-array
+
+ o services-array: an ARRAY, where each ARRAY-VALUE is a service
+
+ o service: an ARRAY of 2 elements, where the first ARRAY-VALUE is a
+ an entry-list and the second ARRAY-VALUE is a service-uri-list
+
+ o entry-list: an ARRAY, where each ARRAY-VALUE is an entry
+
+ o entry: a STRING
+
+ o service-uri-list: an ARRAY, where each ARRAY-VALUE is a service-
+ uri
+
+ o service-uri: a STRING
+
+
+
+
+
+
+
+
+
+
+Blanchet Standards Track [Page 12]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+11. Security Considerations
+
+ By providing a bootstrap method to find RDAP servers, this document
+ helps to ensure that the end users will get the RDAP data from an
+ authoritative source, instead of from rogue sources. The method has
+ the same security properties as the RDAP protocols themselves. The
+ transport used to access the registries can be more secure by using
+ TLS [RFC5246], which IANA supports.
+
+ Additional considerations on using RDAP are described in [RFC7481].
+
+12. IANA Considerations
+
+ IANA has created the RDAP Bootstrap Services Registries, listed
+ below, and made them available as JSON objects. The contents of
+ these registries are described in Section 3, Section 4, and
+ Section 5, with the formal syntax specified in Section 10.
+
+ The process for adding or updating entries in these registries
+ differs from the normal IANA registry processes: these registries are
+ generated from the data, processes, and policies maintained by IANA
+ in their allocation registries ([ipv4reg], [ipv6reg], [asreg], and
+ [domainreg]), with the addition of new RDAP server information.
+
+ IANA will create and update RDAP Bootstrap Services Registries
+ entries from the allocation registries as those registries are
+ updated.
+
+ This document does not change any policies related to the allocation
+ registries; IANA has provided a mechanism for collecting the RDAP
+ server information. The RDAP Bootstrap Services Registries will
+ start empty and will be gradually populated as registrants of domains
+ and address spaces provide RDAP server information to IANA.
+
+ IANA has created a new top-level category on the Protocol Registries
+ page, <http://www.iana.org/protocols>. The group is called
+ "Registration Data Access Protocol (RDAP)". Each of the RDAP
+ Bootstrap Services Registries has been made available for general
+ public on-demand download in the JSON format, and that registry's URI
+ is listed directly on the Protocol Registries page.
+
+ Other normal registries will be added to this group by other
+ documents, but the reason the URIs for these registries are clearly
+ listed on the main page is to make those URIs obvious to implementers
+ -- these are registries that will be accessed by software, as well as
+ by humans using them for reference information.
+
+
+
+
+
+Blanchet Standards Track [Page 13]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+ Because these registries will be accessed by software, the download
+ demand for the RDAP Bootstrap Services Registries may be unusually
+ high compared to normal IANA registries. The technical
+ infrastructure by which registries are published will need to be
+ reviewed and might need to be augmented.
+
+ As discussed in Section 8, software that accesses these registries
+ will depend on the HTTP Expires header field to limit their query
+ rate. It is, therefore, important for that header field to be
+ properly set to provide timely information as the registries change,
+ while maintaining a reasonable load on the IANA servers. The HTTP
+ Content-Type returned to clients accessing these JSON- formatted
+ registries MUST be "application/json", as defined in [RFC7159].
+
+ Because of how information in the RDAP Bootstrap Services Registries
+ is grouped and formatted, the registry entries may not be sortable.
+ It is, therefore, not required or expected that the entries be sorted
+ in any way.
+
+12.1. Bootstrap Service Registry for IPv4 Address Space
+
+ Entries in this registry contain at least the following:
+
+ o a CIDR [RFC4632] specification of the network block being
+ registered.
+
+ o one or more URLs that provide the RDAP service regarding this
+ registration.
+
+12.2. Bootstrap Service Registry for IPv6 Address Space
+
+ Entries in this registry contain at least the following:
+
+ o an IPv6 prefix [RFC4291] specification of the network block being
+ registered.
+
+ o one or more URLs that provide the RDAP service regarding this
+ registration.
+
+12.3. Bootstrap Service Registry for AS Number Space
+
+ Entries in this registry contain at least the following:
+
+ o a range of Autonomous System numbers being registered.
+
+ o one or more URLs that provide the RDAP service regarding this
+ registration.
+
+
+
+
+Blanchet Standards Track [Page 14]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+12.4. Bootstrap Service Registry for Domain Name Space
+
+ Entries in this registry contain at least the following:
+
+ o a domain name attached to the root being registered.
+
+ o one or more URLs that provide the RDAP service regarding this
+ registration.
+
+13. References
+
+13.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
+ Timestamps", RFC 3339, July 2002,
+ <http://www.rfc-editor.org/info/rfc3339>.
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006,
+ <http://www.rfc-editor.org/info/rfc4291>.
+
+ [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
+ (CIDR): The Internet Address Assignment and Aggregation
+ Plan", BCP 122, RFC 4632, August 2006,
+ <http://www.rfc-editor.org/info/rfc4632>.
+
+ [RFC5890] Klensin, J., "Internationalized Domain Names for
+ Applications (IDNA): Definitions and Document Framework",
+ RFC 5890, August 2010,
+ <http://www.rfc-editor.org/info/rfc5890>.
+
+ [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+ Interchange Format", RFC 7159, March 2014,
+ <http://www.rfc-editor.org/info/rfc7159>.
+
+13.2. Informative References
+
+ [REDIRECT-RDAP]
+ Martinez, C., Zhou, L., and G. Rada, "Redirection Service
+ for Registration Data Access Protocol", Work in Progress,
+ draft-ietf-weirds-redirects-04, July 2014.
+
+
+
+
+
+
+Blanchet Standards Track [Page 15]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008,
+ <http://www.rfc-editor.org/info/rfc5246>.
+
+ [RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for
+ Reputation Interchange", RFC 7071, November 2013,
+ <http://www.rfc-editor.org/info/rfc7071>.
+
+ [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+ Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
+ RFC 7234, June 2014,
+ <http://www.rfc-editor.org/info/rfc7234>.
+
+ [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
+ Attack", BCP 188, RFC 7258, May 2014,
+ <http://www.rfc-editor.org/info/rfc7258>.
+
+ [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
+ Registration Data Access Protocol (RDAP)", RFC 7480, March
+ 2015, <http://www.rfc-editor.org/info/rfc7480>.
+
+ [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
+ Registration Data Access Protocol", RFC 7481, March 2015,
+ <http://www.rfc-editor.org/info/rfc7481>.
+
+ [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
+ Protocol Query Format", RFC 7482, March 2015,
+ <http://www.rfc-editor.org/info/rfc7482>.
+
+ [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the
+ Registration Data Access Protocol (RDAP)", RFC 7483, March
+ 2015, <http://www.rfc-editor.org/info/rfc7483>.
+
+ [asreg] IANA, "Autonomous System (AS) Numbers",
+ <http://www.iana.org/assignments/as-numbers>.
+
+ [domainreg]
+ IANA, "Root Zone Database",
+ <http://www.iana.org/domains/root/db>.
+
+ [ipv4reg] IANA, "IPv4 Address Space Registry",
+ <http://www.iana.org/assignments/ipv4-address-space>.
+
+ [ipv6reg] IANA, "IPv6 Global Unicast Address Assignments",
+ <http://www.iana.org/assignments/
+ ipv6-unicast-address-assignments>.
+
+
+
+
+
+Blanchet Standards Track [Page 16]
+
+RFC 7484 Finding Authoritative RDAP Service March 2015
+
+
+Acknowledgements
+
+ The WEIRDS working group had multiple discussions on this topic,
+ including a session during IETF 84, where various methods such as
+ in-DNS and others were debated. The idea of using IANA registries
+ was discovered by the author during discussions with his colleagues
+ as well as by a comment from Andy Newton. All the people involved in
+ these discussions are herein acknowledged. Linlin Zhou, Jean-
+ Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott
+ Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy, Tom
+ Harrison, Naoki Kambe, Alexander Mayrhofer, Edward Lewis, Pete
+ Resnick, Alessandro Vesely, Bert Greevenbosch, Barry Leiba, Jari
+ Arkko, Kathleen Moriaty, Stephen Farrell, Richard Barnes, and Jean-
+ Francois Tremblay have provided input and suggestions to this
+ document. Guillaume Leclanche was a coauthor of this document for
+ some revisions; his support is therein acknowledged and greatly
+ appreciated. The section on formal definition was inspired by
+ Section 6.2 of [RFC7071].
+
+Author's Address
+
+ Marc Blanchet
+ Viagenie
+ 246 Aberdeen
+ Quebec, QC G1R 2E1
+ Canada
+
+ EMail: Marc.Blanchet@viagenie.ca
+ URI: http://viagenie.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet Standards Track [Page 17]
+