rfc9224xml2.original.xml   rfc9224.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<rfc category="std" ipr="trust200902" docName="draft-ietf-regext-rfc7484bis-06" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
obsoletes="7484"> -ietf-regext-rfc7484bis-06" number="9224" obsoletes="7484" updates="" submission
Type="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" symR
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> efs="true" sortRefs="true" version="3">
<?rfc rfcedstyle="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<front> <front>
<title abbrev="Finding Authoritative RDAP Service">Finding the Authoritative Reg <title abbrev="Finding Authoritative RDAP Service">Finding the Authoritative
istration Data (RDAP) Service</title> Registration Data Access Protocol (RDAP) Service</title>
<author initials="M." surname="Blanchet" fullname="Marc Blanchet"> <seriesInfo name="RFC" value="9224"/>
<organization>Viagenie</organization> <seriesInfo name="STD" value="95"/>
<address> <author initials="M." surname="Blanchet" fullname="Marc Blanchet">
<postal> <organization>Viagenie</organization>
<street>246 Aberdeen</street> <address>
<city>Quebec</city> <postal>
<region>QC</region> <street>246 Aberdeen</street>
<code>G1R 2E1</code> <city>Quebec</city>
<country>Canada</country> <region>QC</region>
</postal> <code>G1R 2E1</code>
<email>Marc.Blanchet@viagenie.ca</email> <country>Canada</country>
<uri>https://viagenie.ca</uri> </postal>
</address> <email>Marc.Blanchet@viagenie.ca</email>
</author> <uri>https://viagenie.ca</uri>
</address>
</author>
<date year="2022" month="March" />
<area>art</area>
<workgroup>regext</workgroup>
<keyword>whois</keyword>
<keyword>bootstrap</keyword>
<keyword>domain</keyword>
<keyword>IDN</keyword>
<keyword>DNS</keyword>
<keyword>AS</keyword>
<keyword>IPv4</keyword>
<keyword>IPv6</keyword>
<keyword>JSON</keyword>
<abstract>
<t>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. This documen
t obsoletes RFC 7484.</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>Querying and retrieving registration data from registries are defined
in the Registration Data Access Protocol (RDAP) <xref target="RFC7480"
format="default"/> <xref target="RFC7481" format="default"/> <xref
target="RFC9082" format="default"/> <xref target="RFC9083"
format="default"/>. 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.</t>
<t>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 <xref target="ipv4reg" format="default"/>, <xref
target="ipv6reg" format="default"/>, <xref target="asreg"
format="default"/>, and <xref target="domainreg"
format="default"/>. This document obsoletes <xref target="RFC7484"
format="default"/>.
</t>
<t>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.
</t>
</section>
<section numbered="true" toc="default">
<name>Conventions Used in This Document</name>
<date/> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
<keyword>whois</keyword> </section>
<keyword>bootstrap</keyword> <section anchor="struct" numbered="true" toc="default">
<keyword>domain</keyword> <name>Structure of the RDAP Bootstrap Service Registries</name>
<keyword>IDN</keyword> <t>The RDAP Bootstrap Service Registries, as specified in <xref target="ia
<keyword>DNS</keyword> naconsiderations" format="default"/> below, have been made available as JSON <xr
<keyword>AS</keyword> ef target="RFC8259" format="default"/> objects, which can be retrieved via HTTP
<keyword>IPv4</keyword> from locations specified by IANA. The JSON object for each registry contains a s
<keyword>IPv6</keyword> eries of members containing metadata about the registry such as a version identi
<keyword>JSON</keyword> fier, a timestamp of the publication date of the registry, and a description. Ad
ditionally, a "services" member contains the registry items themselves, as an ar
ray. Each item of the array contains a second-level array, with two elements, ea
ch of them being a third-level array.
</t>
<abstract> <t>Each element of the Services Array is a second-level array with two ele
<t>This document specifies a method to find which Registration Data Access Proto ments: in order, an Entry Array and a Service URL Array.</t>
col (RDAP) server is authoritative to answer queries for a requested scope, such <t>The Entry Array contains all entries that have the same set of base RDA
as domain names, IP addresses, or Autonomous System numbers. This document obso P URLs. The Service URL Array contains the list of base RDAP URLs usable for th
letes RFC7484.</t> e entries found in the Entry Array. Elements within these two arrays are not ord
</abstract> ered in any way.</t>
</front> <t>An example structure of the JSON output of an RDAP Bootstrap Service Re
<middle> gistry is illustrated:
<section title="Introduction">
<t>Querying and retrieving registration data from registries are defined in Regi
stration Data Access Protocol (RDAP) <xref target="RFC7480"/> <xref target="RFC7
481"/> <xref target="RFC9082"/> <xref target="RFC9083"/>. These documents do not
specify where to send the queries. This document specifies a method to find whi
ch server is authoritative to answer queries for the requested scope.</t>
<t>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 <xref target="ipv4reg"/>, <xref t
arget="ipv6reg"/>, <xref target="asreg"/>, and <xref target="domainreg"/>. This
document obsoletes <xref target="RFC7484"/>.
</t>
<t>Per this document, IANA has created new registries based on a JSON format spe
cified in this document, herein named RDAP Bootstrap Service Registries. These n
ew registries are based on the existing entries of the above-mentioned registrie
s. An RDAP client fetches the RDAP Bootstrap Service Registries, extracts the da
ta, and then performs a match with the query data to find the authoritative regi
stration data server and appropriate query base URL.
</t>
</section>
<section title="Conventions Used in This Document">
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when,
and only when, they
appear in all capitals, as shown here.
</t>
</section>
<section anchor="struct" title="Structure of the RDAP Bootstrap Service Regist
ries">
<t>The RDAP Bootstrap Service Registries, as specified in <xref
target="ianaconsiderations"/> below, have been made available as JSON <xref
target="RFC8259"/> objects, which can be retrieved via HTTP from locations speci
fied by IANA. The JSON object for each registry contains a series of members con
taining metadata about the registry such as a version identifier, a timestamp of
the publication date of the registry, and a description. Additionally, a "servi
ces" member contains the registry items themselves, as an array. Each item of th
e array contains a second-level array, with two elements, each of them being a t
hird-level array.
</t> </t>
<t>Each element of the Services Array is a second-level array with two elements: <sourcecode type="json"><![CDATA[
in order, an Entry Array and a Service URL Array.</t>
<t>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 entr
ies found in the Entry Array. Elements within these two arrays are not ordered i
n any way.</t>
<t>An example structure of the JSON output of a RDAP Bootstrap Service Registry
is illustrated:
<figure>
<artwork>
{ {
"version": "1.0", "version": "1.0",
"publication": "YYYY-MM-DDTHH:MM:SSZ", "publication": "YYYY-MM-DDTHH:MM:SSZ",
"description": "Some text", "description": "Some text",
"services": [ "services": [
[ [
["entry1", "entry2", "entry3"], ["entry1", "entry2", "entry3"],
[ [
"https://registry.example.com/myrdap/", "https://registry.example.com/myrdap/",
"http://registry.example.com/myrdap/" "http://registry.example.com/myrdap/"
] ]
], ],
[ [
["entry4"], ["entry4"],
[ [
"https://example.org/" "https://example.org/"
] ]
] ]
] ]
} }
</artwork> ]]></sourcecode>
</figure> <t>The formal syntax is described in <xref target="abnf" format="default"/
>.</t>
<t>The "version" corresponds to the format version of the registry. This s
pecification defines version "1.0".</t>
<t>The syntax of the "publication" value conforms to the Internet date/tim
e format <xref target="RFC3339" format="default"/>. The value is the latest upda
te date of the registry by IANA.</t>
<t>The optional "description" string can contain a comment regarding the c
ontent of the bootstrap object. </t>
<t>Per <xref target="RFC7258" format="default"/>, in each array of base RD
AP URLs, the secure versions of the transport protocol <bcp14>SHOULD</bcp14> be
preferred and tried first. For example, if the base RDAP URLs array contains bot
h HTTPS and HTTP URLs, the bootstrap client <bcp14>SHOULD</bcp14> try the HTTPS
version first.</t>
<t>Base RDAP URLs <bcp14>MUST</bcp14> have a trailing "/" character
because they are concatenated to the various segments defined in <xref
target="RFC9082" format="default"/>.</t>
<t>JSON names <bcp14>MUST</bcp14> follow the format recommendations of
<xref target="RFC7480" sectionFormat="of" section="6"
format="default"/>. Any unrecognized JSON object properties or values
<bcp14>MUST</bcp14> be ignored by implementations.</t>
<t>Internationalized Domain Name labels used as entries or base RDAP URLs
in the registries defined in this document <bcp14>MUST</bcp14> be only represent
ed using their A-label form as defined in <xref target="RFC5890" format="default
"/>.</t>
<t>All Domain Name labels used as entries or base RDAP URLs in the registr
ies defined in this document <bcp14>MUST</bcp14> be only represented in lowercas
e.</t>
</section>
<section anchor="domainrdapreg" numbered="true" toc="default">
<name>Bootstrap Service Registry for Domain Name Space</name>
<t>The JSON output of this registry contains domain label entries attached
to the root, grouped by base RDAP URLs, as shown in this example.
</t> </t>
<t>The formal syntax is described in <xref target="abnf"/>.</t> <sourcecode type="json"><![CDATA[
<t>The "version" corresponds to the format version of the registry. This specifi
cation defines version "1.0".</t>
<t>The syntax of the "publication" value conforms to the Internet date/time form
at <xref target="RFC3339"/>. The value is the latest update date of the registry
by IANA.</t>
<t>The optional "description" string can contain a comment regarding the content
of the bootstrap object. </t>
<t>Per <xref target="RFC7258"/>, in each array of base RDAP URLs, the secure ver
sions 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 c
lient SHOULD try the HTTPS version first.</t>
<t>Base RDAP URLs MUST have a trailing "/" character because they are concatenat
ed to the various segments defined in <xref target="RFC9082"/>.</t>
<t>JSON names MUST follow the format recommendations of section 6 of <xref targe
t="RFC7480"/>. Any unrecognized JSON object properties or values MUST be
ignored by implementations.</t>
<t>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-labe
l form as defined in <xref target="RFC5890"/>.</t>
<t>All Domain Name labels used as entries or base RDAP URLs in the registries de
fined in this document MUST be only represented in lowercase.</t>
</section>
<section anchor="domainrdapreg"
title="Bootstrap Service Registry for Domain Name Space">
<t>The JSON output of this registry contains domain label entries attached t
o the root, grouped by base RDAP URLs, as shown in this example.
<figure>
<artwork>
{ {
"version": "1.0", "version": "1.0",
"publication": "2024-01-07T10:11:12Z", "publication": "2024-01-07T10:11:12Z",
"description": "Some text", "description": "Some text",
"services": [ "services": [
[ [
["net", "com"], ["net", "com"],
[ [
"https://registry.example.com/myrdap/" "https://registry.example.com/myrdap/"
] ]
skipping to change at line 147 skipping to change at line 169
], ],
[ [
["xn--zckzah"], ["xn--zckzah"],
[ [
"https://example.net/rdap/xn--zckzah/", "https://example.net/rdap/xn--zckzah/",
"http://example.net/rdap/xn--zckzah/" "http://example.net/rdap/xn--zckzah/"
] ]
] ]
] ]
} }
</artwork> ]]></sourcecode>
</figure> <t>The domain name's authoritative registration data service is found by
</t>
<t>The domain name's authoritative registration data service is found by
doing the label-wise longest match of the target domain name with the 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 values in the Entry Arrays in the IANA "Bootstrap Service Registry fo
Domain Name Space. The match is done per label, from right to left. If the l r
ongest match results in multiple entries, then those entries are considered equi Domain Name Space". The match is done per label, from right to left. If the
valent. The values contained in the Service URL Array of the matching second-lev longest match results in multiple entries, then those entries are considered equ
el array are the valid base RDAP URLs as described in <xref target="RFC9082"/>.< ivalent. The values contained in the Service URL Array of the matching second-le
/t> vel array are the valid base RDAP URLs as described in <xref target="RFC9082" fo
<t>For example, a domain RDAP query for a.b.example.com matches the com entr rmat="default"/>.</t>
y in one of the arrays of the registry. The base RDAP URL for this query is then <t>For example, a domain RDAP query for a.b.example.com matches the com en
taken from the second element of the array, which is an array of base RDAP URLs try in one of the arrays of the registry. The base RDAP URL for this query is th
valid for this entry. The client chooses one of the base URLs from this array; en taken from the second element of the array, which is an array of base RDAP UR
in this example, it chooses the only one available, "https://registry.example.co Ls valid for this entry. The client chooses one of the base URLs from this array
m/myrdap/". The segment specified in <xref target="RFC9082"/> is then appended t ; in this example, it chooses the only one available, "https://registry.example.
o the base URL to complete the query. The complete query is then "https://regist com/myrdap/". The segment specified in <xref target="RFC9082" format="default"/>
ry.example.com/myrdap/domain/a.b.example.com". </t> is then appended to the base URL to complete the query. The complete query is t
<t>If a domain RDAP query for a.b.example.com matches both com and example.com hen "https://registry.example.com/myrdap/domain/a.b.example.com". </t>
entries in the registry, then the longest match applies and the example.com entr <t>If a domain RDAP query for a.b.example.com matches both com and example
y is used by the client.</t> .com entries in the registry, then the longest match applies and the example.com
<t>If the registry contains entries such as com and goodexample.com, then a dom entry is used by the client.</t>
ain RDAP query for example.com only matches the com entry because matching is do <t>If the registry contains entries such as com and goodexample.com, then
ne on a per-label basis.</t> a domain RDAP query for example.com only matches the com entry because matching
is done on a per-label basis.</t>
<t>The entry for the root of the domain name space is specified as "".</t>
</section>
<t>The entry for the root of the domain name space is specified as "".</t> <section anchor="iprdapreg" numbered="true" toc="default">
</section> <name>Bootstrap Service Registries for Internet Numbers</name>
<section anchor="iprdapreg" <t>This section discusses IPv4 and IPv6 address space and Autonomous Syste
title="Bootstrap Service Registries for Internet Numbers"> m numbers.</t>
<t>This section discusses IPv4 and IPv6 address space and Autonomous System <t>For IP address space, the authoritative registration data service is fo
numbers.</t> und
<t>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 by doing a longest match of the target address with the values of the arrays
in the corresponding RDAP Bootstrap Service Registry for Address in the corresponding RDAP Bootstrap Service Registry for Address
Space. The longest match is done the same way as in packet forwarding: the addre Space. The longest match is done the same way as in packet forwarding: the addre
sses are converted in binary form and then the binary strings are compared to fi sses are converted in binary form and then the binary strings are compared to fi
nd the longest match up to the specified prefix length. The values contained in nd 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 <xref tar the second element of the array are the base RDAP URLs as described in <xref tar
get="RFC9082"/>. The longest match method enables covering prefixes of a larger get="RFC9082" format="default"/>. The longest match method enables covering pref
address space pointing to one base RDAP URL while more specific prefixes within ixes of a larger address space pointing to one base RDAP URL while more specific
the covering prefix are being served by another base RDAP URL.</t> prefixes within the covering prefix are being served by another base RDAP URL.<
<section title="Bootstrap Service Registry for IPv4 Address Space"> /t>
<t>The JSON output of this registry contains IPv4 prefix entries, specified <section numbered="true" toc="default">
in Classless Inter-domain Routing (CIDR) format <xref target="RFC4632"/> and gro <name>Bootstrap Service Registry for IPv4 Address Space</name>
uped by RDAP URLs, as shown in this example. <t>The JSON output of this registry contains IPv4 prefix entries, specif
<figure> ied in Classless Inter-domain Routing (CIDR) format <xref target="RFC4632" forma
<artwork> t="default"/> and grouped by RDAP URLs, as shown in this example.
</t>
<sourcecode type="json"><![CDATA[
{ {
"version": "1.0", "version": "1.0",
"publication": "2024-01-07T10:11:12Z", "publication": "2024-01-07T10:11:12Z",
"description": "RDAP Bootstrap file for example registries.", "description": "RDAP Bootstrap file for example registries.",
"services": [ "services": [
[ [
["198.51.100.0/24", "192.0.0.0/8"], ["198.51.100.0/24", "192.0.0.0/8"],
[ [
"https://rir1.example.com/myrdap/" "https://rir1.example.com/myrdap/"
] ]
skipping to change at line 197 skipping to change at line 218
], ],
[ [
["203.0.113.0/28"], ["203.0.113.0/28"],
[ [
"https://example.net/rdaprir2/", "https://example.net/rdaprir2/",
"http://example.net/rdaprir2/" "http://example.net/rdaprir2/"
] ]
] ]
] ]
} }
</artwork> ]]></sourcecode>
</figure> <t>For example, a query for "192.0.2.1/25" matches the "192.0.0.0/8" ent
ry and the "192.0.2.0/24" entry in the example registry above. The latter is cho
sen by the client because it is the longest match. The base RDAP URL for this qu
ery is then taken from the second element of the array, which is an array of bas
e RDAP URLs valid for this entry. The client chooses one of the base URLs from t
his array; in this example, it chooses the only one available, "https://example.
org/". The {resource} specified in <xref target="RFC9082" format="default"/> 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".</t>
</section>
<section numbered="true" toc="default">
<name>Bootstrap Service Registry for IPv6 Address Space</name>
<t>The JSON output of this registry contains IPv6 prefix entries,
using <xref target="RFC5952" format="default"/> text representation of
the address prefixes format, grouped by base RDAP URLs, as shown in
this example.
</t> </t>
<t>For example, a query for "192.0.2.1/25" matches the "192.0.0.0/8" entry and t <sourcecode type="json"><![CDATA[
he "192.0.2.0/24" entry in the example registry above. The latter is chosen by t
he client because it is the longest match. The base RDAP URL for this query is t
hen taken from the second element of the array, which is an array of base RDAP U
RLs valid for this entry. The client chooses one of the base URLs from this arra
y; in this example, it chooses the only one available, "https://example.org/". T
he {resource} specified in <xref target="RFC9082"/> is then appended to the base
URL to complete the query. The complete query is then "https://example.org/ip/1
92.0.2.1/25".</t>
</section>
<section title="Bootstrap Service Registry for IPv6 Address Space">
<t>The JSON output of this registry contains IPv6 prefix entries, using <xre
f target="RFC5952"/> text representation of the address prefixes format, grouped
by base RDAP URLs, as shown in this example.
<figure>
<artwork>
{ {
"version": "1.0", "version": "1.0",
"publication": "2024-01-07T10:11:12Z", "publication": "2024-01-07T10:11:12Z",
"description": "RDAP Bootstrap file for example registries.", "description": "RDAP Bootstrap file for example registries.",
"services": [ "services": [
[ [
["2001:db8::/34"], ["2001:db8::/34"],
[ [
"https://rir2.example.com/myrdap/" "https://rir2.example.com/myrdap/"
] ]
skipping to change at line 232 skipping to change at line 255
], ],
[ [
["2001:db8:1000::/36"], ["2001:db8:1000::/36"],
[ [
"https://example.net/rdaprir2/", "https://example.net/rdaprir2/",
"http://example.net/rdaprir2/" "http://example.net/rdaprir2/"
] ]
] ]
] ]
} }
</artwork> ]]></sourcecode>
</figure> <t>For example, a query for "2001:db8:1000::/48" matches the
</t> "2001:db8::/34" entry and the "2001:db8:1000::/36" entry in the
<t>For example, a query for "2001:db8:1000::/48" matches the "2001:db8::/34" ent example registry above. The latter is chosen by the client because it
ry and the "2001:db8:1000::/36" entry in the example registry above. The latter is the longest match. The base RDAP URL for this query is then taken
is chosen by the client because it is the longest match. The base RDAP URL for t from the second element of the array, which is an array of base RDAP
his query is then taken from the second element of the array, which is an array URLs valid for this entry. The client chooses one of the base URLs
of base RDAP URLs valid for this entry. The client chooses one of the base URLs from this array; in this example, it chooses
from this array; in this example, it chooses "https://example.net/rdaprir2/" bec "https://example.net/rdaprir2/" because it's the secure version of the
ause it's the secure version of the protocol. The segment specified in <xref tar protocol. The segment specified in <xref target="RFC9082"
get="RFC9082"/> is then appended to the base URL to complete the query. The comp format="default"/> is then appended to the base URL to complete the
lete query is, therefore, "https://example.net/rdaprir2/ip/2001:db8:1000::/48". query. The complete query is therefore
If the target RDAP server does not answer, the client can then use another URL p "https://example.net/rdaprir2/ip/2001:db8:1000::/48". If the target
refix from the array.</t> RDAP server does not answer, the client can then use another URL
</section> prefix from the array.</t>
</section>
<section numbered="true" toc="default">
<name>Bootstrap Service Registry for AS Number Space</name>
<section title="Bootstrap Service Registry for AS Number Space"> <t>The JSON output of this registry contains entries for AS number
<t>The JSON output of this registry contains Autonomous Systems number range ranges, grouped by base RDAP URLs, as shown in this example. The Entry
s entries, grouped by base RDAP URLs, as shown in this example. The Entry Array Array is an array containing the list of AS number ranges served by
is an array containing the list of AS number ranges served by the base RDAP URLs the base RDAP URLs found in the second element. Each element of the
found in the second element. Each element of the array contains two AS numbers array contains two AS numbers represented in decimal format, separated
represented in decimal format, separated by a hyphen, that represents the range by a hyphen, that represents the range of AS numbers between the two
of AS numbers between the two AS numbers (inclusive), where values are in increa AS numbers (inclusive), where values are in increasing order (e.g.,
sing order (e.g. 100-200, not 200-100). A single AS number is represented as a r 100-200, not 200-100). A single AS number is represented as a range of
ange of two identical AS numbers. AS numbers are represented as 'asplain' as def two identical AS numbers. AS numbers are represented as 'asplain' as
ined in <xref target="RFC5396"/>. Ranges MUST NOT overlap. defined in <xref target="RFC5396" format="default"/>. Ranges
<figure> <bcp14>MUST NOT</bcp14> overlap.
<artwork> </t>
<sourcecode type="json"><![CDATA[
{ {
"version": "1.0", "version": "1.0",
"publication": "2024-01-07T10:11:12Z", "publication": "2024-01-07T10:11:12Z",
"description": "RDAP Bootstrap file for example registries.", "description": "RDAP Bootstrap file for example registries.",
"services": [ "services": [
[ [
["64496-64496"], ["64496-64496"],
[ [
"https://rir3.example.com/myrdap/" "https://rir3.example.com/myrdap/"
] ]
skipping to change at line 268 skipping to change at line 313
], ],
[ [
["64512-65534"], ["64512-65534"],
[ [
"http://example.net/rdaprir2/", "http://example.net/rdaprir2/",
"https://example.net/rdaprir2/" "https://example.net/rdaprir2/"
] ]
] ]
] ]
} }
</artwork> ]]></sourcecode>
</figure> <t>For example, a query for AS 65411 matches the 64512-65534 entry in th
</t> e example registry above. The base RDAP URL for this query is then taken from th
<t>For example, a query for AS 65411 matches the 64512-65534 entry in the ex e second element of the array, which is an array of base RDAP URLs valid for thi
ample registry above. The base RDAP URL for this query is then taken from the se s entry. The client chooses one of the base URLs from this array; in this exampl
cond element of the array, which is an array of base RDAP URLs valid for this en e, it chooses "https://example.net/rdaprir2/". The segment specified in <xref ta
try. The client chooses one of the base URLs from this array; in this example, i rget="RFC9082" format="default"/> is then appended to the base URL to complete t
t chooses "https://example.net/rdaprir2/". The segment specified in <xref target he query. The complete query is, therefore, "https://example.net/rdaprir2/autnum
="RFC9082"/> is then appended to the base URL to complete the query. The complet /65411". If the server does not answer, the client can then use another URL pref
e query is, therefore, "https://example.net/rdaprir2/autnum/65411". If the serve ix from the array.</t>
r does not answer, the client can then use another URL prefix from the array.</t </section>
>
</section> </section>
</section> <section numbered="true" toc="default">
<section title="Entity"> <name>Entity</name>
<t>Entities (such as contacts, registrants, or registrars) can be queried by
handle as described in <xref target="RFC9082"/>. Since there is no global namesp
ace 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 t
hat entity, or the entity identifier itself is a fully qualified URL that can be
queried. The mechanism described in <xref target="RFC8521"/> MAY also be used.<
/t>
</section>
<section title="Non-existent Entries or RDAP URL Values">
<t>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.</t>
</section>
<section anchor="deploy" title="Deployment and Implementation Considerations">
<t>This method relies on the fact that RDAP clients are fetching the IANA reg
istries to then find the servers locally. Clients SHOULD NOT fetch the registry
on every RDAP request. Clients SHOULD cache the registry, but use underlying pro
tocol signaling, such as the HTTP Expires header field <xref target="RFC7234"/>,
to identify when it is time to refresh the cached registry.</t>
<t>Some authorities of registration data may work together on sharing their i
nformation for a common service, including mutual redirection <xref target="REDI
RECT-RDAP"/>.</t>
<t>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 serve
r for this new entry may become live and registered later. Therefore, the client
s should expect that even if an object, such as TLD, IP address range, or AS ran
ge is allocated, the existence of the entry in the corresponding bootstrap regis
try is not guaranteed.</t>
</section>
<section title="Limitations">
<t>This method does not provide a direct way to find authoritative RDAP serv
ers for any other objects than the ones described in this document. In particula
r, the following objects are not bootstrapped with the method described in this
document:
<list style="symbols">
<t>entities</t>
<t>queries using search patterns that do not contain a terminating strin
g that matches some entries in the registries</t>
<t>nameservers</t>
<t>help</t>
</list>
</t>
</section>
<section anchor="abnf" title="Formal Definition">
<t>This section is the formal definition of the registries. The structure of JSO
N objects and arrays using a set of primitive elements is defined in <xref targe
t="RFC8259"/>. Those elements are used to describe the JSON structure of the reg
istries.</t>
<section title="Imported JSON Terms"> <t>Entities (such as contacts, registrants, or registrars) can be queried
by handle as described in <xref target="RFC9082" format="default"/>. Since there
is no global name space for entities, this document does not describe how to fi
nd 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 c
ould be queried for that entity, or the entity identifier itself is a fully qual
ified URL that can be queried. The mechanism described in <xref target="RFC8521"
format="default"/> <bcp14>MAY</bcp14> also be used.</t>
</section>
<section numbered="true" toc="default">
<name>Non-existent Entries or RDAP URL Values</name>
<t>The registries may not contain the requested value. In these cases, the
re is no known RDAP server for that requested value, and the client <bcp14>SHOUL
D</bcp14> provide an appropriate error message to the user.</t>
</section>
<t> <section anchor="deploy" numbered="true" toc="default">
<list style="symbols"> <name>Deployment and Implementation Considerations</name>
<t>OBJECT: a JSON object, defined in Section 4 of <xref target="RFC8259"/></t> <t>This method relies on the fact that RDAP clients are fetching the
<t>MEMBER: a member of a JSON object, defined in Section 4 of <xref target="RF IANA registries to then find the servers locally. Clients <bcp14>SHOULD
C8259"/></t> NOT</bcp14> fetch the registry on every RDAP request. Clients
<t>MEMBER-NAME: the name of a MEMBER, defined as a "string" in <bcp14>SHOULD</bcp14> cache the registry, but use underlying protocol
Section 4 of <xref target="RFC8259"/></t> signaling, such as the HTTP Expires header field <xref target="RFC7234"
<t>MEMBER-VALUE: the value of a MEMBER, defined as a "value" in format="default"/>, to identify when it is time to refresh the cached
Section 4 of <xref target="RFC8259"/></t> registry.</t>
<t>ARRAY: an array, defined in Section 5 of <xref target="RFC8259"/></t> <t>Some authorities of registration data may work together on sharing thei
<t>ARRAY-VALUE: an element of an ARRAY, defined in Section 5 of r information for a common service, including mutual redirection <xref target="I
<xref target="RFC8259"/></t> -D.ietf-weirds-redirects" format="default"/>.</t>
<t>STRING: a "string", as defined in Section 7 of <xref target="RFC8259"/></t> <t>When a new object is allocated, such as a new AS range, a new TLD, or a
</list> new IP address range, there is no guarantee that this new object will have an e
</t> ntry in the corresponding bootstrap RDAP registry, since the setup of the RDAP s
</section> erver for this new entry may become live and registered later. Therefore, the cl
<section title="Registry Syntax"> ients should expect that even if an object, such as TLD, IP address range, or AS
<t>Using the above terms for the JSON structures, the syntax of a range is allocated, the existence of the entry in the corresponding bootstrap r
registry is defined as follows: egistry is not guaranteed.</t>
<list style="symbols"> </section>
<t>rdap-bootstrap-registry: an OBJECT containing a MEMBER version and <section numbered="true" toc="default">
a MEMBER publication, an optional MEMBER description, and a MEMBER services- <name>Limitations</name>
list</t> <t>This method does not provide a direct way to find authoritative RDAP se
<t>version: a MEMBER with MEMBER-NAME "version" and rvers for any other objects than the ones described in this document. In particu
MEMBER-VALUE a STRING</t> lar, the following objects are not bootstrapped with the method described in thi
<t>publication: a MEMBER with MEMBER-NAME "publication" and s document:
MEMBER-VALUE a STRING</t> </t>
<t>description: a MEMBER with MEMBER-NAME "description" and <ul spacing="normal">
MEMBER-VALUE a STRING</t> <li>entities</li>
<t>services-list: a MEMBER with MEMBER-NAME "services" and MEMBER-VALUE a servi <li>queries using search patterns that do not contain a terminating stri
ces-array</t> ng that matches some entries in the registries</li>
<t>services-array: an ARRAY, where each ARRAY-VALUE is a service</t> <li>nameservers</li>
<t>service: an ARRAY of 2 elements, where the first ARRAY-VALUE is an entry-lis <li>help</li>
t and the second ARRAY-VALUE is a service-uri-list</t> </ul>
<t>entry-list: an ARRAY, where each ARRAY-VALUE is an entry</t> </section>
<t>entry: a STRING</t> <section anchor="abnf" numbered="true" toc="default">
<t>service-uri-list: an ARRAY, where each ARRAY-VALUE is a service-uri</t> <name>Formal Definition</name>
<t>service-uri: a STRING</t> <t>This section is the formal definition of the registries. The structure
</list> of JSON objects and arrays using a set of primitive elements is defined in <xref
</t> target="RFC8259" format="default"/>. Those elements are used to describe the JS
</section> ON structure of the registries.</t>
</section> <section numbered="true" toc="default">
<section title="Security Considerations"> <name>Imported JSON Terms</name>
<t>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 uses TLS <xref target="RFC8446"/> <dl>
.
</t>
<t>Additional considerations on using RDAP are described in <xref target="RFC748 <dt>OBJECT:
1"/>.</t> </dt>
</section> <dd>a JSON object, defined in <xref target="RFC8259"
<section title="Implementation Status"> sectionFormat="of" section="4" format="default"/>
<t> NOTE: Please remove this section and the reference to RFC 7942 prior to publ </dd>
ication as an RFC.</t>
<t>This section records the status of known implementations of the protocol defi <dt>MEMBER:
ned by this specification at the time of posting of this Internet-Draft, and is </dt>
based on a proposal described in <xref target="RFC7942"/>. The description of im <dd>a member of a JSON object, defined in <xref
plementations in this section is intended to assist the IETF in its decision pro target="RFC8259" format="default" sectionFormat="of" section="4"
cesses in progressing drafts to RFCs. Please note that the listing of any indiv />
idual implementation here does not imply endorsement by the IETF. Furthermore, </dd>
no effort has been spent to verify the information presented here that was suppl
ied by IETF contributors. This is not intended as, and must not be construed to
be, a catalog of available implementations or their features. Readers are advi
sed to note that other implementations may exist.</t>
<t>According to <xref target="RFC7942"/>, "this will allow reviewers and working <dt>MEMBER-NAME:
groups to assign due consideration to documents that have the benefit of runnin </dt>
g code, which may serve as evidence of valuable experimentation and feedback tha <dd>the name of a MEMBER, defined as a "string" in
t have made the implemented protocols more mature. It is up to the individual w <xref target="RFC8259" sectionFormat="of" section="4" format="default"/>
orking groups to use this information as they see fit". </t> </dd>
<section title="RDAP Browser Mobile Application">
<t>
<list>
<t>Responsible Organization: Viagenie</t>
<t>Author: Marc Blanchet</t>
<t>Location: https://viagenie.ca/rdapbrowser/</t>
<t>Description: RDAP Browser is an RDAP client for domain names, IP addresse
s and AS numbers fetching the IANA registries described in this document to find
the right authoritative RDAP server. End user can query any domain name, IP add
ress or AS number and the registration data will be shown on the screen.</t>
<t>Level of Maturity: Production (i.e. in the Android and iOS App stores sin
ce August 2019)</t>
<t>Contact Information: rdapbrowser@viagenie.ca</t>
<t>Information last updated: March 2021</t>
</list>
</t>
</section>
<section title="ICANN Lookup Web Application">
<t>
<list>
<t>Responsible Organization: ICANN </t>
<t>Location: https://lookup.icann.org</t>
<t>Description: ICANN's Domain Name Registration Data Lookup is an RDAP clie
nt for domain names fetching the IANA regis tries described in this document to
find the right authoritative RDAP server. End user can query any domain name and
the registration data will be shown on the screen.</t>
<t>Level of Maturity: Production</t>
<t>Information last updated: March 2021</t>
</list>
</t>
</section>
<section title="ARIN Implementation">
<t>
<list>
<t>Responsible Organization: ARIN</t>
<t>Base URL: https://rdap-bootstrap.arin.net/bootstrap ( Sample quer
y: https://rdap-bootstrap.arin.net/bootstrap/autnum/1 )</t>
<t>Description: ARIN RDAP Bootstrap server aids clients by reading t
he bootstrapping information published by IANA and using it to send HTTP redirec
ts to RDAP queries. RDAP clients https://search.arin.net/ and NicInfo ( https://
github.com/arineng/nicinfo ) use this bootstrap service. The underlying server s
oftware is open-sourced at https://github.com/arineng/rdap_bootstrap_server .</t
>
<t>Level of Maturity: Production</t>
<t>Contact Information: info@arin.net</t>
<t>Information Last Updated: Nov 2020</t>
</list>
</t>
</section>
</section>
<section anchor="ianaconsiderations" title="IANA Considerations">
<t>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 <xref target="struct"/>, <xref target="domainrdapreg"/>, and <xref
target="iprdapreg"/>, with the formal syntax specified in <xref target="abnf"/>.
The registries MUST be accessible only through HTTPS (TLS <xref target="RFC8446
"/>) transport.</t>
<t>The process for adding or updating entries in these registries differs from t <dt>MEMBER-VALUE:
he normal IANA registry processes: these registries are generated from the data, </dt>
processes, and policies maintained by IANA in their allocation registries (<xre <dd>the value of a MEMBER, defined as a "value" in
f target="ipv4reg"/>, <xref target="ipv6reg"/>, <xref target="asreg"/>, and <xre <xref target="RFC8259" sectionFormat="of" section="4" format="default"
f target="domainreg"/>), with the addition of new RDAP server information.</t> />
</dd>
<t>IANA updates RDAP Bootstrap Services Registries entries from the allocation r <dt>ARRAY:
egistries as those registries are updated.</t> </dt>
<dd>an array, defined in <xref target="RFC8259"
format="default" sectionFormat="of" section="5"/>
</dd>
<t>This document does not change any policies related to the allocation <dt>ARRAY-VALUE:
registries; IANA has provided a mechanism for collecting the RDAP server informa </dt>
tion.</t> <dd>an element of an ARRAY, defined in <xref
target="RFC8259" sectionFormat="of" section="5"
format="default"/>
</dd>
<t>IANA has created a new top-level category on the Protocol Registries page, <dt>STRING:
&lt;https://www.iana.org/protocols&gt;. The group is called "Registration Data </dt>
Access Protocol (RDAP)". <dd>a "string", as defined in <xref target="RFC8259"
format="default" sectionFormat="of" section="7"/>
</dd>
</dl>
Each of the RDAP Bootstrap Services Registries has </section>
been made available for general public on-demand download in the JSON format, <section numbered="true" toc="default">
and that registry's URI is listed directly on the Protocol Registries page. <name>Registry Syntax</name>
<t>Using the above terms for the JSON structures, the syntax of a
registry is defined as follows:
</t> </t>
<t>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.</t>
<t>Because these registries will be accessed by software, the download demand <dl>
for the RDAP Bootstrap Services Registries may be unusually high compared to <dt>rdap-bootstrap-registry:
normal IANA registries. The technical infrastructure by which registries are </dt>
published has been put in place by IANA to support the load. Since the publicati <dd>an OBJECT containing a MEMBER version and a MEMBER publication, an optiona
on of <xref target="RFC7484"/>, no issue have been reported regarding the load l MEMBER description, and a MEMBER services-list
or the service. </t> </dd>
<t>As discussed in <xref target="deploy"/>, software that accesses these registr <dt>version:
ies will depend on the HTTP Expires header field to limit their query rate. It i </dt>
s, therefore, important for that header field to be properly set to provide time <dd>a MEMBER with MEMBER-NAME "version" and MEMBER-VALUE a STRING
ly information as the registries change, while maintaining a reasonable load on </dd>
the IANA servers.</t>
<t>The HTTP Content-Type returned to clients accessing these JSON-formatted regi <dt>publication:
stries MUST be "application/json", as defined in <xref target="RFC8259"/>.</t> </dt>
<dd>a MEMBER with MEMBER-NAME "publication" and MEMBER-VALUE a STRING
</dd>
<t>Because of how information in the RDAP Bootstrap Services Registries is group <dt>description:
ed and formatted, the registry entries may not be sortable. It is, therefore, n </dt>
ot required or expected that the entries be ordered in any way.</t> <dd>a MEMBER with MEMBER-NAME "description" and MEMBER-VALUE a STRING
</dd>
<t>NOTE TO IANA: Please update the registries to reference this new RFC instead <dt>services-list:
of RFC 7484 once this document is approved by the IESG and published by the RFC </dt>
Editor". RFC-Editor, please remove this paragraph before publication</t> <dd>a MEMBER with MEMBER-NAME "services" and MEMBER-VALUE a services-array
</dd>
<dt>services-array:
</dt>
<dd>an ARRAY, where each ARRAY-VALUE is a service
</dd>
<dt>service:
</dt>
<dd>an ARRAY of 2 elements, where the first ARRAY-VALUE is an entry-list and t
he second ARRAY-VALUE is a service-uri-list
</dd>
<dt>entry-list:
</dt>
<dd>an ARRAY, where each ARRAY-VALUE is an entry
</dd>
<dt>entry:
</dt>
<dd>a STRING
</dd>
<dt>service-uri-list:
</dt>
<dd>an ARRAY, where each ARRAY-VALUE is a service-uri
</dd>
<dt>service-uri:
</dt>
<dd>a STRING
</dd>
</dl>
<section title="Bootstrap Service Registry for IPv4 Address Space">
<t>Entries in this registry contain at least the following:
<list style="symbols">
<t>a CIDR <xref target="RFC4632"/> specification of the network block being re
gistered.</t>
<t>one or more URLs that provide the RDAP service regarding this registration.
</t>
</list>
</t>
</section>
<section title="Bootstrap Service Registry for IPv6 Address Space">
<t>Entries in this registry contain at least the following:
<list style="symbols">
<t>an IPv6 prefix <xref target="RFC5952"/> specification of the network block
being registered.</t>
<t>one or more URLs that provide the RDAP service regarding this registration.
</t>
</list>
</t>
</section>
<section title="Bootstrap Service Registry for AS Number Space">
<t>Entries in this registry contain at least the following:
<list style="symbols">
<t>a range of Autonomous System numbers being registered.</t>
<t>one or more URLs that provide the RDAP service regarding this registration.
</t>
</list>
</t>
</section> </section>
<section title="Bootstrap Service Registry for Domain Name Space"> </section>
<t>Entries in this registry contain at least the following: <section numbered="true" toc="default">
<list style="symbols"> <name>Security Considerations</name>
<t>a domain name attached to the root being registered.</t> <t>By providing a bootstrap method to find RDAP servers, this document
<t>one or more URLs that provide the RDAP service regarding this registration. helps to ensure that the end users will get the RDAP data from an
</t> authoritative source instead of from rogue sources. The method has the
</list> same security properties as the RDAP protocols themselves.
The transport used to access the registries uses TLS <xref target="RFC8446" f
ormat="default"/>.
</t>
<t>Additional considerations on using RDAP are described in <xref target="
RFC7481" format="default"/>.</t>
</section>
<section anchor="ianaconsiderations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>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 Sections <xref target="struct" format="counter"/>, <xref target="do
mainrdapreg" format="counter"/>, and <xref target="iprdapreg" format="counter"/>
, with the formal syntax specified in <xref target="abnf" format="default"/>. Th
e registries <bcp14>MUST</bcp14> be accessible only through HTTPS (TLS <xref tar
get="RFC8446" format="default"/>) transport.</t>
<t>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
(<xref target="ipv4reg" format="default"/>, <xref target="ipv6reg" format="defa
ult"/>, <xref target="asreg" format="default"/>, and <xref target="domainreg" fo
rmat="default"/>), with the addition of new RDAP server information.</t>
<t>IANA updates RDAP Bootstrap Services Registries entries from the
allocation registries as those registries are updated.</t>
<t>This document does not change any policies related to the allocation
registries; IANA has provided a mechanism for collecting the RDAP server informa
tion.</t>
<t>IANA has created a new top-level category on the Protocol Registries page:
<eref target="https://www.iana.org/protocols" brackets="angle"/>. The group
is
called "Registration Data Access Protocol (RDAP)".
Each of the RDAP Bootstrap Services Registries has been made available for
on-demand download in the JSON format by the general public, and that registry's
URI
is listed directly on the Protocol Registries page.
</t> </t>
</section> <t>Other normal registries will be added to this group by other
</section> 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.</t>
<t>Because these registries will be accessed by software, the download dem
and
for the RDAP Bootstrap Services Registries may be unusually high compared to
normal IANA registries. The technical infrastructure by which registries are
published has been put in place by IANA to support the load. Since the publicati
on of <xref target="RFC7484" format="default"/>, no issues have been reported r
egarding the load or the service. </t>
<t>As discussed in <xref target="deploy" format="default"/>, 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 prope
rly set to provide timely information as the registries change, while maintainin
g a reasonable load on the IANA servers.</t>
<t>The HTTP Content-Type returned to clients accessing these JSON-formatte
d registries <bcp14>MUST</bcp14> be "application/json", as defined in <xref targ
et="RFC8259" format="default"/>.</t>
<t>Because of how information in the RDAP Bootstrap Services Registries is
grouped and formatted, the registry entries may not be sortable. It is, theref
ore, not required or expected that the entries be ordered in any way.</t>
</middle> <section numbered="true" toc="default">
<back> <name>Bootstrap Service Registry for IPv4 Address Space</name>
<references title="Normative References"> <t>Entries in this registry contain at least the following:
<?rfc include="reference.RFC.2119"?> </t>
<?rfc include="reference.RFC.3339"?> <ul spacing="normal">
<?rfc include="reference.RFC.4632"?> <li>a CIDR <xref target="RFC4632" format="default"/> specification of
<?rfc include="reference.RFC.5396"?> the network block being registered</li>
<?rfc include="reference.RFC.5890"?> <li>one or more URLs that provide the RDAP service regarding this regi
<?rfc include="reference.RFC.5952"?> stration</li>
<?rfc include="reference.RFC.7258"?> </ul>
<?rfc include="reference.RFC.7480"?> </section>
<?rfc include="reference.RFC.8174"?> <section numbered="true" toc="default">
<?rfc include="reference.RFC.8259"?> <name>Bootstrap Service Registry for IPv6 Address Space</name>
</references> <t>Entries in this registry contain at least the following:
</t>
<ul spacing="normal">
<li>an IPv6 prefix <xref target="RFC5952" format="default"/> specifica
tion of the network block being registered</li>
<li>one or more URLs that provide the RDAP service regarding this regi
stration
</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Bootstrap Service Registry for AS Number Space</name>
<t>Entries in this registry contain at least the following:
</t>
<ul spacing="normal">
<li>a range of Autonomous System numbers being registered</li>
<li>one or more URLs that provide the RDAP service regarding this
registration
</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Bootstrap Service Registry for Domain Name Space</name>
<t>Entries in this registry contain at least the following:
</t>
<ul spacing="normal">
<li>a domain name attached to the root being registered</li>
<li>one or more URLs that provide the RDAP service regarding this regi
stration
</li>
</ul>
</section>
</section>
<references title="Informative References"> </middle>
<?rfc include="reference.RFC.7071"?> <back>
<?rfc include="reference.RFC.7234"?>
<?rfc include="reference.RFC.7481"?>
<?rfc include="reference.RFC.7484"?>
<?rfc include="reference.RFC.7942"?>
<?rfc include="reference.RFC.8446"?>
<?rfc include="reference.RFC.8521"?>
<?rfc include="reference.RFC.9082"?>
<?rfc include="reference.RFC.9083"?>
<!--I-D.ietf-weirds-redirects, Expired - not in queue--> <displayreference target="I-D.ietf-weirds-redirects" to="REDIRECT-RDAP"/>
<reference anchor='REDIRECT-RDAP'>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3339.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4632.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5396.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5890.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5952.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7258.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7480.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8259.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7071.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7481.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7484.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8521.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9082.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9083.xml"/>
<reference anchor="I-D.ietf-weirds-redirects">
<front> <front>
<title>Redirection Service for Registration Data Access Protocol</title> <title>Redirection Service for Registration Data Access Protocol</title>
<author initials='C' surname='Martinez' fullname='Carlos Martinez'> <author initials='C.M.' surname='Martinez' fullname='Carlos M. Martinez' role='e
<organization /> ditor'/>
</author>
<author initials='L' surname='Zhou' fullname='Linlin Zhou'> <author initials='L.' surname='Zhou' fullname='Linlin Zhou' role='editor' />
<organization />
</author> <author initials='G.' surname='Rada' fullname='Gerardo Rada' />
<author initials='G' surname='Rada' fullname='Gerardo Rada'> <date month='July' year='2014'/>
<organization />
</author>
<date month='July' year='2014' />
</front> </front>
<seriesInfo name='Work in Progress,' value='draft-ietf-weirds-redirects-04' /> <seriesInfo name="Internet-Draft" value="draft-ietf-weirds-redirects-04"/>
</reference> </reference>
<reference anchor="ipv4reg" target="https://www.iana.org/assignments/ipv4-ad
dress-space">
<front><title>IPv4 Address Space Registry</title>
<author>
<organization>IANA</organization></author>
<date/>
</front>
</reference>
<reference anchor="ipv6reg" target="https://www.iana.org/assignments/ipv6-un <reference anchor="ipv4reg" target="https://www.iana.org/assignments/ipv
icast-address-assignments"> 4-address-space">
<front><title>IPv6 Global Unicast Address Assignments</title> <front>
<author> <title>IANA IPv4 Address Space Registry</title>
<organization>IANA</organization></author> <author>
<date/></front> <organization>IANA</organization>
</reference> </author>
<date/>
</front>
</reference>
<reference anchor="asreg" target="https://www.iana.org/assignments/as-number <reference anchor="ipv6reg" target="https://www.iana.org/assignments/ipv
s"> 6-unicast-address-assignments">
<front><title>Autonomous System (AS) Numbers</title> <front>
<author> <title>IPv6 Global Unicast Address Assignments</title>
<organization>IANA</organization></author> <author>
<date/> <organization>IANA</organization>
</front> </author>
</reference> <date/>
</front>
</reference>
<reference anchor="domainreg" target="https://www.iana.org/domains/root/db"> <reference anchor="asreg" target="https://www.iana.org/assignments/as-nu
<front><title>Root Zone Database</title> mbers">
<author> <front>
<organization>IANA</organization></author> <title>Autonomous System (AS) Numbers</title>
<date/></front> <author>
</reference> <organization>IANA</organization>
</references> </author>
<date/>
</front>
</reference>
<section title="Acknowledgements" numbered="no"> <reference anchor="domainreg" target="https://www.iana.org/domains/root/
<t>The WEIRDS working group had multiple discussions on this topic, db">
including a session during IETF 84, where various methods such as <front>
in&nbhy;DNS and others were debated. <title>Root Zone Database</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
</references>
</references>
<section numbered="true" toc="default">
<name>Changes since RFC 7484</name>
<t>There are no substantive changes except for minor clarifications.
This update is primarily to meet the requirements for moving to an Interne
t
Standard.</t>
</section>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>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 <contact
fullname="Andy Newton"/>. All the people involved in these discussions are
herein acknowledged. <contact fullname="Linlin Zhou"/>, <contact
fullname="Jean-Philippe Dionne"/>, <contact fullname="John Levine"/>, <contact
fullname="Kim Davies"/>, <contact fullname="Ernie Dainow"/>, <contact
fullname="Scott Hollenbeck"/>, <contact fullname="Arturo Servin"/>, <contact
fullname="Andy Newton"/>, <contact fullname="Murray Kucherawy"/>, <contact
fullname="Tom Harrison"/>, <contact fullname="Naoki Kambe"/>, <contact
fullname="Alexander Mayrhofer"/>, <contact fullname="Edward Lewis"/>, <contact
fullname="Pete Resnick"/>, <contact fullname="Alessandro Vesely"/>, <contact
fullname="Bert Greevenbosch"/>, <contact fullname="Barry Leiba"/>, <contact
fullname="Jari Arkko"/>, <contact fullname="Kathleen Moriaty"/>, <contact
fullname="Stephen Farrell"/>, <contact fullname="Richard Barnes"/>, and
<contact fullname="Jean-Francois Tremblay"/> provided input and suggestions to
the first version of this document.</t>
<t>
<contact fullname="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 <xref target="RFC7071" sectionFormat="of" section="6.2"
format="default"/>. This new version [This document] received comments and
suggestions from <contact fullname="Gavin Brown"/>, <contact fullname="Patrick
Mevzek"/>, <contact fullname="John Levine"/>, <contact fullname="Jasdip
Singh"/>, <contact fullname="George Michaelson"/>, <contact fullname="Scott
Hollenbeck"/>, <contact fullname="Russ Housley"/>, <contact fullname="Joel
Halpern"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Benjamin
Kaduk"/>, <contact fullname="Scott Kelly"/>, <contact fullname="Éric
Vyncke"/>, <contact fullname="John Scudder"/>, <contact fullname="Erik
Kline"/>, and <contact fullname="Robert Wilton"/>. Errata for RFC 7484 were
submitted by <contact fullname="Pieter Vandepitte"/> and were applied to this
document.
</t>
The idea of using IANA registries was discovered by the author during discussion
s with his colleagues as well as by a comment from Andy Newton. All the people i
nvolved 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, J
ari Arkko, Kathleen Moriaty, Stephen Farrell, Richard Barnes, and Jean-Francois
Tremblay have provided input and suggestions to this document. Guillaume Leclan
che was a coauthor of this document for some revisions; his support is therein a
cknowledged and greatly appreciated. The section on formal definition was inspir
ed by Section 6.2 of <xref target="RFC7071"/>. This new version got comments an
d suggestions from: Gavin Brown, Patrick Mevzek, John Levine, Jasdip Singh, Geor
ge Michaelson, Scott Hollenbeck, Russ Housley, Joel Halpern, Lars Eggert, Benjam
in Kaduk, Scott Kelly, Eric Vyncke, John Scudder, Erik Kline, Robert Wilton. Err
ata of RFC7484 were submitted by Pieter Vandepitte and were applied to this vers
ion.</t>
</section>
<section title="Changes since RFC7484" numbered="no">
<t>There are no substantive changes except for updates to the implementation
status and minor clarifications.
This update is primarily to meet the requirements for moving to Internet
Standard.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 53 change blocks. 
585 lines changed or deleted 678 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/