RDAP RIR Search

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 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 services in this respect, this document defines additional search options for IP networks and autonomous system numbers, along with an additional link relation for finding more-specific resources.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The new resource type path segments for search 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. Search path segments are formed using the same logic as in section 3.2 of .

Syntax: ips?handle=<handle search pattern> Syntax: ips?name=<name search pattern> Searches for IP network information by handle are specified using the form: ips?handle=XXXX XXXX is a search pattern representing an IP network identifier, the syntax for which 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 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-*

Syntax: autnums?handle=<handle search pattern> Syntax: autnums?name=<name search pattern> Searches for autonomous system number information by handle are specified using the form: autnums?handle=XXXX XXXX is a search pattern representing an autonomous system number identifier, the syntax for which 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 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-*

As with , responses to the IP network and autonomous system number searches defined in the previous section take the form of an array of object instances, where each instance is an appropriate object class for the search (i.e., a search for /ips yields an array of IP network object instances, and a search for /autnums yields an array of autonomous system number object instances). These arrays are contained within the response object. The names of the arrays are as follows: for /ips searches, the array is "ipSearchResults"; and for /autnums searches, the array is "autnumSearchResults".

An IP network, autonomous system number, or reverse domain object 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, for a registry with the following four IP network objects: 192.0.2.0/24 192.0.2.0/25 192.0.2.128/25 192.0.2.0/32 the parent object of 192.0.2.0/32 would be 192.0.2.0/25, the parent object of 192.0.2.128/25 would be 192.0.2.0/24, the parent object of 192.0.2.0/25 would be 192.0.2.0/24, and 192.0.2.0/24 would have no parent object. Conversely, the child objects for 192.0.2.0/24 would be 192.0.2.0/25 and 192.0.2.128/25, for 192.0.2.0/25 192.0.2.0/32, and for 192.0.2.128/25 and 192.0.2.0/32 there would be no child objects. In order to permit clients to locate the parent object for a given object, an operator MAY include a link using the "up" link relation that links to the parent object. Similarly, in order to permit clients to locate the child objects for a given object, an operator MAY include a link using the "down" link relation that when resolved, returns a response that has the same format as a search for the relevant object type containing all of the child objects for that object. For example: In the example above, the link target for the link with the "down" relation is "http://rdap.example.com/ip-down/192.0.2.0/25". However, the link structure used by a server for these links is not defined by this specification, and clients MUST NOT make inferences about supported behaviour by inspecting the structure of these links.

RDAP reverse search is defined by . That document limits reverse search to domains, nameservers, and entities. This document extends reverse search to cover IP networks and autonomous system numbers as well, by incorporating the text from section 2 and additionally permitting "searchable-resource-type" to be "ips" or "autnums".

A server that supports all of the functionality specified in this document MUST include the string literal "rir_search" in the rdapConformance array in their response objects.

The search functionality defined in this document may affect the privacy of entities in the registry (and elsewhere) in various ways: see for a general treatment of privacy in protocol specifications. Registry operators should be aware of the tradeoffs that result from implementation of this functionality. Many jurisdictions have laws or regulations that restrict the use of "Personal Data", per the definition in . Given that, registry operators should ascertain whether the regulatory environment in which they operate permits implementation of the functionality defined in this document.

describes security requirements and considerations for RDAP generally.

IANA is requested to register the following value in the RDAP Extensions Registry: Extension identifier: rir_search Registry operator: Any Published specification: [this document] Contact: IETF <iesg@ietf.org> Intended usage: This extension identifier is used for RIR-specific search operations. IANA is also requested to register the following value in the Link Relations Registry: Relation Name: down Description: Refers to a set of child documents in a hierarchy of documents. Reference: [this document]

TBD