]> RIPE NCC

maggarwal@ripe.net

ARIN

jasdips@arin.net

ICANN

andy@hxr.us

Reliably Coded

sasha@reliablycoded.nl

Operations and Management Internet Engineering Task Force RDAP IRR RPSL 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 core object types, but they do not contain objects for the Internet Routing Registry (IRR). This document is intended to address this gap. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the regext Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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 core object types, but they do not contain objects for the Internet Routing Registry (IRR). The IRR consists of several IRR Databases containing objects in the Routing Policy Specification Language (RPSL) , such as route origins, sets of routes and autonomous systems, and routing policies. Network operators use this data to configure route filters, among other things. IRR Databases are commonly queried with the WHOIS protocol , which returns RPSL text. Several RIRs operate IRR Databases alongside their registration databases, and already provide their other registration data through RDAP. Serving IRR objects through RDAP lets clients use one protocol for both, and relate IRR objects to the IP networks and autonomous system numbers they refer to. This document defines RDAP object classes and lookups for IRR objects, so that IRR data is available in the same structured JSON format and over the same HTTPS transport as other RDAP data.

Conventions and Definitions 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 a required feature 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. To keep the examples short, entities in them only include the "objectClassName", "handle", and "roles" members.

Extension This document defines a new RDAP extension with identifier "irr0", for accessing Internet Routing Registry (IRR) data through RDAP. This extension adheres to the guidelines in . New versions of this extension will use different extension identifiers.

Lookup Path Segment specification defines the simple lookup path segments for types: "ip", "autnum", "domain", "nameserver", and "entity". This document aims to extend this to add following path segments: "irr0_route" -- Used to identify ROUTE object and associated IP address prefix and the autonomous system (AS) that originates it "irr0_routeSet" -- Used to identify route-set object "irr0_autnumSet" -- Used to identify as-set object "irr0_rtrSet" -- Defines the name of the rtr-set "irr0_peeringSet" -- Specifies the name of the peering-set "irr0_filterSet" -- Defines the name of the filter

The Route Object Class It is the RDAP representation of the RPSL route class defined in Syntax: irr0_route/< IP prefix of the interAS route >/< AS that originates the route > For example, the following URL would be used to find information describing route object

The route object class can contain the following members: "objectClassName" -- the string "irr0_route" "handle" -- a string representing the registry-unique identifier of the route object "route" -- a string representing the address-prefix for which a route is referenced; as per "origin" -- a string representing an autonomous system number for which a route is referenced; as per "routeVersion" -- a string signifying the ip protocol version of the network: "v4" signifies an route with ipv4 network, and "v6" signifies a route with ipv6 network "remarks" -- see "pingable" -- an array of strings each containing a value as specified in "holes" -- an array of strings each containing a value as specified in "member-of" -- an array of strings, each containing a value as specified in "inject" -- an array of strings, each containing a value as specified in "components" -- a string containing a value as specified in "aggregateBoundary" -- a string containing a value as specified in "aggregateMtd" -- a string containing a value as specified in "exportComps" -- a string containing a value as specified in "entities" -- an array of entity objects as defined by "links" -- see "port43" -- see "events" -- see The following is an example of the JSON object

The SET Object Class defines SET objects. This section aims to represent SET classes in RDAP representation. Support for peering-set, rtr-set and filter-set is optional and may be provided at the discretion of the implementation.

Route Set Object Class It is the RDAP representation of the RPSL route-set class defined in Syntax: irr0_routeSet/< name of the route set > For example, the following URL would be used to find information describing route-set object

The routeSet object class can contain the following members: "objectClassName" -- the string "irr0_routeSet" "handle" -- a string representing the registry-unique identifier of the routeSet object. "members" -- an array of strings, each containing a value as specified in "mp-members" -- an array of strings, each containing a value as specified in "remarks" -- see "entities" -- an array of entity objects as defined by "links" -- see "port43" -- see "events" -- see The following is an example of a routeSet that might be served by an RIR.

Autnum Set Object Class It is the RDAP representation of the RPSL autnum-set class defined in Syntax: irr0_autnumSet/< name of the as-set > For example, the following URL would be used to find information describing autnum-set object

The autnumSet object class can contain the following members: "objectClassName" -- the string "irr0_autnumSet" "handle" -- a string representing the registry-unique identifier of the autnumSet object. "members" -- an array of strings, each containing a value as specified in "remarks" -- see "entities" -- an array of entity objects as defined by "links" -- see "port43" -- see "events" -- see The following is an example of an autnumSet that might be served by an RIR.

