draft-ietf-regext-rdap-rir-search-08.txt   draft-ietf-regext-rdap-rir-search-09.txt 
Internet Engineering Task Force T. Harrison Internet Engineering Task Force T. Harrison
Internet-Draft APNIC Internet-Draft APNIC
Intended status: Standards Track J. Singh Intended status: Standards Track J. Singh
Expires: 21 September 2024 ARIN Expires: 26 September 2024 ARIN
20 March 2024 25 March 2024
RDAP RIR Search RDAP RIR Search
draft-ietf-regext-rdap-rir-search-08 draft-ietf-regext-rdap-rir-search-09
Abstract Abstract
The Registration Data Access Protocol (RDAP) is used by Regional The Registration Data Access Protocol (RDAP) is used by Regional
Internet Registries (RIRs) and Domain Name Registries (DNRs) to Internet Registries (RIRs) and Domain Name Registries (DNRs) to
provide access to their resource registration information. The core provide access to their resource registration information. The core
specifications for RDAP define basic search functionality, but there specifications for RDAP define basic search functionality, but there
are various IP and ASN-related search options provided by RIRs via are various IP and ASN-related search options provided by RIRs via
their Whois services for which there is no corresponding RDAP their Whois services for which there is no corresponding RDAP
functionality. This document extends RDAP to support those search functionality. This document extends RDAP to support those search
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 21 September 2024. This Internet-Draft will expire on 26 September 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Basic Searches . . . . . . . . . . . . . . . . . . . . . . . 3 2. Basic Searches . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Path Segments . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Path Segments . . . . . . . . . . . . . . . . . . . . . . 3
2.2. IP Network Search . . . . . . . . . . . . . . . . . . . . 4 2.2. IP Network Search . . . . . . . . . . . . . . . . . . . . 4
2.3. Autonomous System Number Search . . . . . . . . . . . . . 4 2.3. Autonomous System Number Search . . . . . . . . . . . . . 4
3. Relation Searches . . . . . . . . . . . . . . . . . . . . . . 5 3. Relation Searches . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Path Segments . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Path Segments . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Relation Search . . . . . . . . . . . . . . . . . . . . . 6 3.2. Relation Search . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Definitions . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Definitions . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Relations . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Relations . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2.1. "up" . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2.1. Single-Result Searches . . . . . . . . . . . . . 11
3.2.2.2. "down" . . . . . . . . . . . . . . . . . . . . . 11 3.2.2.2. Multiple-Result Searches . . . . . . . . . . . . 11
3.2.2.3. "top" . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2.4. "bottom" . . . . . . . . . . . . . . . . . . . . 11
3.3. Status . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Status . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Link Relations . . . . . . . . . . . . . . . . . . . . . 12 3.4. Link Relations . . . . . . . . . . . . . . . . . . . . . 12
4. Responding To Searches . . . . . . . . . . . . . . . . . . . 15 4. Responding To Searches . . . . . . . . . . . . . . . . . . . 15
4.1. Single-Result Searches . . . . . . . . . . . . . . . . . 15
4.2. Multiple-Result Searches . . . . . . . . . . . . . . . . 15
5. Reverse Search . . . . . . . . . . . . . . . . . . . . . . . 17 5. Reverse Search . . . . . . . . . . . . . . . . . . . . . . . 17
6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 17 6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 17
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 7. Operational Considerations . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.2. Link Relations Registry . . . . . . . . . . . . . . . . . 20 10.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 19
9.3. RDAP Reverse Search Registry . . . . . . . . . . . . . . 21 10.2. Link Relations Registry . . . . . . . . . . . . . . . . 20
9.4. RDAP Reverse Search Mapping Registry . . . . . . . . . . 22 10.3. RDAP Reverse Search Registry . . . . . . . . . . . . . . 21
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 10.4. RDAP Reverse Search Mapping Registry . . . . . . . . . . 23
10.1. APNIC RDAP Implementation . . . . . . . . . . . . . . . 24 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 11.1. APNIC RDAP Implementation . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.2. RIPE NCC RDAP Implementation . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The Registration Data Access Protocol (RDAP) [RFC7480] is used by The Registration Data Access Protocol (RDAP) [RFC7480] is used by
Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)
to provide access to their resource registration information. The to provide access to their resource registration information. The
core specifications for RDAP define basic search functionality, but core specifications for RDAP define basic search functionality, but
this is limited to domains, nameservers, and entities. No searches this is limited to domains, nameservers, and entities. No searches
were defined for IP networks or autonomous system numbers. In an were defined for IP networks or autonomous system numbers. In an
effort to have RDAP reach feature parity with the existing RIR Whois effort to have RDAP reach feature parity with the existing RIR Whois
services in this respect, this document defines additional search services in this respect, this document defines additional search
options for IP networks and autonomous system numbers. options for IP networks and autonomous system numbers.
While this document is in terms of RIRs and DNRs for the sake of While this document is in terms of RIRs and DNRs for the sake of
consistency with earlier RDAP documents such as [RFC9082] and consistency with earlier RDAP documents such as [RFC9082] and
[RFC9083], the functionality described here may be used by any RDAP [RFC9083], the functionality described here may be used by any RDAP
server operator that hosts Internet Number Resource (INR) objects, server operator that hosts Internet Number Resource (INR) objects.
such as National Internet Registries (NIRs) or Local Internet
Registries (LIRs).
1.1. Conventions Used in This Document 1.1. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Indentation and whitespace in examples are provided only to Indentation and whitespace in examples are provided only to
skipping to change at page 6, line 17 skipping to change at page 6, line 17
separated by a single hyphen ('-', US-ASCII value 0x2D), where the separated by a single hyphen ('-', US-ASCII value 0x2D), where the
second number is greater than the first. second number is greater than the first.
<resource type search path segment>: A search path segment <resource type search path segment>: A search path segment
corresponding to an Internet Number Resource (INR) object class corresponding to an Internet Number Resource (INR) object class
(i.e. an IP network address or range, autonomous system number or (i.e. an IP network address or range, autonomous system number or
number range, or reverse domain name). number range, or reverse domain name).
<object value>: a value used to identify an object for the <object value>: a value used to identify an object for the
purposes of a relation search relative to that object. One of <IP purposes of a relation search relative to that object. One of <IP
address>, <CIDR prefix>, <CIDR length>, <domain name>, or address>, <CIDR prefix> and <CIDR length> pair, <domain name>, or
<autonomous system number or range>, depending on the type of <autonomous system number or range>, depending on the type of
search that is being performed. search that is being performed.
<status>: an object status value, as defined in Section 4.6 of <status>: an object status value, as defined in Section 4.6 of
[RFC9083]. [RFC9083].
The new resource type path segments for relation search (similar to The new resource type path segments for relation search (similar to
the searches defined in [RFC9082] and [RFC9083]) are: the searches defined in [RFC9082] and [RFC9083]) are:
'ips/rirSearch1/<relation>/<IP address>': Used to identify an IP 'ips/rirSearch1/<relation>/<IP address>': Used to identify an IP
skipping to change at page 6, line 51 skipping to change at page 6, line 51
reverse domain search using a relation and a reverse domain name reverse domain search using a relation and a reverse domain name
to match a set of reverse domains. to match a set of reverse domains.
3.2. Relation Search 3.2. Relation Search
Syntax: <resource type search path Syntax: <resource type search path
segment>/rirSearch1/<relation>/<object value>[?status=<status>] segment>/rirSearch1/<relation>/<object value>[?status=<status>]
The relation searches defined in this document rely on the syntax The relation searches defined in this document rely on the syntax
described above. Each search works in the same way for each object described above. Each search works in the same way for each object
type. class.
3.2.1. Definitions 3.2.1. Definitions
An INR object value may have a "parent" object and one or more An INR object value may have a "parent" object and one or more
"child" objects. The "parent" object is the next-least-specific "child" objects. The "parent" object is the next-least-specific
object that exists in the relevant registry, while the "child" object that exists in the relevant registry, while the "child"
objects are the next-most-specific objects that exist in the relevant objects are the next-most-specific objects that exist in the relevant
registry. For example, for a registry with the following seven IP registry. For example, for a registry with the following seven IP
network objects: network objects:
skipping to change at page 8, line 18 skipping to change at page 8, line 18
| 192.0.2.0/32 | 192.0.2.0/28 | | 192.0.2.0/32 | 192.0.2.0/28 |
+------------------+----------------+ +------------------+----------------+
| 192.0.2.0/28 | 192.0.2.0/25 | | 192.0.2.0/28 | 192.0.2.0/25 |
+------------------+----------------+ +------------------+----------------+
| 192.0.2.64/26 | 192.0.2.0/25 | | 192.0.2.64/26 | 192.0.2.0/25 |
+------------------+----------------+ +------------------+----------------+
| 192.0.2.128/26 | 192.0.2.128/25 | | 192.0.2.128/26 | 192.0.2.128/25 |
+------------------+----------------+ +------------------+----------------+
| 192.0.2.192/26 | 192.0.2.128/25 | | 192.0.2.192/26 | 192.0.2.128/25 |
+------------------+----------------+ +------------------+----------------+
| 192.0.2.128/25 | 192.0.2.0/24 |
+------------------+----------------+
| 192.0.2.0/25 | 192.0.2.0/24 | | 192.0.2.0/25 | 192.0.2.0/24 |
+------------------+----------------+ +------------------+----------------+
| 192.0.2.128/25 | 192.0.2.0/24 |
+------------------+----------------+
| 192.0.2.0/24 | N/A | | 192.0.2.0/24 | N/A |
+------------------+----------------+ +------------------+----------------+
Table 1: Parent objects Table 1: Parent objects
+==================+================================+ +==================+================================+
| INR object value | Child objects | | INR object value | Child objects |
+==================+================================+ +==================+================================+
| 192.0.2.0/24 | 192.0.2.0/25, 192.0.2.128/25 | | 192.0.2.0/24 | 192.0.2.0/25, 192.0.2.128/25 |
+------------------+--------------------------------+ +------------------+--------------------------------+
skipping to change at page 9, line 5 skipping to change at page 8, line 49
+------------------+--------------------------------+ +------------------+--------------------------------+
| 192.0.2.192/26 | N/A | | 192.0.2.192/26 | N/A |
+------------------+--------------------------------+ +------------------+--------------------------------+
| 192.0.2.0/28 | 192.0.2.0/32 | | 192.0.2.0/28 | 192.0.2.0/32 |
+------------------+--------------------------------+ +------------------+--------------------------------+
| 192.0.2.0/32 | N/A | | 192.0.2.0/32 | N/A |
+------------------+--------------------------------+ +------------------+--------------------------------+
Table 2: Child objects Table 2: Child objects
Along similar lines, each INR object value may have a "top" object, (INR object values do not necessarily correspond to registry objects,
being the least-specific covering object that exists in the registry, because users can provide arbitrary object values as input to the
and one or more "bottom" objects, being the most-specific objects searches defined in this document.)
that entirely cover the INR object value when taken together. Given Similarly to the parent/child object relationships, each INR object
the registry defined in the previous paragraph, the top and bottom value may have a "top" object, being the least-specific covering
object relationships are: object that exists in the registry, and one or more "bottom" objects,
being the most-specific objects that entirely cover the INR object
value when taken together. Given the registry defined in the
previous paragraph, the top and bottom object relationships are:
+==================+==============+ +==================+==============+
| INR object value | Top object | | INR object value | Top object |
+==================+==============+ +==================+==============+
| 192.0.2.0/32 | 192.0.2.0/24 | | 192.0.2.0/32 | 192.0.2.0/24 |
+------------------+--------------+ +------------------+--------------+
| 192.0.2.0/28 | 192.0.2.0/24 | | 192.0.2.0/28 | 192.0.2.0/24 |
+------------------+--------------+ +------------------+--------------+
| 192.0.2.64/26 | 192.0.2.0/24 | | 192.0.2.64/26 | 192.0.2.0/24 |
+------------------+--------------+ +------------------+--------------+
| 192.0.2.128/26 | 192.0.2.0/24 | | 192.0.2.128/26 | 192.0.2.0/24 |
+------------------+--------------+ +------------------+--------------+
| 192.0.2.192/26 | 192.0.2.0/24 | | 192.0.2.192/26 | 192.0.2.0/24 |
+------------------+--------------+ +------------------+--------------+
| 192.0.2.128/25 | 192.0.2.0/24 |
+------------------+--------------+
| 192.0.2.0/25 | 192.0.2.0/24 | | 192.0.2.0/25 | 192.0.2.0/24 |
+------------------+--------------+ +------------------+--------------+
| 192.0.2.128/25 | 192.0.2.0/24 |
+------------------+--------------+
| 192.0.2.0/24 | N/A | | 192.0.2.0/24 | N/A |
+------------------+--------------+ +------------------+--------------+
Table 3: Top objects Table 3: Top objects
+==================+===========================================+ +==================+===========================================+
| INR object value | Bottom objects | | INR object value | Bottom objects |
+==================+===========================================+ +==================+===========================================+
| 192.0.2.0/24 | 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32, | | 192.0.2.0/24 | 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32, |
| | 192.0.2.128/26, 192.0.2.192/26 | | | 192.0.2.128/26, 192.0.2.192/26 |
skipping to change at page 11, line 4 skipping to change at page 11, line 4
The bottom objects for a given INR object value may include an object The bottom objects for a given INR object value may include an object
that is less-specific than that INR object value. For example, that is less-specific than that INR object value. For example,
192.0.2.0/31 is an INR object value that has a more-specific object, 192.0.2.0/31 is an INR object value that has a more-specific object,
being 192.0.2.0/32, so the set of bottom objects must include at being 192.0.2.0/32, so the set of bottom objects must include at
least that object. The most-specific object that covers the residual least that object. The most-specific object that covers the residual
(i.e. 192.0.2.1/32) is 192.0.2.0/28, so it is included in the results (i.e. 192.0.2.1/32) is 192.0.2.0/28, so it is included in the results
as well. as well.
3.2.2. Relations 3.2.2. Relations
3.2.2.1. "up" 3.2.2.1. Single-Result Searches
3.2.2.1.1. "up"
If the server receives a search containing the relation value "up", If the server receives a search containing the relation value "up",
it will return the parent object for the specified INR object value. it will return the parent object for the specified INR object value
If no such object exists, it will return an empty search response. as though that object had been requested directly. If no such object
exists, it will respond with a HTTP 404 (Not Found) [RFC9110] search
response.
3.2.2.2. "down" 3.2.2.1.2. "top"
If the server receives a search containing the relation value "top",
it will return the top object for the specified INR object value as
though that object had been requested directly. If no such object
exists, it will respond with an HTTP 404 (Not Found) [RFC9110] search
response.
3.2.2.2. Multiple-Result Searches
3.2.2.2.1. "down"
If the server receives a search containing the relation value "down", If the server receives a search containing the relation value "down",
it will return the child objects for the specified INR object value. it will return the child objects for the specified INR object value.
If no such objects exist, it will return an empty search response. If no such objects exist, it will return an empty search response.
Per the definitions section, this includes only immediate child Per the definitions section, this includes only immediate child
objects. objects.
3.2.2.3. "top" 3.2.2.2.2. "bottom"
If the server receives a search containing the relation value "top",
it will return the top object for the specified INR object value. If
no such object exists, it will return an empty search response.
3.2.2.4. "bottom"
If the server receives a search containing the relation value If the server receives a search containing the relation value
"bottom", it will return the bottom objects for the specified INR "bottom", it will return the bottom objects for the specified INR
object value. If no such objects exist, it will return an empty object value. If no such objects exist, it will return an empty
search response. search response.
3.3. Status 3.3. Status
If the "status" argument is provided, then response processing will If the "status" argument is provided, then response processing will
proceed as though all objects without the specified status had first proceed as though all objects without the specified status had first
skipping to change at page 12, line 5 skipping to change at page 12, line 19
+----------------+----------+ +----------------+----------+
| 192.0.2.128/25 | inactive | | 192.0.2.128/25 | inactive |
+----------------+----------+ +----------------+----------+
| 192.0.2.128/26 | active | | 192.0.2.128/26 | active |
+----------------+----------+ +----------------+----------+
| 192.0.2.192/26 | active | | 192.0.2.192/26 | active |
+----------------+----------+ +----------------+----------+
Table 5: Statuses Table 5: Statuses
then a server receiving a "child" object query with the INR object then a server receiving a "down" search request with the INR object
value 192.0.2.0/24 and a "status" argument of "active" would return value 192.0.2.0/24 and a "status" argument of "active" would return
the objects 192.0.2.0/25, 192.0.2.128/26, and 192.0.2.192/26. the objects 192.0.2.0/25, 192.0.2.128/26, and 192.0.2.192/26.
Status filtering is useful, for example, where the client is trying Status filtering is useful, for example, where the client is trying
to find the delegation from an RIR to an RIR account holder: by using to find the delegation from an RIR to an RIR account holder: by using
the "top" relation with a "status" of "active", the delegation from the "top" relation with a "status" of "active", the delegation from
IANA to the RIR will be ignored, and the client will receive the IANA to the RIR will be ignored, and the client will receive the
delegation from the RIR to the account holder in the response delegation from the RIR to the account holder in the response
instead. instead.
By default, any valid status value may be used for status filtering. By default, any valid status value may be used for status filtering.
Server operators MAY opt not to support "status" filtering for the Server operators MAY opt not to support "status" filtering for the
"down" and "bottom" link relations, in which case the server should "down" and "bottom" link relations, in which case the server should
respond with a HTTP 501 (Not Implemented) [RFC9110] response code if respond with an HTTP 501 (Not Implemented) [RFC9110] response code if
it receives such a request. Server operators MAY also opt not to it receives such a request. Server operators MAY also opt not to
support "status" filtering for values other than "active" for the support "status" filtering for values other than "active" for the
"up" and "top" link relations, in which case the server should "up" and "top" link relations, in which case the server should
respond with a HTTP 501 (Not Implemented) [RFC9110] response code if respond with an HTTP 501 (Not Implemented) [RFC9110] response code if
it receives such a request. it receives such a request.
3.4. Link Relations 3.4. Link Relations
Each of the relations defined in section 3.2.2 has a corresponding Each of the relations defined in section 3.2.2 has a corresponding
link relation that can be used for a link object contained within link relation that can be used for a link object contained within
another RDAP object. When constructing these link objects, the another RDAP object. When constructing these link objects, the
server MUST set link targets that yield the same response as for the server MUST use the corresponding search URL for the link target, or
corresponding search. The following is an elided example of a a URL that yields the same response as for the corresponding search
response that makes use of those link relations: as at the time of the request. The following is an elided example of
a response that makes use of those link relations:
{ {
"startAddress": "192.0.2.0", "startAddress": "192.0.2.0",
"endAddress": "192.0.2.127", "endAddress": "192.0.2.127",
... ...
"links": [ "links": [
..., ...,
{ {
"value": "https://rdap.example.com/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "up", "rel": "up",
"href": "https://rdap.example.com/ips/rirSearch1/up/192.0.2.0/25", "href": "https://example.com/rdap/ips/rirSearch1/up/192.0.2.0/25",
"type": "application/rdap+json" "type": "application/rdap+json"
}, },
{ {
"value": "https://rdap.example.com/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "down", "rel": "down",
"href": "https://rdap.example.com/ips/rirSearch1/down/192.0.2.0/25", "href": "https://example.com/rdap/ips/rirSearch1/down/192.0.2.0/25",
"type": "application/rdap+json" "type": "application/rdap+json"
}, },
{ {
"value": "https://rdap.example.com/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "top", "rel": "top",
"href": "https://rdap.example.com/ips/rirSearch1/top/192.0.2.0/25", "href": "https://example.com/rdap/ips/rirSearch1/top/192.0.2.0/25",
"type": "application/rdap+json" "type": "application/rdap+json"
}, },
{ {
"value": "https://rdap.example.com/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "bottom", "rel": "bottom",
"href": "https://rdap.example.com/ips/rirSearch1/bottom/192.0.2.0/25", "href": "https://example.com/rdap/ips/rirSearch1/bottom/192.0.2.0/25",
"type": "application/rdap+json" "type": "application/rdap+json"
} }
] ]
} }
Figure 2: Example links Figure 2: Example links
Two additional link relations are defined that correspond to relation Two additional link relations are defined that correspond to relation
searches with a "status" of "active": "up-active" and "top-active". searches with a "status" of "active": "up-active" and "top-active".
No other status-specific link relations are defined, because the only No other status-specific link relations are defined, because the only
skipping to change at page 14, line 12 skipping to change at page 14, line 12
relations and the "active" status. The following is an elided relations and the "active" status. The following is an elided
example of a response that makes use of those link relations: example of a response that makes use of those link relations:
{ {
"startAddress": "192.0.2.0", "startAddress": "192.0.2.0",
"endAddress": "192.0.2.127", "endAddress": "192.0.2.127",
... ...
"links": [ "links": [
..., ...,
{ {
"value": "https://rdap.example.com/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "up-active", "rel": "up-active",
"href": "href":
"https://rdap.example.com/ips/rirSearch1/up/192.0.2.0/25?status=active", "https://example.com/rdap/ips/rirSearch1/up/192.0.2.0/25?status=active",
"type": "application/rdap+json" "type": "application/rdap+json"
}, },
{ {
"value": "https://rdap.example.com/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "top-active", "rel": "top-active",
"href": "href":
"https://rdap.example.com/ips/rirSearch1/top/192.0.2.0/25?status=active", "https://example.com/rdap/ips/rirSearch1/top/192.0.2.0/25?status=active",
"type": "application/rdap+json" "type": "application/rdap+json"
} }
] ]
} }
Figure 3: Example status links Figure 3: Example status links
Since the "top" and "up" link relations resolve to a single object, Since the "top" and "up" link relations resolve either to a single
it is possible to simply include that object's link in the "href" object or to an HTTP 404 (Not Found) [RFC9110] response, it is
attribute in the link object. The following is an elided example of possible for a server to use a lookup URL in the "href" attribute in
a response that uses this approach: the link object. The following is an elided example of a response
that uses this approach:
{ {
"startAddress": "192.0.2.0", "startAddress": "192.0.2.0",
"endAddress": "192.0.2.127", "endAddress": "192.0.2.127",
... ...
"links": [ "links": [
..., ...,
{ {
"value": "https://rdap.example.com/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "up", "rel": "up",
"href": "https://rdap.example.com/192.0.2.0/24", "href": "https://example.com/rdap/ip/192.0.2.0/24",
"type": "application/rdap+json" "type": "application/rdap+json"
} }
] ]
} }
Figure 4: Example single object links Figure 4: Example single-result links
This section mandates specific behaviour for the "up" link relation, This section mandates specific behaviour for the "up" link relation,
but does not define that link relation (see [RFC8288]). This is but does not define that link relation (see [RFC8288]). This is
acceptable, because this behaviour: acceptable, because this behaviour:
does not conflict with the current description of the link does not conflict with the current description of the link
relation; and relation; and
is not generally applicable, but instead limited to the context of is not generally applicable, but instead limited to the context of
RDAP INR objects only. RDAP INR objects only.
Use of these link relations in responses is OPTIONAL. The absence in Use of these link relations in responses is OPTIONAL. The absence in
a response of a link for a specific relation does not necessarily a response of a link for a specific relation does not necessarily
mean that the corresponding object does not exist or that the mean that the corresponding search will return no results.
corresponding search will return no results.
4. Responding To Searches 4. Responding To Searches
As with [RFC9083], responses to the IP network and autonomous system 4.1. Single-Result Searches
number searches defined in the previous sections take the form of an
The "up" and "top" relations are single-result searches. When
processing these searches, if there is a result for the search, the
server returns that object as though it were requested directly via a
lookup URL (see section 3.1 of [RFC9082]). If there is no result for
the search, the server returns an HTTP 404 (Not Found) [RFC9110]
response code.
4.2. Multiple-Result Searches
The "down" and "bottom" relations are multiple-result searches. As
with [RFC9083], responses for these searches take the form of an
array of object instances, where each instance is an appropriate array of object instances, where each instance is an appropriate
object class for the search (i.e., a search beginning with /ips object class for the search (i.e., a search beginning with /ips
yields an array of IP network object instances, and a search yields an array of IP network object instances, and a search
beginning with /autnums yields an array of autonomous system number beginning with /autnums yields an array of autonomous system number
object instances). The IP network object and autonomous system object instances). The IP network object and autonomous system
number object types are defined in sections 5.4 and 5.5 of [RFC9083]. number object classes are defined in sections 5.4 and 5.5 of
The object instance arrays are contained within the response object. [RFC9083]. The object instance arrays are contained within the
response object.
The names of the arrays are as follows: The names of the arrays are as follows:
for /ips searches, the array is "ipSearchResults"; and for /ips searches, the array is "ipSearchResults"; and
for /autnums searches, the array is "autnumSearchResults". for /autnums searches, the array is "autnumSearchResults".
The following is an elided example of a response to an IP network The following is an elided example of a response to an IP network
search: search:
skipping to change at page 16, line 47 skipping to change at page 16, line 47
{ {
"objectClassName": "autnum", "objectClassName": "autnum",
"handle": "XXXX-RIR", "handle": "XXXX-RIR",
"startAutnum": 64496, "startAutnum": 64496,
"endAutnum": 64496, "endAutnum": 64496,
... ...
}, },
{ {
"objectClassName": "autnum", "objectClassName": "autnum",
"handle": "YYYY-RIR", "handle": "YYYY-RIR",
"startAddress": "64497", "startAutnum": "64497",
"endAddress": "64497", "endAutnum": "64497",
... ...
} }
] ]
} }
Figure 6: ASN search response Figure 6: ASN search response
Responses for relation searches for reverse domain objects have the Responses for relation searches for reverse domain objects have the
same form as for a standard domain search response, per [RFC9083]. same form as for a standard domain search response, per [RFC9083].
If the search can be processed by the server, but there are no If the search can be processed by the server, but there are no
results for the search, then the server returns a HTTP 200 (OK) results for the search, then the server returns an HTTP 200 (OK)
response code, with the body of the response containing an empty [RFC9110] response code, with the body of the response containing an
results array. empty results array.
5. Reverse Search 5. Reverse Search
RDAP reverse search is defined by RDAP reverse search is defined by
[I-D.ietf-regext-rdap-reverse-search]. That document limits reverse [I-D.ietf-regext-rdap-reverse-search]. That document limits reverse
search to domains, nameservers, and entities. This document extends search to domains, nameservers, and entities. This document extends
reverse search to cover IP networks and autonomous system numbers as reverse search to cover IP networks and autonomous system numbers as
well. well.
If a server receives a reverse search query with a searchable If a server receives a reverse search query with a searchable
resource type (per the definition of that term in resource type (per the definition of that term in
[I-D.ietf-regext-rdap-reverse-search]) of "ips", then the reverse [I-D.ietf-regext-rdap-reverse-search]) of "ips", then the reverse
search will be performed on the IP network objects from its data search will be performed on the IP network objects from its data
store. Similarly, if a server receives a reverse search query with a store. Similarly, if a server receives a reverse search query with a
searchable resource type of "autnums", then the reverse search will searchable resource type of "autnums", then the reverse search will
be performed on the autonomous system number objects from its data be performed on the autonomous system number objects from its data
store. store.
Additionally, Section 9 includes requests to register new entries for Additionally, Section 10 includes requests to register new entries
IP network and autonomous system number searches in the RDAP Reverse for IP network and autonomous system number searches in the RDAP
Search and RDAP Reverse Search Mapping IANA registries. Reverse Search and RDAP Reverse Search Mapping IANA registries.
6. RDAP Conformance 6. RDAP Conformance
A server that supports the functionality specified in this document A server that supports the functionality specified in this document
MUST include additional string literals in the rdapConformance array MUST include additional string literals in the rdapConformance array
of its responses, in accordance with the following: of its responses, in accordance with the following:
any response that includes an IP network basic search link, an IP any response that includes an IP network basic search link, an IP
network relation search link, or an IP network reverse search network relation search link, or an IP network reverse search
link, includes the "rirSearch1" and "ips" literals; link, includes the "rirSearch1" and "ips" literals;
skipping to change at page 18, line 24 skipping to change at page 18, line 24
a response to a "/help" request includes the "rirSearch1", "ips", a response to a "/help" request includes the "rirSearch1", "ips",
"ipSearchResults", "autnums", and "autnumSearchResults" literals. "ipSearchResults", "autnums", and "autnumSearchResults" literals.
Although responses will generally not include all of the Although responses will generally not include all of the
rdapConformance string literals defined in this document, that is not rdapConformance string literals defined in this document, that is not
meant to imply that a server can support only a portion of the meant to imply that a server can support only a portion of the
functionality defined in this document. functionality defined in this document.
The "ips", "autnums", "ipSearchResults", and "autnumSearchResults" The "ips", "autnums", "ipSearchResults", and "autnumSearchResults"
extension identifiers are included here due to the requirements set extension identifiers are included here due to the requirements set
out in [RFC7480], [RFC9082], and [RFC9083] that an RDAP extension out in [RFC7480], [RFC9082], and [RFC9083]. These requirements are
identifier be used as a prefix in new path segments and JSON members that an RDAP extension identifier be used as a prefix in new path
introduced by the extension, and those strings are used as such as segments and JSON members introduced by the extension, and those
part of the basic searches defined in this document. Furthermore, strings are used as such as part of the basic searches defined in
using these strings as path segments helps to increase consistency this document. Furthermore, using these strings as path segments
among the basic searches for the core RDAP object types. helps to increase consistency among the basic searches for the core
RDAP object classes.
As with the other core object classes (entity, domain, and As with the other core object classes (entity, domain, and
nameserver), other documents may define additional reverse searches nameserver), other documents may define additional reverse searches
with IP networks and ASNs as the searchable resource type by with IP networks and ASNs as the searchable resource type by
registering those in the IANA RDAP reverse search registries. registering those in the IANA RDAP reverse search registries.
Because a given extension identifier must correspond to a single Because a given extension identifier must correspond to a single
extension, though, any document making use of IP networks or ASNs as extension, though, any document making use of IP networks or ASNs as
the searchable resource type must also implement the functionality the searchable resource type must also implement the functionality
described in this document. described in this document.
7. Privacy Considerations 7. Operational Considerations
When using a link object for a single-result search, a server may
replace a search URL with a lookup URL, because the behaviour of the
lookup URL is the same as for the search URL as at the time when the
response is generated. One difference between these approaches is
that when using the lookup URL, the server is effectively performing
the search on behalf of the client as at the time of response
generation. If there is no change to the relevant database state
between the time when the original response is generated and the time
when the client resolves the link relation target, then the search
URL and the lookup URL will lead to the same result. However, if
there is a change to the relevant database state, then the lookup URL
may lead to a different result from that of the search URL. Server
operators should consider which type of URL will be more effective
for their clients when implementing this specification.
8. Privacy Considerations
The search functionality defined in this document may affect the The search functionality defined in this document may affect the
privacy of entities in the registry (and elsewhere) in various ways: privacy of entities in the registry (and elsewhere) in various ways:
see [RFC6973] for a general treatment of privacy in protocol see [RFC6973] for a general treatment of privacy in protocol
specifications. Server operators should be aware of the tradeoffs specifications. Server operators should be aware of the tradeoffs
that result from implementation of this functionality. that result from implementation of this functionality.
Many jurisdictions have laws or regulations that restrict the use of Many jurisdictions have laws or regulations that restrict the use of
"Personal Data", per the definition in [RFC6973]. Given that, server "Personal Data", per the definition in [RFC6973]. Given that, server
operators should ascertain whether the regulatory environment in operators should ascertain whether the regulatory environment in
which they operate permits implementation of the functionality which they operate permits implementation of the functionality
defined in this document. defined in this document.
8. Security Considerations 9. Security Considerations
[RFC7481] describes security requirements and considerations for RDAP [RFC7481] describes security requirements and considerations for RDAP
generally. generally.
9. IANA Considerations 10. IANA Considerations
9.1. RDAP Extensions Registry 10.1. RDAP Extensions Registry
IANA is requested to register the following values in the RDAP IANA is requested to register the following values in the RDAP
Extensions Registry: Extensions Registry:
* Extension identifier: rirSearch1 * Extension identifier: rirSearch1
* Registry operator: Any * Registry operator: Any
* Published specification: [this document] * Published specification: [this document]
skipping to change at page 20, line 29 skipping to change at page 20, line 42
* Registry operator: Any * Registry operator: Any
* Published specification: [this document] * Published specification: [this document]
* Contact: IETF <iesg@ietf.org> * Contact: IETF <iesg@ietf.org>
* Intended usage: This extension identifier is used for INR-specific * Intended usage: This extension identifier is used for INR-specific
search operations. search operations.
9.2. Link Relations Registry 10.2. Link Relations Registry
IANA is requested to register the following values in the Link IANA is requested to register the following values in the Link
Relations Registry: Relations Registry:
* Relation Name: up-active * Relation Name: up-active
* Description: Refers to an RDAP parent document that has a status * Description: Refers to an RDAP parent document that has a status
of "active" in a hierarchy of documents. of "active" in a hierarchy of documents.
* Reference: [this document] * Reference: [this document]
skipping to change at page 21, line 21 skipping to change at page 21, line 35
* Reference: [this document] * Reference: [this document]
* Relation Name: bottom * Relation Name: bottom
* Description: Refers to the set of child documents that do not * Description: Refers to the set of child documents that do not
themselves have child documents, in a hierarchy of documents. themselves have child documents, in a hierarchy of documents.
* Reference: [this document] * Reference: [this document]
9.3. RDAP Reverse Search Registry 10.3. RDAP Reverse Search Registry
IANA is requested to register the following entries in the "RDAP IANA is requested to register the following entries in the "RDAP
Reverse Search" registry: Reverse Search" registry:
Searchable Resource Type: ips, autnums Searchable Resource Type: ips, autnums
Related Resource Type: entity Related Resource Type: entity
Property: fn Property: fn
skipping to change at page 22, line 36 skipping to change at page 23, line 5
Description: The server supports the IP/autnum search based on the Description: The server supports the IP/autnum search based on the
role of an associated entity. role of an associated entity.
Registrant Name: IETF Registrant Name: IETF
Registrant Contact Information: iesg@ietf.org Registrant Contact Information: iesg@ietf.org
Reference: This document. Reference: This document.
9.4. RDAP Reverse Search Mapping Registry 10.4. RDAP Reverse Search Mapping Registry
IANA is requested to register the following entries in the "RDAP IANA is requested to register the following entries in the "RDAP
Reverse Search Mapping" registry: Reverse Search Mapping" registry:
Searchable Resource Type: ips, autnums Searchable Resource Type: ips, autnums
Related Resource Type: entity Related Resource Type: entity
Property: fn Property: fn
skipping to change at page 23, line 35 skipping to change at page 24, line 4
Property Path: $..entities[*].vcardArray[1][?(@[0]=='email')][3] Property Path: $..entities[*].vcardArray[1][?(@[0]=='email')][3]
Registrant Name: IETF Registrant Name: IETF
Registrant Contact Information: iesg@ietf.org Registrant Contact Information: iesg@ietf.org
Reference: This document. Reference: This document.
Searchable Resource Type: ips, autnums Searchable Resource Type: ips, autnums
Related Resource Type: entity Related Resource Type: entity
Property: role Property: role
Property Path: $..entities[*].roles Property Path: $..entities[*].roles
Registrant Name: IETF Registrant Name: IETF
Registrant Contact Information: iesg@ietf.org Registrant Contact Information: iesg@ietf.org
Reference: This document. Reference: This document.
10. Implementation Status 11. Implementation Status
| Note to the RFC Editor - remove this section before | Note to the RFC Editor - remove this section before
| publication, as well as the reference to RFC 7942. | publication, as well as the reference to RFC 7942.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
skipping to change at page 24, line 25 skipping to change at page 24, line 41
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
According to [RFC7942], "this will allow reviewers and working groups According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
10.1. APNIC RDAP Implementation 11.1. APNIC RDAP Implementation
* Responsible Organization: Asia-Pacific Network Information Centre * Responsible Organization: Asia-Pacific Network Information Centre
(APNIC) (APNIC)
* Location: https://github.com/APNIC-net/rdap-rmp-demo/tree/rir- * Location: https://github.com/APNIC-net/rdap-rmp-demo/tree/rir-
search search
* Description: This implementation includes support for the various * Description: This implementation includes support for the various
searches and responses described in this document. searches and responses described in this document.
* Level of Maturity: This is a proof-of-concept implementation. * Level of Maturity: This is a proof-of-concept implementation.
* Coverage: This implementation includes all of the features * Coverage: This implementation includes all of the features
described in this specification. described in this specification.
* Contact Information: Tom Harrison, tomh@apnic.net * Contact Information: Tom Harrison, tomh@apnic.net
11. Acknowledgements 11.2. RIPE NCC RDAP Implementation
* Responsible Organization: RIPE NCC
* Location: https://github.com/RIPE-NCC/whois
* Description: This implementation includes support for basic
searches for IP networks and ASNs.
* Level of Maturity: This is a production implementation.
* Coverage: This implementation includes the new basic searches
only.
* Contact Information: Ed Shryane, eshryane@ripe.net
12. Acknowledgements
The authors wish to thank Mario Loffredo, Andy Newton, Antoin The authors wish to thank Mario Loffredo, Andy Newton, Antoin
Verschuren, and James Gould for document review and associated Verschuren, and James Gould for document review and associated
comments. comments.
12. References 13. References
12.1. Normative References 13.1. Normative References
[I-D.ietf-regext-rdap-reverse-search] [I-D.ietf-regext-rdap-reverse-search]
Loffredo, M. and M. Martinelli, "Registration Data Access Loffredo, M. and M. Martinelli, "Registration Data Access
Protocol (RDAP) Reverse Search", Work in Progress, Protocol (RDAP) Reverse Search", Work in Progress,
Internet-Draft, draft-ietf-regext-rdap-reverse-search-26, Internet-Draft, draft-ietf-regext-rdap-reverse-search-26,
13 November 2023, <https://datatracker.ietf.org/doc/html/ 13 November 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-regext-rdap-reverse-search-26>. draft-ietf-regext-rdap-reverse-search-26>.
[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, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 25, line 41 skipping to change at page 26, line 29
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95, Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021, RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>. <https://www.rfc-editor.org/info/rfc9083>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
12.2. Informative References 13.2. Informative References
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95, Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015, RFC 7480, DOI 10.17487/RFC7480, March 2015,
 End of changes. 59 change blocks. 
106 lines changed or deleted 163 lines changed or added

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