RDAP RIR Search

Abstract

The Registration Data Access Protocol (RDAP) is used by Internet Number Resource (INR) registries and domain name registries 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 INR registries 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 Internet Number Resource (INR) registries and domain name registries 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 INR 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 includes 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 includes 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.¶

An operator MUST NOT include a link with an "up" link relation in an object if that object has no parent object. Similarly, an operator MUST NOT include a link with a "down" link relation in an object if that object has no child objects. This permits clients to rely on the absence of a given link relation as determinative of the question whether the object has any related objects of that type.¶

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

If a server receives a reverse search query with a searchable resource type (per the definition of that term in [I-D.ietf-regext-rdap-reverse-search]) of "ips", then the reverse search will be performed on the IP network objects from its data store. Similarly, if a server receives a reverse search query with a searchable resource type of "autnums", then the reverse search will be performed on the autonomous system number objects from its data store.¶

Additionally, Section 9 includes requests to register new entries for IP network and autonomous system number searches in the RDAP Reverse Search and RDAP Reverse Search Mapping IANA registries.¶

6. RDAP Conformance

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

[RFC7480], [RFC9082] and [RFC9083] collectively require that an RDAP extension identifier be used as a prefix in new path segments and response object members that are introduced by the extension. Because IP network objects and autonomous system number objects are part of the original set of object types defined for use in RDAP, it may be unintuitive or confusing for users if the searches and associated responses defined here include the "inr_search" extension prefix, since the searches and associated responses for the other original object types do not include a prefix. Therefore, the extension identifier is not used as a prefix in this document. Since this is not in keeping with the requirements of those earlier documents, this document is marked as updating those documents.¶

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