Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search

T. Harrison; J. Singh

doi:10.17487/RFC9910

RFC 9910: Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search

T. Harrison,
J. Singh

Proposed Standard

Abstract

The Registration Data Access Protocol (RDAP) is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but there are various search options related to IP addresses, IP prefixes, and Autonomous System Numbers (ASNs), which are provided by RIRs via their WHOIS services, but for which there is no corresponding RDAP functionality. This document extends RDAP to support those search options.¶

Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9910.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

1. Introduction

The Registration Data Access Protocol (RDAP) [RFC7480] is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but this is limited to domains, nameservers, and entities. No searches were defined for IP networks or autonomous system numbers. In an effort to have RDAP reach feature parity with the existing RIR WHOIS [RFC3912] services in this respect, this document defines additional search options for IP networks and autonomous system numbers.¶

While this document is written in terms of RIRs and DNRs for the sake of consistency with earlier RDAP documents such as [RFC9082] and [RFC9083], the functionality described here may be used by any RDAP server operator that hosts Internet Number Resource (INR) objects.¶

1.1. Conventions Used in This Document

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Indentation and whitespace in examples are provided only to illustrate element relationships and are not required features of this specification.¶

"..." in examples is used as shorthand for elements defined outside of this document, as well as to abbreviate elements that are too long.¶

2. Basic Searches

2.1. Path Segments

The new resource type path segments for basic search (similar to the searches defined in [RFC9082] and [RFC9083]) are:¶

'ips':: Used to identify an IP network search using a pattern to match one of a set of IP network attributes.¶
'autnums':: Used to identify an autonomous system number search using a pattern to match one of a set of autonomous system number attributes.¶

A search pattern matches a value where it equals the string representation of the value, or where it is a match for the value in accordance with the use of the asterisk ('*', ASCII value 0x2A) character for partial string matching as defined in Section 4.1 of [RFC9082]. For most searches, '*' may be used to match trailing characters only, and may appear in a search only once: see the previously mentioned section for a complete definition of the relevant behaviour.¶

Section 4.1 of [RFC9082] describes the use of a trailing domain label suffix in a partial string search. It is not necessary that servers support this type of search pattern for the basic searches defined in this document, since those searches do not relate to domain name members.¶

2.2. IP Network Search

Syntax:: ips?handle=<handle search pattern>¶
Syntax:: ips?name=<name search pattern>¶

Searches for IP network (see Section 5.4 of [RFC9083]) information by handle are specified using the form:¶

ips?handle=XXXX¶

XXXX is a search pattern representing an IP network identifier whose syntax is specific to the registration provider. The following URL would be used to find information for IP networks with handles matching the "NET-199*" pattern:¶

https://example.com/rdap/ips?handle=NET-199*¶

Searches for IP network (see Section 5.4 of [RFC9083]) information by name are specified using the form:¶

ips?name=XXXX¶

XXXX is a search pattern representing an IP network identifier that is assigned to the network registration by the registration holder. The following URL would be used to find information for IP networks with names matching the "NET-EXAMPLE-*" pattern:¶

https://example.com/rdap/ips?name=NET-EXAMPLE-*¶

2.3. Autonomous System Number Search

Syntax:: autnums?handle=<handle search pattern>¶
Syntax:: autnums?name=<name search pattern>¶

Searches for autonomous system number (see Section 5.5 of [RFC9083]) information by handle are specified using the form:¶

autnums?handle=XXXX¶

XXXX is a search pattern representing an autonomous system number identifier whose syntax is specific to the registration provider. The following URL would be used to find information for autonomous system numbers with handles matching the "AS1*" pattern:¶

https://example.com/rdap/autnums?handle=AS1*¶

Searches for autonomous system number (see Section 5.5 of [RFC9083]) information by name are specified using the form:¶

autnums?name=XXXX¶

XXXX is a search pattern representing an autonomous system number identifier that is assigned to the autonomous system number registration by the registration holder. The following URL would be used to find information for autonomous system numbers with names matching the "ASN-EXAMPLE-*" pattern:¶

https://example.com/rdap/autnums?name=ASN-EXAMPLE-*¶

3. Relation Searches

This section defines searches and link relations for finding objects and sets of objects with respect to their position within a hierarchy.¶

3.1. Path Segments

The variables used in the path segments in this section include:¶

