Summary

  • ARIN says /rest/net/NETHANDLE/routes returns route objects for the direct NET and does not provide subnets.
  • Adding reassignments=true widens the registration scope to downstream NETs; neither collection is a live BGP measurement or an RPKI verdict.

The empty parent drawer

The tempting mistake begins with a clean result. An operator takes a NET handle, asks ARIN for its route objects and receives an empty collection. The parent block appears to have no routing declaration. In a dashboard, that absence can harden quickly into a red badge: no route, no origin, perhaps no network.

But the request has not searched the whole address tree. ARIN’s own REST guide draws the boundary in unusually plain language. The call at /rest/net/NETHANDLE/routes returns the prefix-and-origin route objects associated with the direct NET. It “does not provide subnets.” The result is a view into one registration drawer, not a recursive inspection of everything numbered beneath it.

That distinction has physical consequences. A carrier may hold a direct allocation and record downstream reassignments for customers. Those child registrations can have their own operational arrangements and their own IRR objects. A tool that checks only the parent collection can miss that layer while reporting its answer with perfect technical accuracy. The error arrives later, when a bounded collection is rewritten as a statement about the network.

Two calls, two perimeters

ARIN documents a second form of the query: /rest/net/NETHANDLE/routes?reassignments=true. This collection includes the NET and its downstream reassignment NETs. The parameter does not improve the truth of an individual route object; it changes which registration objects are eligible to appear.

Both collection descriptions include another boundary. A route must be “visible and authorized in the IRR system” to be included. Here, visible is an IRR condition. It is not a claim that the prefix is visible to the global BGP system, reachable from a given access network, carrying traffic, or accepted by every route server. Authorized is also scoped to the registry system. It should not be silently promoted into legal title, operational control, or a cryptographically validated route-origin result.

The response itself helps keep the claim narrow. ARIN lists four relevant fields for each route reference: an entry type, an organization handle, an origin AS and a prefix. There is no collector identity, AS path, observation timestamp, propagation footprint or validation state in that payload. Those absences are not defects. They show what this interface was built to answer.

A registration tree is not a routing tree

The hierarchy behind the query is administrative. RDAP’s IP network model gives a registration its own handle and can name a parentHandle. A direct allocation and a downstream reassignment are therefore separate registered objects even when one address range sits inside the other. ARIN’s two route-list calls follow that distinction: one stops at the selected NET; the other deliberately traverses reassignments.

RPSL adds a different structure. RFC 2622 defines a route object by the pair of an address prefix and an origin AS. That pair is a database key for a routing-policy declaration. It is useful because networks can use IRR data to build filters and because the same prefix can be associated with different origin ASes in distinct objects. It still does not carry a packet, configure a router or prove that an announcement is present now.

A Route Origin Authorization occupies yet another layer. ARIN describes a ROA as a cryptographically signed object stating which AS is authorized to originate specified prefixes. The current IETF ROA profile defines the signed structure and validation procedure. A matching ROA can strengthen an origin-authorization conclusion, but it does not make an IRR collection a BGP feed; nor does a valid ROA prove that the route is currently announced.

Reading the answer without enlarging it

A defensible investigation records the exact NET handle, endpoint, parameters and retrieval time before it records a conclusion. The direct collection answers whether qualifying route objects are attached to that direct registration. The reassignment-aware collection answers a wider registration question. RDAP or Whois explains the parent-and-child registration structure. RPKI evidence addresses cryptographic origin authorization. Time-stamped routing collectors address what selected observers actually saw.

The order matters. If the direct result is empty, the next question is not “why is the network absent?” It is “was the downstream tree part of this request?” If reassignments=true returns an object, the next question is not “who controls the route?” It is “which registration and origin pair was admitted to this IRR collection, and what independent evidence confirms its present use?”

This is a small interface boundary with a large reporting consequence. The route list is reliable when it is treated as the collection ARIN documents. It becomes misleading only when its perimeter disappears from the sentence written about it.

Sources