Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search Asia Pacific Network Information Centre
6 Cordelia St South Brisbane 4101 Australia QLD tomh@apnic.net
American Registry for Internet Numbers
PO Box 232290 Centreville VA 20120 United States of America jasdips@arin.net
ART regext RDAP 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 .
Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () 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.
Table of Contents
  • .  Introduction
    • .  Conventions Used in This Document
  • .  Basic Searches
    • .  Path Segments
    • .  IP Network Search
    • .  Autonomous System Number Search
  • .  Relation Searches
    • .  Path Segments
    • .  Relation Search
      • .  Definitions
      • .  Relations
        • .  Single-Result Searches
        • .  Multiple-Result Searches
    • .  Status
    • .  Link Relations
  • .  Responding to Searches
    • .  Single-Result Searches
    • .  Multiple-Result Searches
  • .  Reverse Search
  • .  RDAP Conformance
  • .  Operational Considerations
  • .  Privacy Considerations
  • .  Security Considerations
  • . IANA Considerations
    • .  RDAP Extensions Registry
      • .  rirSearch1
      • .  ips
      • .  autnums
      • .  ipSearchResults
      • .  autnumSearchResults
    • .  Link Relations Registry
      • .  rdap-up
      • .  rdap-down
      • .  rdap-top
      • .  rdap-bottom
      • .  rdap-active
    • .  RDAP Reverse Search Registry
      • .  fn
      • .  handle
      • .  email
      • .  role
    • .  RDAP Reverse Search Mapping Registry
      • .  fn
      • .  handle
      • .  email
      • .  role
  • . References
    • .  Normative References
    • .  Informative References
  • Acknowledgements
  • Authors' Addresses