<relation>:: a relation type, as defined in Section 3.2.2 of this document.¶
<IP address>:: an IP address, as defined in Section 3.1.1 of [RFC9082].¶
<CIDR prefix>:: the first address of a Classless Inter-Domain Routing (CIDR) block, as defined in Section 3.1.1 of [RFC9082].¶
<CIDR length>:: the prefix length for a CIDR block, as defined in Section 3.1.1 of [RFC9082].¶
<domain name>:: a fully qualified domain name, as defined in Section 3.1.3 of [RFC9082].¶
<autonomous system number or range>:: an autonomous system number, as defined in Section 3.1.2 of [RFC9082], or two such numbers separated by a single hyphen ('-', ASCII value 0x2D), where the second number is greater than the first.¶
<resource type search path segment>:: a search path segment corresponding to an Internet Number Resource (INR) object class (i.e., an IP network address or range, autonomous system number or number range, or reverse domain name).¶
<object value>:: a value used to identify an object for the purposes of a relation search relative to that object. One of <IP address>, <CIDR prefix> and <CIDR length> pair, <domain name>, or <autonomous system number or range>, depending on the type of search that is being performed.¶
<status>:: an object status value, as defined in Section 4.6 of [RFC9083].¶

The new resource type path segments for relation search (similar to the searches defined in [RFC9082] and [RFC9083]) are:¶

'ips/rirSearch1/<relation>/<IP address>':: Used to identify an IP network search using a relation and an IP address to match a set of IP networks.¶
'ips/rirSearch1/<relation>/<CIDR prefix>/<CIDR length>':: Used to identify an IP network search using a relation and an IP address range to match a set of IP networks.¶
'autnums/rirSearch1/<relation>/<autonomous system number or range>':: Used to identify an autonomous system number search using a relation and a single ASN or an ASN range to match a set of ASN objects.¶
'domains/rirSearch1/<relation>/<domain name>':: Used to identify a reverse domain search using a relation and a reverse domain name to match a set of reverse domains.¶

3.2. Relation Search

Syntax:: <resource type search path segment>/rirSearch1/<relation>/<object value>[?status=<status>]¶

The relation searches defined in this document rely on the syntax described above. Each search works in the same way for each object class.¶

The rirSearch1 path segment is used in the relation search URLs in order to provide a single namespace for those searches, and so that other searches can be defined underneath the top-level resource type search path segments.¶

3.2.1. Definitions

An INR object value may have a "parent" object and one or more "child" objects. The "parent" object is the next-least-specific object that exists in the relevant registry, while the "child" objects are the next-most-specific objects that exist in the relevant registry. For example, let's say there is a registry with the following IP network objects:¶

                        +--------------+
                        | 192.0.2.0/24 |
                        +--------------+
                           /        \
              +--------------+    +----------------+
              | 192.0.2.0/25 |    | 192.0.2.128/25 |
              +--------------+    +----------------+
                 /                   /          \
     +--------------+   +----------------+  +----------------+
     | 192.0.2.0/28 |   | 192.0.2.128/26 |  | 192.0.2.192/26 |
     +--------------+   +----------------+  +----------------+
        /
 +--------------+
 | 192.0.2.0/32 |
 +--------------+

Figure 1: Example Registry Objects

For this example registry, the INR object value to parent/child object relationships are:¶

Table 1: Parent Objects
INR object value	Parent object
192.0.2.0/32	192.0.2.0/28
192.0.2.0/28	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.192/26	192.0.2.128/25
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

Table 2: 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/25	192.0.2.0/28
192.0.2.128/25	192.0.2.128/26, 192.0.2.192/26
192.0.2.64/26	N/A
192.0.2.128/26	N/A
192.0.2.192/26	N/A
192.0.2.0/28	192.0.2.0/32
192.0.2.0/32	N/A

(INR object values do not necessarily correspond to registry objects, because users can provide arbitrary object values as input to the searches defined in this document.)¶

Similarly to the parent/child object relationships, each INR object value may have a "top" object, being the least-specific covering 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 above, the top and bottom object relationships are:¶

Table 3: Top Objects
INR object value	Top object
192.0.2.0/32	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.128/26	192.0.2.0/24
192.0.2.192/26	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

Table 4: 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.128/26, 192.0.2.192/26
192.0.2.0/25	192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32
192.0.2.128/25	192.0.2.128/26, 192.0.2.192/26
192.0.2.64/26	N/A
192.0.2.128/26	N/A
192.0.2.192/26	N/A
192.0.2.0/28	192.0.2.0/28, 192.0.2.0/32
192.0.2.0/31	192.0.2.0/28, 192.0.2.0/32
192.0.2.0/32	N/A

If there are no more-specific objects for a given INR object value, then the set of bottom objects for that INR object value will be empty. 192.0.2.0/32 is an example of such an INR object value.¶

It is not necessarily the case that the bottom objects for a given INR object value will be disjoint. For example, 192.0.2.0/28's bottom objects are 192.0.2.0/28 and 192.0.2.0/32. 192.0.2.0/32 is included because it is one of the most-specific objects (i.e., an object at the bottom of the object hierarchy) for 192.0.2.0/28, while 192.0.2.0/28 itself is included because it is the most-specific object for the other addresses within the range (i.e., those aside from 192.0.2.0/32).