Summary

  • RFC 9910 defines rdap-down as immediate-child discovery, while rdap-bottom finds the most-specific registry objects that together cover the requested range.
  • ARIN’s live /21 example returned an active /22 direct allocation and an administrative /8; the /8 covers the residual space and is not a child of the /21.

The impossible-looking drawer

The result set begins with a shape that seems to violate the hierarchy. Ask ARIN’s RDAP service for the bottom objects of 149.112.152.0/21 and it returns two registrations. One is NET-149-112-152-0-1, an active direct allocation represented as 149.112.152.0/22. The other is NET-149-0-0-0-0, an administrative object represented as 149.0.0.0/8.

A /8 cannot be a more-specific child of a /21. Yet the service is not claiming that it is. The apparent contradiction comes from reading the word “bottom” as “all leaves below this node.” RFC 9910 gives the relation a different task: find the most-specific registered objects that, taken together, cover the value supplied by the client.

The /22 covers half of the requested /21. For the remaining addresses, the most-specific registered object available in this response is the broader /8. The bottom set therefore contains an overlap. It describes which registry objects account for the whole query range, not a tidy partition into mutually exclusive descendants.

Down is not bottom

The paired query makes the distinction visible. ARIN’s rdap-down search for the same /21 returns only the direct /22 allocation. That is because rdap-down follows the immediate-child relation: it asks for the next registered objects below the supplied range. The /8 does not qualify.

rdap-bottom asks a coverage question. If more-specific objects do not completely cover the request, a covering object can remain in the set for the residual addresses. RFC 9910 explicitly says that bottom objects need not be disjoint and may even include an object less specific than the input. ARIN’s documentation states the same operational rule: when the discovered bottom objects do not cover the requested value, the most-specific network object is also returned.

Those semantics are useful. A client can discover how far a registration hierarchy has been refined across a range without recursively assembling the tree itself. But the convenience creates a display risk. If a dashboard labels every item “suballocation” or renders the response as a flat set of child blocks, it will turn the coverage object into a false relationship.

What the response actually carries

The returned items identify themselves as ip network objects. They include handles, starting and ending addresses, CIDR representations, RIR-specific types and status values. In the captured response, the /22 is a DIRECT ALLOCATION with status active; the /8 carries status administrative.

Those labels belong to the registry surface. They do not say that both prefixes are announced in BGP, reachable from a given network, carrying traffic or authorized by a Route Origin Authorization. The optional ARIN origin-AS arrays were empty in this capture, but that absence is not proof that no route exists. It is only the state of one field in one registry response at one retrieval time.

RFC 9083 defines the IP network object as registration information. RFC 9082 likewise explains that an ordinary IP lookup selects the most-specific registered network that completely encompasses the query. Neither specification silently converts registration geometry into operational routing state.

Keep the relation attached

A defensible record stores more than the prefixes. It preserves the exact relation requested, the input range, retrieval time, handle, start and end addresses, CIDR, type and status for every result. With those fields intact, the /8 is understandable: it is the covering registration for the portion the /22 does not account for.

The same evidence should be kept separate from routing collectors, IRR route objects, RPKI validation and internal address-management records. Each answers a different question. A bottom search explains registry coverage. It does not show which route is visible, who can change a router, who holds an account, or which organization has legal title.

This is a small distinction with a large downstream effect. Once the relation name is dropped, an accurate response can become an invented delegation tree. The safest label is also the most literal one: coverage by the bottom-most registered objects available for the requested range.

Sources