IRR route objects: what they are, where to create one, and whether a ROA replaces it
You brought a prefix to a new upstream, the session came up, and the prefix went nowhere: the announcement is being filtered because no route object says your network may originate it. Route objects are older than RPKI by more than a decade and transit providers still build their filters from them. Here is what one is, where it belongs, who creates it for leased space, and the honest answer to whether a ROA has made it unnecessary.
What a route object is
A route object is a small record in an Internet Routing Registry stating that a prefix may be originated by an AS number: route 203.0.113.0/24, origin AS64496, plus the maintainer that guards the record and the registry it lives in. The format is RPSL, defined in RFC 2622 in 1999, with route6 objects for IPv6 added by RFC 4012. In the RIPE Database only route, origin, mnt-by and source are mandatory. The key of the object is the prefix and origin pair, not the prefix alone, so several objects for one prefix with different origins can coexist legitimately, and the same pair can be registered in several registries at once: 193.0.14.0/24 with origin AS25152 has separate objects in RIPE, RADB and NTTCOM. Alongside route objects sit as-set objects, named lists of AS numbers that a network expands into a filter for its customers; PeeringDB carries a field for the as-set your peers should expand, and at least one large transit network reads it.
Why your upstream asks for one
Because that is where filters come from. NTT's policy states that every route a customer wishes to announce requires an exact prefix to be registered; it builds route lists at 0100 UTC and loads them, with peers soft-cleared, at 0400 UTC daily. Arelion requires each announced prefix to have a matching route object and/or RPKI ROA and regenerates its filters at 05:00 and 19:00 UTC. Hurricane Electric publishes its algorithm: accept a prefix from the neighbour AS if its RPKI status is valid, otherwise fall back to a registry handle match or an exact match against the peer's IRR policy, and reject everything not explicitly accepted. Tools such as bgpq4 turn registry data into router configuration, and IRRexplorer shows, for a prefix or ASN, which objects exist in which registries next to the ROA state and the observed origins. The consequences follow. A missing object makes the prefix silently unreachable through that transit, and a new object takes until the next filter build to matter, so change today, propagate tomorrow.
Which registry it belongs in
Prefer the registry run by the RIR that issued the space: AFRINIC, APNIC, ARIN, LACNIC and RIPE NCC each operate an IRR that can check an object against their own allocation records, which third-party registries generally cannot. RFC 7682 says it plainly: outside registries that tie objects to allocations, there is generally no assurance of the validity of objects at their creation time. That is why bgpq4's README recommends limiting sources to RPKI plus the five RIR registries and warns against treating the NONAUTH sources as trusted. The third-party registries still matter, because many networks consult them: RADb, run by Merit, is a paid subscription (US$595 a year, US$425 for non-profits, as listed in August 2026); ALTDB is free and makes no verification claim; NTTCOM and LEVEL3 are operator-run. Two histories shape the RIR side. The RIPE Database stopped creating out-of-region route objects on 4 September 2018, moved the existing ones to a separate source, RIPE-NONAUTH, and since January 2020 deletes any NONAUTH object that has conflicted with a ROA for fourteen consecutive days; the future of that source has been under discussion since 2025. ARIN launched an authenticated IRR in June 2020 and retired its unauthenticated ARIN-NONAUTH database in April 2022; objects can only be created for resources covered by an ARIN agreement, which is why holders of legacy space without one cannot use it.
Leased or transferred space: who creates it
In the RIPE Database and ARIN's IRR, authorisation belongs to the address holder, not the announcing network, and this is the point that trips up leases (APNIC and AFRINIC also involve the origin ASN's maintainer, so check your own RIR's current rules). In the RIPE Database the check runs against the maintainers on the covering route object if one exists, otherwise on the covering inetnum, in the order mnt-routes, mnt-lower, mnt-by, and only that one object is consulted; you do not need to authenticate against the origin AS at all, since ASN-holder authorisation was removed in 2018. In ARIN's IRR the origin ASN in a route object does not have to be registered to the object's organisation. So the lessor creates the object naming the lessee's ASN, or in RIPE grants the lessee's maintainer through mnt-routes, optionally limited to the leased prefixes; in the RIR's registry the lessee cannot do it alone and should not expect to, while a third-party registry will take the lessee's own object, which is exactly why some upstreams trust it less. The reverse duty matters as much: when the lease ends, delete the object, and check the third-party registries too, because a stale copy there can outlive the RIR one and keep an old tenant's announcement acceptable to some networks. Origin history tells you which ASNs to look for, since the networks that have originated a prefix over time are the ones its leftover objects are most likely to name; IRRexplorer or a whois query across all sources shows the objects themselves.
Does a ROA replace it?
Per upstream, not globally. Arelion accepts a route object and/or a ROA; Hurricane Electric accepts a prefix from the neighbour when RPKI says valid; MANRS lets an operator document announcements with ROAs in lieu of IRR objects; and IRRd version 4, the registry software behind RADb and NTT's registry among others, runs RPKI-aware by default, suppressing RPKI-invalid objects and publishing a pseudo-object for every ROA under a source called RPKI. But NTT's policy page still says every customer route needs an exact prefix registered, even though RPKI is among the sources its registry consults, so whether a ROA alone satisfies it is not stated in words; and you cannot know that every network on the path reads ROAs, because some filters still read only route objects. The 2026 answer is therefore both, in this order: a ROA first, because one object serves every network that validates, with no copy per registry; a route object in your RIR's registry, because some filters read nothing else; and the as-set published in PeeringDB, because at least one large transit network reads it from there. Then check the result the way an upstream will, from outside, before you assume the prefix is reachable.
Look up your prefix on the front page for the origin history a route object should agree with: which networks have announced it and when, the registered holder and the RPKI state beside the current origin so a mismatch is visible, and which past origins a leftover object might still name. Look up the ASN for the prefixes it announces today; the per-prefix origin history is where the older story lives.