draft-ietf-weirds-bootstrap-09.txt   draft-ietf-weirds-bootstrap-10.txt 
Network Working Group M. Blanchet Network Working Group M. Blanchet
Internet-Draft Viagenie Internet-Draft Viagenie
Intended status: Standards Track October 13, 2014 Intended status: Standards Track October 27, 2014
Expires: April 16, 2015 Expires: April 30, 2015
Finding the Authoritative Registration Data (RDAP) Service Finding the Authoritative Registration Data (RDAP) Service
draft-ietf-weirds-bootstrap-09.txt draft-ietf-weirds-bootstrap-10.txt
Abstract Abstract
This document specifies a method to find which Registration Data This document specifies a method to find which Registration Data
Access Protocol (RDAP) server is authoritative to answer queries for Access Protocol (RDAP) server is authoritative to answer queries for
a requested scope, such as domain names, IP addresses or Autonomous a requested scope, such as domain names, IP addresses or Autonomous
System numbers. System numbers.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Non-existent Entries or RDAP URL Values . . . . . . . . . . . 10 7. Non-existent Entries or RDAP URL Values . . . . . . . . . . . 10
8. Deployment and Implementation Considerations . . . . . . . . 10 8. Deployment and Implementation Considerations . . . . . . . . 10
9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Formal Definition . . . . . . . . . . . . . . . . . . . . . . 11 10. Formal Definition . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Imported JSON Terms . . . . . . . . . . . . . . . . . . 11 10.1. Imported JSON Terms . . . . . . . . . . . . . . . . . . 11
10.2. Registry Syntax . . . . . . . . . . . . . . . . . . . . 12 10.2. Registry Syntax . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12.1. IPv4 Address Space RDAP Bootstrap Service Registry . . . 13 12.1. IPv4 Address Space RDAP Bootstrap Service Registry . . . 13
12.2. IPv6 Address Space RDAP Bootstrap Service Registry . . . 13 12.2. IPv6 Address Space RDAP Bootstrap Service Registry . . . 14
12.3. Autonomous System Number Space RDAP Bootstrap Service 12.3. Autonomous System Number Space RDAP Bootstrap Service
Registry . . . . . . . . . . . . . . . . . . . . . . . . 14 Registry . . . . . . . . . . . . . . . . . . . . . . . . 14
12.4. Domain Name Space RDAP Bootstrap Service Registry . . . 14 12.4. Domain Name Space RDAP Bootstrap Service Registry . . . 14
12.5. Additional Consideration . . . . . . . . . . . . . . . . 14 12.5. Additional Consideration . . . . . . . . . . . . . . . . 14
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 15
14.2. Non-Normative References . . . . . . . . . . . . . . . . 15 14.2. Non-Normative References . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Querying and retrieving registration data from registries are defined Querying and retrieving registration data from registries are defined
in the Registration Data Access Protocol (RDAP) [I-D.ietf-weirds-rdap in the Registration Data Access Protocol (RDAP) [I-D.ietf-weirds-rdap
-query][I-D.ietf-weirds-using-http][I-D.ietf-weirds-json-response]. -query][I-D.ietf-weirds-using-http][I-D.ietf-weirds-json-response].
These documents do not specify where to send the queries. This These documents do not specify where to send the queries. This
document specifies a method to find which server is authoritative to document specifies a method to find which server is authoritative to
answer queries for the requested scope. answer queries for the requested scope.
Top-level domains(TLD), Autonomous numbers (AS), and network blocks Top-level domains(TLD), Autonomous System numbers (AS), and network
are delegated by IANA to Internet registries such as TLD registries blocks are delegated by IANA to Internet registries such as TLD
and Regional Internet Registries(RIR) that then issue further registries and Regional Internet Registries(RIR) that then issue
delegations and maintain information about them. Thus, obviously the further delegations and maintain information about them. Thus,
bootstrap information needed by RDAP clients is best generated from obviously the bootstrap information needed by RDAP clients is best
data and processes already maintained by IANA, whose registries generated from data and processes already maintained by IANA, whose
already exist at [ipv4reg], [ipv6reg], [asreg], and [domainreg]. registries already exist at [ipv4reg], [ipv6reg], [asreg], and
[domainreg].
The required new functionality in support of RDAP could be This document requests IANA to make an augmented version of
accomplished by augmenting these registries to contain new fields, or the existing registries available for the specific purpose of
creating second parallel registries containing the extra fields whose RDAP use, herein named RDAP Bootstrap Service Registries. An RDAP
entries mirror the existing ones. Either approach will satisfy the client fetches the RDAP Bootstrap Service Registries, extracts the
needs of this document. This document requests IANA to make these data and then does a match with the query data to find the
registries available for the specific purpose of RDAP use, herein authoritative registration data server and appropriate query base
named RDAP Bootstrap Service Registries. An RDAP client fetches the URL.
RDAP Bootstrap Service Registries, extracts the data and then does a
match with the query data to find the authoritative registration data
server and appropriate query base URL.
2. Conventions Used In This Document 2. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Structure of RDAP Bootstrap Service Registries 3. Structure of RDAP Bootstrap Service Registries
The RDAP Bootstrap Service Registries, as specified in Section 12, The RDAP Bootstrap Service Registries, as specified in Section 12,
skipping to change at page 8, line 23 skipping to change at page 8, line 23
"https://rir2.example.com/myrdap/" "https://rir2.example.com/myrdap/"
] ]
], ],
[ [
["2600::/16", "2100:ffff::/32"], ["2600::/16", "2100:ffff::/32"],
[ [
"http://example.org/" "http://example.org/"
] ]
], ],
[ [
["2001:0200:1000::/28"], ["2001:0200:1000::/36"],
[ [
"https://example.net/rdaprir2/", "https://example.net/rdaprir2/",
"http://example.net/rdaprir2/" "http://example.net/rdaprir2/"
] ]
] ]
] ]
} }
For example, a query for "2001:0200:1000::/48" matches the For example, a query for "2001:0200:1000::/48" matches the
"2001:0200::/23" entry and the "2001:0200:1000::/28" entry in 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 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 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 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 valid for this entry. The client chooses one of the base URLs from
this array; in this example it chooses "https://example.net/ this array; in this example it chooses "https://example.net/
rdaprir2/" because it's the secure version of the protocol. The rdaprir2/" because it's the secure version of the protocol. The
segment specified in [I-D.ietf-weirds-rdap-query] is then appended to segment specified in [I-D.ietf-weirds-rdap-query] is then appended to
the base URL to complete the query. The complete query is therefore the base URL to complete the query. The complete query is therefore
"https://example.net/rdaprir2/ip/2001:0200:1000::/48". If the server "https://example.net/rdaprir2/ip/2001:0200:1000::/48". If the server
does not answer, the client can then use another URL prefix from the does not answer, the client can then use another URL prefix from the
skipping to change at page 9, line 48 skipping to change at page 9, line 48
RDAP URLs valid for this entry. The client chooses one of the base RDAP URLs valid for this entry. The client chooses one of the base
URLs from this array; in this example it chooses URLs from this array; in this example it chooses
"https://example.net/rdaprir2/". The segment specified in "https://example.net/rdaprir2/". The segment specified in
[I-D.ietf-weirds-rdap-query] is then appended to the base URL to [I-D.ietf-weirds-rdap-query] is then appended to the base URL to
complete the query. The complete query is therefore complete the query. The complete query is therefore
"https://example.net/rdaprir2/autnum/65411". If the server does not "https://example.net/rdaprir2/autnum/65411". If the server does not
answer, the client can then use another URL prefix from the array. answer, the client can then use another URL prefix from the array.
6. Entity 6. Entity
Entities (such as contacts, registrants, or registrars) can
be queried by handle as described in [I-D.ietf-weirds-rdap-query].
Since there is no global namespace for entities, this document does Since there is no global namespace for entities, this document does
not describe how to find the authoritative RDAP server for entities. not describe how to find the authoritative RDAP server for entities.
It is possible however that, if the entity identifier was received It is possible however that, if the entity identifier was received
from a previous query, the same RDAP server could be queried for that 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 entity or the entity identifier itself is a fully referenced URL that
can be queried. can be queried.
7. Non-existent Entries or RDAP URL Values 7. Non-existent Entries or RDAP URL Values
The registries may not contain the requested value or the base RDAP The registries may not contain the requested value or the base RDAP
URL value may be empty. In these cases, there is no known RDAP URL value may be empty. In these cases, there is no known RDAP
server for that requested value and the client SHOULD provide an server for that requested value and the client SHOULD provide an
skipping to change at page 10, line 28 skipping to change at page 10, line 31
fetch the registry on every RDAP request. Clients SHOULD cache the fetch the registry on every RDAP request. Clients SHOULD cache the
registry, but use underlying protocol signalling, such as the HTTP registry, but use underlying protocol signalling, such as the HTTP
Expires header field [RFC7234], to identify when it is time to Expires header field [RFC7234], to identify when it is time to
refresh the cached registry. refresh the cached registry.
If the query data does not match any entry in the client cached If the query data does not match any entry in the client cached
registry, then the client may implement various methods, such as the registry, then the client may implement various methods, such as the
following: following:
o In the case of a domain object, the client may first query the DNS 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 a 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 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, 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. 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 However, if the DNS answer is positive, this may mean that the
currently cached registry is no longer current. The client could currently cached registry is no longer current. The client could
then fetch the registry, parse and then do the normal matching as then fetch the registry, parse and then do the normal matching as
specified above. This method may not work for all types of RDAP specified above. This method may not work for all types of RDAP
objects. objects.
o If the client knows the existence of an RDAP aggregator or o If the client knows the existence of an RDAP aggregator or
skipping to change at page 13, line 7 skipping to change at page 13, line 7
By providing a bootstrap method to find RDAP servers, this document 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 helps to ensure that the end-users will get the RDAP data from an
authoritative source, instead of from rogue sources. The method has authoritative source, instead of from rogue sources. The method has
the same security properties as the RDAP protocols themselves. The the same security properties as the RDAP protocols themselves. The
transport used to access the registries could be more secure by using transport used to access the registries could be more secure by using
TLS [RFC5246] if IANA supports it. TLS [RFC5246] if IANA supports it.
12. IANA Considerations 12. IANA Considerations
The required new functionality in support of RDAP could be
accomplished by augmenting the existing registries to contain new
fields, or creating second parallel registries containing the extra
fields whose entries mirror the existing ones. Either approach will
satisfy the needs of this document.
IANA is requested to make the RDAP Bootstrap Services Registries IANA is requested to make the RDAP Bootstrap Services Registries
described below available as JSON objects, the syntax of which are described below available as JSON objects, the syntax of which are
described by section 10. The process for adding or updating entries described by section 10. The process for adding or updating entries
into these registries does not correspond to the registration into these registries does not correspond to the registration
policies described in [RFC5226]; as stated earlier, these registries policies described in [RFC5226]; as stated earlier, these registries
are generated from the data, processes, and policies maintained by are generated from the data, processes, and policies maintained by
IANA in their allocation registries ([ipv4reg], [ipv6reg], [asreg], IANA in their allocation registries ([ipv4reg], [ipv6reg], [asreg],
and [domainreg]). IANA is expected to generate the RDAP Bootstrap and [domainreg]). IANA is expected to generate the RDAP Bootstrap
Services Registries data from these above mentioned registries, Services Registries data from these above mentioned registries,
according to their own registration policies. This document does not according to their own registration policies. This document does not
skipping to change at page 14, line 39 skipping to change at page 14, line 49
The WEIRDS working group had multiple discussions on this topic, The WEIRDS working group had multiple discussions on this topic,
including a session during IETF 84, where various methods such as in- including a session during IETF 84, where various methods such as in-
DNS and others were debated. The idea of using IANA registries was DNS and others were debated. The idea of using IANA registries was
discovered by the editor during discussions with his colleagues as discovered by the editor during discussions with his colleagues as
well as by a comment from Andy Newton. All the people involved in well as by a comment from Andy Newton. All the people involved in
these discussions are herein acknowledged. Linlin Zhou, Jean- these discussions are herein acknowledged. Linlin Zhou, Jean-
Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott
Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy, Tom Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy, Tom
Harrison, Naoki Kambe, Alexander Mayrhofer, Edward Lewis, Pete Harrison, Naoki Kambe, Alexander Mayrhofer, Edward Lewis, Pete
Resnick have provided input and suggestions to this document. Resnick, Alessandro Vesely, Bert Greevenbosch have provided input and
Guillaume Leclanche was a co-editor of this document for some suggestions to this document. Guillaume Leclanche was a co-editor of
revisions; his support is therein acknowledged and greatly this document for some revisions; his support is therein acknowledged
appreciated. The section on formal definition was inspired by and greatly appreciated. The section on formal definition was
section 6.2 of [RFC7071]. inspired by section 6.2 of [RFC7071].
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
 End of changes. 14 change blocks. 
32 lines changed or deleted 39 lines changed or added

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