RDAP RIR Search

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 IP and ASN-related search options provided by RIRs via their Whois services for which there is no corresponding RDAP functionality. This document extends RDAP to support those search options.¶

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 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.¶

2. Search Path Segment Specification

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 [RFC9082].¶

3. Responding To Searches

As with [RFC9083], 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".¶

4. Link Relations

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:¶

{
  ...
  "links": [
    ...,
    {
      "value": "http://rdap.example.com/ip/192.0.2.0/25",
      "rel": "up",
      "href": "http://rdap.example.com/ip/192.0.2.0/24",
      "type": "application/rdap+json"
    },
    {
      "value": "http://rdap.example.com/ip/192.0.2.0/25",
      "rel": "down",
      "href": "http://rdap.example.com/ip-down/192.0.2.0/25",
      "type": "application/rdap+json"
    }
  ]
}

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.¶

5. Reverse Search

RDAP reverse search is defined by [I-D.ietf-regext-rdap-reverse-search]. 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".¶

6. RDAP Conformance

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.¶

7. Privacy Considerations

The search functionality defined in this document may affect the privacy of entities in the registry (and elsewhere) in various ways: see [RFC6973] 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 [RFC6973]. Given that, registry operators should ascertain whether the regulatory environment in which they operate permits implementation of the functionality defined in this document.¶

8. Security Considerations

[RFC7481] describes security requirements and considerations for RDAP generally.¶

11. References