RTR Set Object Class It is the RDAP representation of the RPSL rtr-set class defined in Syntax: irr0_rtrSet/< name of the router-set > For example, the following URL would be used to find information describing rtrSet object

The rtrSet set object class can contain the following members: "objectClassName" -- the string "irr0_rtrSet" "handle" -- a string representing the registry-unique identifier of the rtrSet. "members" -- an array of strings, each containing a value as specified in "mp-members" -- an array of strings, each containing a value as specified in "remarks" -- see "entities" -- an array of entity objects as defined by "links" -- see "port43" -- see "events" -- see The following is an example of rtrSet that might be served by an RIR.

Peering Set Object Class It is the RDAP representation of the RPSL peering-set class defined in Syntax: irr0_peeringSet/< name of the peering-set > For example, the following URL would be used to find information describing peering-set object

The peeringSet object class can contain the following members: "objectClassName" -- the string "irr0_peeringSet" "handle" -- a string representing the registry-unique identifier of the peeringSet "peering" -- an array of strings, each containing a value as specified in "mp-peering" -- an array of strings, each containing a value as specified in "remarks" -- see "entities" -- an array of entity objects as defined by "links" -- see "port43" -- see "events" -- see The following is an example of peeringSet that might be served by an RIR.

Filter Set Object Class It is the RDAP representation of the RPSL filter-set class defined in Syntax: irr0_filterSet/< name of the filter > For example, the following URL would be used to find information describing filter object

The filterSet object class can contain the following members: "objectClassName" -- the string "irr0_filterSet" "handle" -- a string representing the registry-unique identifier of the filterSet "filter" -- an array of strings each defines the set's policy filter as per "mp-filter" -- an array of strings, each containing a value as specified in "remarks" -- see "entities" -- an array of entity objects as defined by "links" -- see "port43" -- see "events" -- see The following is an example of filterSet that might be served by an RIR.

" ], "mp-filter": [ "{2001:db8:100::/48^+}" ], "remarks": [ { "description": [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "entities": [ { "objectClassName": "entity", "handle": "XXXX", "roles": [ "registrant" ] } ], "links": [ { "value": "https://example.net/irr0_filterSet/FLTR-FOO", "rel": "self", "href": "https://example.net/irr0_filterSet/FLTR-FOO", "type": "application/rdap+json" } ], "events": [ { "eventAction": "registration", "eventDate": "1990-12-31T23:59:59Z" }, { "eventAction": "last changed", "eventDate": "1991-12-31T23:59:59Z" } ] } ]]>

Autnum Route Policies defines the lookup for autnum objects. The returned autnum object May include an "irr0_policies" member. "irr0_policies" is an optional member and must be an array, the order of the objects in the array is to be observed during processing. "irr0_policies" can contain following object member and each of them is a string containing a value as specified by RPSL: "import" -- see "mp-import" -- see "import-via" -- see "export" -- see "mp-export" -- see "export-via" -- see An example "irr0_policies" data structure:

RDAP Conformance A server that supports the functionality specified in this document MUST include the "irr0" string literal in the "rdapConformance" array () of any response containing an object class or member defined in this document, as well as in the help response.

Privacy Considerations The lookups 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 for further detail. includes security considerations relating to object retrieval in RDAP. Those considerations are relevant here as well.

IANA Considerations IANA is requested to register the following value in the "RDAP Extensions" registry at : Extension identifier: irr0 Registry operator: Any Published specification: This document. Contact: IETF iesg@ietf.org Intended usage: This extension describes a method to access Internet Routing Registry (IRR) data through RDAP.

RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK] This memo introduces a new set of simple extensions to the Routing Policy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. [STANDARDS-TRACK] The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons that are outside the scope of this document. In order to aid in the debugging of these persistent problems, this document proposes the creation of a new Routing Policy Specification Language attribute that allows a network to advertise an IP address that is reachable and can be used as a target for diagnostic tests (e.g., pings). [STANDARDS-TRACK] 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. 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. 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. ICANN ARIN APNIC This document describes and clarifies the usage of extensions in RDAP. 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. 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. 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] 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. IANA 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. 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. 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. NTT This document defines two attributes in the aut-num Class which can be used in RPSL policy specifications to publish desired routing policy regarding non-adjacent networks.

Acknowledgments TODO acknowledge.