Summary

  • The proposed irr0 extension names six RDAP lookup paths for IRR records, including a route identified by prefix and origin AS.
  • Support for peering sets, router sets and filter sets is optional. The policy array on an existing autnum response is optional too; a client cannot infer “no policy” merely from its absence.

A route object could get a clean RDAP address: irr0_route/192.0.2.0/24/64500. The prefix and origin AS sit in a structured JSON response, with fields for set membership, associated entities and events. That is a substantial improvement in how a program can read a routing registry. It is also where a program can become dangerously overconfident. The same proposal gives it six doors into IRR data, then lets the server leave several rooms closed.

Revision 00 of RDAP Extension for Internet Routing Registry (IRR) Objects was submitted on 29 October by Mahesh Aggarwal, Jasdip Singh, Andy Newton and Sasha Romijn. It is an individual Internet-Draft, not an adopted IETF standard. It proposes the irr0 extension because the existing RDAP query format names core registration objects, while IRR route and policy objects still commonly arrive as RPSL text through WHOIS.

The proposed paths cover a route object, a route set, an AS set, a router set, a peering set and a filter set. The route lookup's two-part key matters: an address prefix alone is not enough for a complete route lookup; the originating AS is part of the question. ARIN's IRR guide makes the distinction operational. It describes a route object by prefix and origin ASN, an AS set as a group of ASNs, and a route set as prefixes or other route sets. A route set is not a bag of database route objects. A client that flattens them into one list has already lost the policy's shape before the new transport helps it.

Then comes the coverage clause. Section 6 of the draft makes support for peering sets, router sets and filter sets optional at the implementation's discretion. Section 7 adds an optional irr0_policies array to an autnum response, potentially carrying ordered import, export, multiprotocol and -via policy strings. The order of entries matters if the array exists. A program that asks for an AS record and sees no policy array has learned about that RDAP response. It has not learned that the AS has no routing policy recorded elsewhere.

The draft requires a supporting server to declare irr0 in rdapConformance for extension responses and in its help response. That is a useful capability flag, but its own optionality leaves a second question: which of the six object classes and which policy members can this particular server actually supply? One flag cannot answer all six queries. This is the acceptance test a network operator should demand before feeding the new format into a filter builder.

The present operating surfaces underline the gap. RIPE NCC's RDAP documentation currently lists autnum, domain, ip and entity as supported object types. ARIN documents its IRR management and search separately from its registration RDAP interface. The draft aims to give these worlds a common reading format; it reports no deployment count, cross-registry coverage measurement or filter-generation test. A live implementation showing its class-by-class coverage would settle the practical question. Until then, “RDAP returned JSON” is only the start of an inventory.

IRR-in-RDAP draft · RFC 9082 · RIPE NCC RDAP guide · ARIN IRR guide