Introduction 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. While this document is written in terms of RIRs and DNRs for the sake of consistency with earlier RDAP documents such as and , the functionality described here may be used by any RDAP server operator that hosts Internet Number Resource (INR) objects.
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 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.
Basic Searches
Path Segments The new resource type path segments for basic search (similar to the searches defined in and ) 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 . 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. 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.
IP Network Search
Syntax:
ips?handle=<handle search pattern>
Syntax:
ips?name=<name search pattern>
Searches for IP network (see ) 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 ) 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-*
Autonomous System Number Search
Syntax:
autnums?handle=<handle search pattern>
Syntax:
autnums?name=<name search pattern>
Searches for autonomous system number (see ) 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 ) 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-*
Relation Searches This section defines searches and link relations for finding objects and sets of objects with respect to their position within a hierarchy.
Path Segments The variables used in the path segments in this section include:
<relation>:
a relation type, as defined in of this document.
<IP address>:
an IP address, as defined in .
<CIDR prefix>:
the first address of a Classless Inter-Domain Routing (CIDR) block, as defined in .
<CIDR length>:
the prefix length for a CIDR block, as defined in .
<domain name>:
a fully qualified domain name, as defined in .
<autonomous system number or range>:
an autonomous system number, as defined in , 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 .
The new resource type path segments for relation search (similar to the searches defined in and ) 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.
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.
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:
Example Registry 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 | +--------------+
For this example registry, the INR object value to parent/child object relationships are: 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
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: 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
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). The bottom objects for a given INR object value may include an object 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, 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 (i.e., 192.0.2.1/32) is 192.0.2.0/28, so it is included in the results as well.
Relations
Single-Result Searches
"rdap-up" If the server receives a search containing the relation value "rdap-up", it will return the parent 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) status code.
"rdap-top" If the server receives a search containing the relation value "rdap-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) status code.
Multiple-Result Searches
"rdap-down" If the server receives a search containing the relation value "rdap-down", it will return the child objects for the specified INR object value. If no such objects exist, it will return an empty search response. Per the definitions section, this includes only immediate child objects.
"rdap-bottom" If the server receives a search containing the relation value "rdap-bottom", it will return the bottom objects for the specified INR object value. If no such objects exist, it will return an empty search response.
Status If the "status" argument is provided, then response processing will proceed as though all objects without the specified status had first been removed from the database. For example, if the registry objects from had the following statuses: Statuses
Object Status
192.0.2.0/25 active
192.0.2.128/25 inactive
192.0.2.128/26 active
192.0.2.192/26 active
then a server receiving a "rdap-down" search request with the INR object 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. 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 the "rdap-top" relation with a "status" of "active", the delegation from IANA to the RIR will be ignored, and the client will receive the delegation from the RIR to the account holder in the response instead. By default, any valid status value may be used for status filtering. Server operators MAY opt not to support "status" filtering for the "rdap-down" and "rdap-bottom" link relations, in which case the server responds with an HTTP 501 (Not Implemented) response code if it receives such a request. Server operators MAY also opt not to support "status" filtering for values other than "active" for the "rdap-up" and "rdap-top" link relations, in which case the server responds with an HTTP 501 (Not Implemented) response code if it receives such a request. While any valid status value may be used for status filtering, a given RDAP server may make use of only a small number of those status values for INR objects. For example, a status value like "client hold" would typically only be used by a DNR for a forward domain name object.
Link Relations Each of the relations defined in has a corresponding link relation that can be used for a link object contained within another RDAP object. When constructing these link objects, the server MUST use the corresponding search URL for the link target, or a URL that yields the same response as for the corresponding search as at the time of the request. The following is an elided example of an IPv4 response that makes use of those link relations:
Example Links in an IPv4 Response { "startAddress": "192.0.2.0", "endAddress": "192.0.2.127", ... "links": [ ..., { "value": "https://example.com/rdap/ip/192.0.2.0/25", "rel": "rdap-up", "href": ".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25", "type": "application/rdap+json" }, { "value": "https://example.com/rdap/ip/192.0.2.0/25", "rel": "rdap-down", "href": ".../rdap/ips/rirSearch1/rdap-down/192.0.2.0/25", "type": "application/rdap+json" }, { "value": "https://example.com/rdap/ip/192.0.2.0/25", "rel": "rdap-top", "href": ".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25", "type": "application/rdap+json" }, { "value": "https://example.com/rdap/ip/192.0.2.0/25", "rel": "rdap-bottom", "href": ".../rdap/ips/rirSearch1/rdap-bottom/192.0.2.0/25", "type": "application/rdap+json" } ] }
The following is an elided example of an IPv6 response that makes use of the link relations:
Example Links in an IPv6 Response { "startAddress": "2001:db8:a::", "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff", ... "links": [ ..., { "value": "https://example.com/rdap/ip/2001:db8:a::/48", "rel": "rdap-up", "href": ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48", "type": "application/rdap+json" }, { "value": "https://example.com/rdap/ip/2001:db8:a::/48", "rel": "rdap-down", "href": ".../rdap/ips/rirSearch1/rdap-down/2001:db8:a::/48", "type": "application/rdap+json" }, { "value": "https://example.com/rdap/ip/2001:db8:a::/48", "rel": "rdap-top", "href": ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48", "type": "application/rdap+json" }, { "value": "https://example.com/rdap/ip/2001:db8:a::/48", "rel": "rdap-bottom", "href": ".../rdap/ips/rirSearch1/rdap-bottom/2001:db8:a::/48", "type": "application/rdap+json" } ] }
One additional link relation, "rdap-active", is defined for denoting a search with a "status" of "active". No other status link relations are defined because the only known use cases for status filtering involve the "rdap-up" and "rdap-top" relations and the "active" status. The following is an elided example of an IPv4 response that makes use of those link relations:
Example Status Links in an IPv4 Response { "startAddress": "192.0.2.0", "endAddress": "192.0.2.127", ... "links": [ ..., { "value": "https://example.com/rdap/ip/192.0.2.0/25", "rel": "rdap-up rdap-active", "href": ".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25?status=active", "type": "application/rdap+json" }, { "value": "https://example.com/rdap/ip/192.0.2.0/25", "rel": "rdap-top rdap-active", "href": ".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25?status=active", "type": "application/rdap+json" } ] }
The following is an elided example of an IPv6 response that makes use of the link relations:
Example Status Links in an IPv6 Response { "startAddress": "2001:db8:a::", "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff", ... "links": [ ..., { "value": "https://example.com/rdap/ip/2001:db8:a::/48", "rel": "rdap-up rdap-active", "href": ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active", "type": "application/rdap+json" }, { "value": "https://example.com/rdap/ip/2001:db8:a::/48", "rel": "rdap-top rdap-active", "href": ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active", "type": "application/rdap+json" } ] }
"rdap-active" is used only as a link relation in a link object. It cannot be used as a value for <relation> in the relation search URL defined in . details status filtering for relation search URLs. Since the "rdap-top" and "rdap-up" link relations resolve either to a single object or to an HTTP 404 (Not Found) response, it is possible for a server to use a lookup URL (see ) in the "href" attribute in the link object. The following is an elided example of an IPv4 response that uses this approach:
Example Single-Result Links in an IPv4 Response { "startAddress": "192.0.2.0", "endAddress": "192.0.2.127", ... "links": [ ..., { "value": "https://example.com/rdap/ip/192.0.2.0/25", "rel": "rdap-up", "href": "https://example.com/rdap/ip/192.0.2.0/24", "type": "application/rdap+json" } ] }
The following is an elided example of an IPv6 response that makes use of the approach:
Example Single-Result Links in an IPv6 Response { "startAddress": "2001:db8:a::", "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff", ... "links": [ ..., { "value": "https://example.com/rdap/ip/2001:db8:a::/48", "rel": "rdap-up", "href": "https://example.com/rdap/ip/2001:db8::/32", "type": "application/rdap+json" } ] }
Use of these link relations in responses is OPTIONAL. The absence in a response of a link for a specific relation does not necessarily mean that the corresponding search will return no results.
Responding to Searches
Single-Result Searches The "rdap-up" and "rdap-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 ). If there is no result for the search, the server returns an HTTP 404 (Not Found) response code.
Multiple-Result Searches The "rdap-down" and "rdap-bottom" relations are multiple-result searches. As with , responses for these searches take the form of an array of object instances, where each instance is an appropriate object class for the search (i.e., a search beginning with /ips yields an array of IP network object instances, and a search beginning with /autnums yields an array of autonomous system number object instances). The IP network object class is defined in , and the autonomous system number object class is defined in . The object instance 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".
The following is an elided example of a response for an IPv4 network search:
IPv4 Network Search Response { "rdapConformance": [ "rdap_level_0", "rirSearch1", "ips", "ipSearchResults", ... ], ... "ipSearchResults": [ { "objectClassName": "ip network", "handle": "XXXX-RIR", "startAddress": "192.0.2.0", "endAddress": "192.0.2.127", ... }, { "objectClassName": "ip network", "handle": "YYYY-RIR", "startAddress": "192.0.2.0", "endAddress": "192.0.2.255", ... } ] }
The following is an elided example of a response for an IPv6 network search:
IPv6 Network Search Response { "rdapConformance": [ "rdap_level_0", "rirSearch1", "ips", "ipSearchResults", ... ], ... "ipSearchResults": [ { "objectClassName": "ip network", "handle": "XXXX-RIR", "startAddress": "2001:db8:a::", "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff", ... }, { "objectClassName": "ip network", "handle": "YYYY-RIR", "startAddress": "2001:db8::", "endAddress": "2001:db8:ffff:ffff:ffff:ffff:ffff:ffff", ... } ] }
The following is an elided example of a response to an autonomous system number search:
ASN Search Response { "rdapConformance": [ "rdap_level_0", "rirSearch1", "autnums", "autnumSearchResults", ... ], ... "autnumSearchResults": [ { "objectClassName": "autnum", "handle": "XXXX-RIR", "startAutnum": 64496, "endAutnum": 64496, ... }, { "objectClassName": "autnum", "handle": "YYYY-RIR", "startAutnum": "64497", "endAutnum": "64497", ... } ] }
Responses for relation searches for reverse domain objects have the same form as for a standard domain search response, per . If the search can be processed by the server, but there are no results for the search, then the server returns an HTTP 404 (Not Found) response code, with the body of the response containing an empty results array.
Reverse Search 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. If a server receives a reverse search query with a searchable resource type (per the definition of that term in ) 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, notes that new registrations for IP network and autonomous system number searches have been made in the "RDAP Reverse Search" and "RDAP Reverse Search Mapping" IANA registries.
RDAP Conformance A server that supports the functionality specified in this document MUST include additional string literals in the rdapConformance array of its responses, in accordance with the following:
  • any response that includes an IP network basic search link, an IP network relation search link, or an IP network reverse search link includes the "rirSearch1" and "ips" literals;
  • any response for an IP network basic search request, an IP network relation search request, or an IP network reverse search request includes the "rirSearch1", "ips", and "ipSearchResults" literals;
  • any response that includes an ASN basic search link, an ASN relation search link, or an ASN reverse search link includes the "rirSearch1" and "autnums" literals;
  • any response for an ASN basic search request, an ASN relation search request, or an ASN reverse search request includes the "rirSearch1", "autnums", and "autnumSearchResults" literals;
  • any response that includes a domain relation search link includes the "rirSearch1" literal;
  • any response for a domain relation search request includes the "rirSearch1" literal; and
  • a response to a "/help" request includes the "rirSearch1", "ips", "ipSearchResults", "autnums", and "autnumSearchResults" literals.
Although responses will generally not include all of the rdapConformance string literals defined in this document, that is not meant to imply that a server can support only a portion of the functionality defined in this document. The "ips", "autnums", "ipSearchResults", and "autnumSearchResults" extension identifiers are included here due to the requirements and recommendations set out in , , and . These requirements and recommendations are such that an RDAP extension identifier be used as a prefix in new path segments and JSON members introduced by the extension, and those strings are used as such as part of the basic searches defined in this document. Furthermore, using these strings as path segments helps to increase consistency among the basic searches for the core RDAP object classes. As with the other core object classes (entity, domain, and nameserver), other documents may define additional reverse searches with IP networks and ASNs as the searchable resource type by registering those in the IANA RDAP reverse search registries. Because a given extension identifier must correspond to a single extension, though, any document making use of IP networks or ASNs as the searchable resource type must also implement the functionality described in this document. The "1" in "rirSearch1" denotes that this is version 1 of the RIR search extension. New versions of the RIR search extension will use different extension identifiers. A version suffix is not used for the remaining identifiers defined by this document, partly because such a suffix would reduce consistency with the corresponding functionality for the other core object classes, and partly because it is very unlikely that the functionality associated with those identifiers will change.
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 that of the search URL at the time 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. Where this document includes HTTP reason phrases, that is purely for the benefit of the reader and is not an indication that those phrases need to be used as-is in responses.
Privacy Considerations 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, and for specific discussion about privacy threats with respect to the registration data provided by RDAP. Server 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, server operators should ascertain whether the regulatory environment in which they operate permits implementation of the functionality defined in this document.
Security Considerations describes security requirements and considerations for RDAP generally. Additionally, guidance as to the use of TLS has changed since that document was published: see and for further detail. includes security considerations relating to object retrieval in RDAP. Those considerations are relevant here as well.
IANA Considerations
RDAP Extensions Registry IANA has registered the following values in the "RDAP Extensions" registry.
rirSearch1
Extension Identifier:
rirSearch1
Registry operator:
Any
Specification:
RFC 9910
Contact:
IETF <iesg@ietf.org>
Intended Usage:
This extension identifier is used for INR-specific search operations.
ips
Extension Identifier:
ips
Registry operator:
Any
Specification:
RFC 9910
Contact:
IETF <iesg@ietf.org>
Intended Usage:
This extension identifier is used for INR-specific search operations.
autnums
Extension Identifier:
autnums
Registry operator:
Any
Specification:
RFC 9910
Contact:
IETF <iesg@ietf.org>
Intended Usage:
This extension identifier is used for INR-specific search operations.
ipSearchResults
Extension Identifier:
ipSearchResults
Registry operator:
Any
Specification:
RFC 9910
Contact:
IETF <iesg@ietf.org>
Intended Usage:
This extension identifier is used for INR-specific search operations.
autnumSearchResults
Extension Identifier:
autnumSearchResults
Registry operator:
Any
Specification:
RFC 9910
Contact:
IETF <iesg@ietf.org>
Intended Usage:
This extension identifier is used for INR-specific search operations.
Link Relations Registry IANA has registered the following values in the "Link Relations" registry.
rdap-up
Relation Name:
rdap-up
Description:
Refers to an RDAP parent object in a hierarchy of objects.
Reference:
RFC 9910
rdap-down
Relation Name:
rdap-down
Description:
Refers to a set of RDAP child objects in a hierarchy of objects.
Reference:
RFC 9910
rdap-top
Relation Name:
rdap-top
Description:
Refers to the topmost RDAP parent object in a hierarchy of objects.
Reference:
RFC 9910
rdap-bottom
Relation Name:
rdap-bottom
Description:
Refers to the set of child RDAP objects that do not themselves have child objects, in a hierarchy of objects.
Reference:
RFC 9910
rdap-active
Relation Name:
rdap-active
Description:
The target is for an RDAP RIR search that filters for the status "active".
Reference:
RFC 9910
RDAP Reverse Search Registry IANA has registered the following entries in the "RDAP Reverse Search" registry.
fn
Property:
fn
Description:
The server supports the IP/autnum search based on the full name (a.k.a. formatted name) of an associated entity.
Searchable Resource Type:
ips, autnums
Related Resource Type:
entity
Registrant:
IETF
Contact Information:
iesg@ietf.org
Reference:
RFC 9910
handle
Property:
handle
Description:
The server supports the IP/autnum search based on the handle of an associated entity.
Searchable Resource Type:
ips, autnums
Related Resource Type:
entity
Registrant:
IETF
Contact Information:
iesg@ietf.org
Reference:
RFC 9910
email
Property:
email
Description:
The server supports the IP/autnum search based on the email address of an associated entity.
Searchable Resource Type:
ips, autnums
Related Resource Type:
entity
Registrant:
IETF
Contact Information:
iesg@ietf.org
Reference:
RFC 9910
role
Property:
role
Description:
The server supports the IP/autnum search based on the role of an associated entity.
Searchable Resource Type:
ips, autnums
Related Resource Type:
entity
Registrant:
IETF
Contact Information:
iesg@ietf.org
Reference:
RFC 9910
RDAP Reverse Search Mapping Registry IANA has registered the following entries in the "RDAP Reverse Search Mapping" registry.
fn
Property:
fn
Property Path:
$.entities[*].vcardArray[1][?(@[0]=='fn')][3]
Searchable Resource Type:
ips, autnums
Related Resource Type:
entity
Registrant:
IETF
Contact Information:
iesg@ietf.org
Reference:
RFC 9910
handle
Property:
handle
Property Path:
$.entities[*].handle
Searchable Resource Type:
ips, autnums
Related Resource Type:
entity
Registrant:
IETF
Contact Information:
iesg@ietf.org
Reference:
RFC 9910
email
Property:
email
Property Path:
$.entities[*].vcardArray[1][?(@[0]=='email')][3]
Searchable Resource Type:
ips, autnums
Related Resource Type:
entity
Registrant:
IETF
Contact Information:
iesg@ietf.org
Reference:
RFC 9910
role
Property:
role
Property Path:
$.entities[*].roles
Searchable Resource Type:
ips, autnums
Related Resource Type:
entity
Registrant:
IETF
Contact Information:
iesg@ietf.org
Reference:
RFC 9910
 References Normative References Deprecating TLS 1.0 and TLS 1.1 This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1. This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Security Services for the Registration Data Access Protocol (RDAP) The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Registration Data Access Protocol (RDAP) Query Format This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482. JSON Responses for the Registration Data Access Protocol (RDAP) This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Registration Data Access Protocol (RDAP) Reverse Search The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case. Informative References WHOIS Protocol Specification This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS-TRACK] Privacy Considerations for Internet Protocols This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. HTTP Usage in the Registration Data Access Protocol (RDAP) This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application.
Acknowledgements The authors wish to thank , , , , , , , , , , , , , and for document review and associated comments.
Authors' Addresses Asia Pacific Network Information Centre
6 Cordelia St South Brisbane 4101 Australia QLD tomh@apnic.net
American Registry for Internet Numbers
PO Box 232290 Centreville VA 20120 United States of America jasdips@arin.net