Route Objects Explained: IRR, RPSL and Why Your BGP Announcement Needs One

What is a route object? A route object is a small database record, written in a language called RPSL and stored in an Internet Routing Registry (IRR), that says "this IP prefix is expected to be announced by this AS number." It pairs a prefix (the route: or route6: attribute) with an originating AS (the origin: attribute), and transit providers, peers and IXP route servers read these objects to decide which BGP announcements to accept and which to drop.

If you run BGP, this tiny record is the difference between your prefix propagating across the Internet and your prefix being silently filtered by your own upstream. Plenty of new operators finish getting their ASN, configure their session, announce a prefix, and then spend a frustrating afternoon wondering why half the Internet cannot reach them. The usual answer is a missing or wrong route object.

If you lease a /48 from us, we create its route6 object and ROA when the block is provisioned, but understanding what the object says is still worth ten minutes.

What is a route object, concretely?

A route object is a structured text record with a fixed set of attributes. Here is a real-shaped example for an IPv4 prefix in the RIPE Database:

route:          192.0.2.0/24
descr:          Example Corp customer prefix
origin:         AS64500
mnt-by:         EXAMPLE-MNT
source:         RIPE

The IPv6 equivalent is called a route6 object and is identical in structure apart from the attribute name and the address family:

route6:         2001:db8::/32
descr:          Example Corp IPv6 prefix
origin:         AS64500
mnt-by:         EXAMPLE-MNT
source:         RIPE

Per the RIPE Database documentation, the mandatory attributes are:

The single most important thing to understand: the prefix and the origin AS together form the primary key. Change the origin AS and you have a different object. That pairing is exactly the claim the rest of the Internet cares about, which prefix belongs behind which AS, so it makes sense that it is what uniquely identifies the record.

What are IRR and RPSL?

Route objects do not float in a vacuum. They live in an Internet Routing Registry (IRR), and they are written in RPSL (Routing Policy Specification Language).

RPSL is the object-oriented language operators use to describe routing policy and the resources involved. It was standardised in RFC 2622 (Proposed Standard, June 1999), which obsoleted the earlier RFC 2280 and was later updated by RFC 4012 and RFC 7909. RFC 2622 defines the object classes you will meet constantly: the route class for inter-AS routes, the aut-num class for an AS and its import/export policy, and the as-set class for named groups of AS numbers. RFC 4012 (RPSLng) added the IPv6 and multicast extensions that gave us route6.

The IRR is not one database. It is a distributed set of registries that publish their data for mirroring (NRTM), and each network mirrors the ones it trusts. The five Regional Internet Registries each run an IRR for the address space they manage (RIPE, ARIN, APNIC, LACNIC, AFRINIC), and there are independent registries too, the best known being RADb, the Routing Assets Database operated by Merit Network. Operators query across all of them, and many providers mirror a defined list of trusted registries into their own filtering pipeline.

One rule follows from this distributed design: put your object in the authoritative registry for your space. For a RIPE-region prefix, that is the RIPE Database. Registering the same prefix in a random open registry that your upstream does not mirror does nothing useful, and creating objects in loosely authenticated third-party registries is exactly the weakness that RPKI (below) was designed to close.

The RIPE Database only accepts a route or route6 object for a prefix allocated to the RIPE region. Older out-of-region objects live in a separate source, RIPE-NONAUTH, which still held 41,598 route objects in the dump of 24 September 2026. Under ripe-731, a NONAUTH object that conflicts with a ROA for 14 consecutive days is deleted.

ARIN retired its own non-authoritative registry on 4 April 2022. RADb costs $595 per year ($425 for non-profits) and refuses route objects that are RPKI-invalid. If you bring addresses to AWS, BYOIP writes the RADb objects itself.

Why does a BGP announcement actually need a route object?

Because an upstream that builds its filters from the IRR will not carry a prefix it cannot see a route object for. At NTT, that is filtering policy.

Look at how a Tier 1 states it. NTT's Global IP Network route registry FAQ is blunt: "Every route wished to be announced by a customer requires an exact prefix to be registered." NTT frames the requirement as protection, "a safeguard to help protect the Global IP Network (and the rest of the Internet) from accidental announcement of prefixes which do not belong to the ASN or similar errors which have caused other ISPs to have (multi-day) outages/instability." It also propagates downstream: "If your company has 'downstream' BGP customers, those customers will need to have route objects created for their networks if they want to transit your NTT connection." NTT accepts objects from whatever registry the customer prefers, as long as it is one NTT mirrors.

Arelion (formerly Telia Carrier) is in the same place: it recommends registering your as-set and route objects in an authenticated IRR database, preferably one run by an RIR, and rebuilds its prefix filters from that data on a schedule (published as 05:00 and 19:00 UTC). Its filters accept a matching route object and/or RPKI ROA for each prefix, and they also read a few legacy registries such as RADb.

The mechanism behind those policies is simple. Providers who build filters from the IRR search for route objects matching each peer's or customer's AS, and only accept announcements that have a matching, correct route object. No object, or the wrong one, and the announcement is dropped. Publish a matching route object for every prefix you announce; some networks also accept a valid ROA instead, but not all do.

Where the as-set comes in

For a provider with one directly connected customer, listing prefixes by hand would be fine. The problem is downstream. A transit customer may itself have BGP customers, who have customers, and the provider needs to accept all of those prefixes without hand-editing filters every time the tree changes.

That is what the as-set solves. An as-set is a named object that groups AS numbers (and other as-sets) together. A provider points its customer filter at a single as-set; the customer maintains the membership; tools then walk the as-set, collect every member AS, pull every route object those ASes originate, and emit a concrete prefix list. Utilities like bgpq4 and IRRToolSet do exactly this transformation, turning IRR objects into router configuration. The result is that a well-maintained as-set plus accurate route objects let a filter update itself as your customer base changes, with no manual intervention from the upstream.

If you are getting your first ASN, your upstream will usually ask for two things: your AS number, and either a per-prefix route object list or an as-set they can build from. Getting both right up front avoids the "announced but unreachable" afternoon.

How do you create a route object in the RIPE Database?

For prefixes in the RIPE region, the RIPE Database is authoritative, and there are two common ways in.

1. Webupdates (the web form). Log in with your RIPE NCC Access account (two-factor authentication has been mandatory since 2024), choose object type route (or route6 for IPv6), and fill in the attributes: the prefix, a descr, the origin AS, your mnt-by maintainer, and source: RIPE. Submit it. This is the friendliest path for a one-off object.

2. Syncupdates or the REST API. For automation, send the object over HTTPS to syncupdates as a POST (updates via GET have been refused since 18 March 2026) or to the RIPE Database REST API. MD5 passwords were removed from maintainers on 4 March 2026, so scripts authenticate with an API key, an OAuth 2.0 or OIDC token, or a PGP or X.509 signature. This is how provisioning systems create objects at scale.

The part that trips people up is not the form, it is authorisation. A common misconception is that you must authenticate against the AS in the origin attribute. You do not: since the NWI-5 change in 2018, the RIPE Database no longer requires authentication against the origin AS Number when creating a route object. What the registry does require is authorisation over the address space (or the route space). It checks in a defined order: an exact-match route object first, then a less specific route object, then the address space object (the inetnum/inet6num or allocation) covering the prefix. That check must succeed against a maintainer you hold, and the object's own mnt-by maintainer must also authorise the creation. The origin AS holder is not asked to authenticate at all; they are only notified, via the notify: attribute on the aut-num, if that AS Number exists and has notify: set. This is deliberate, it is what stops a stranger from registering a route object for your prefix.

Two practical consequences:

• If you announce space registered to someone else (leased IPv4, a customer's PI block), the RIPE Database accepts the object only with that holder's maintainer. The holder either creates the route object for you or adds your maintainer to mnt-routes: on the covering inetnum or inet6num. A Letter of Authorization does not replace that step: it is paperwork for your upstream, not for the database (our free LOA generator produces one).
• If you hold the address space under a maintainer you control, creation is straightforward, and you can put any origin AS you like on the object. That is the common case for a small operator with its own resources.

For IPv6 we lease from our allocation, we create the objects for you. After payment the inet6num is created, then its route6 object and ROA, with no action on your side. A PI /48 is registered to your own organisation, so its route6 objects are managed from your dashboard and its ROA is signed in your End User hosted CA, not in ours.

Route objects vs RPKI ROAs: which one do you need?

Both. They answer overlapping questions with different trust models. Publish both.

A route object is a text record in the IRR. Its strength is that it is human-readable, expressive (it feeds as-set logic and richer policy), and universally consumed by filter-building pipelines. Its historic weakness is authentication: for years, loosely governed registries let almost anyone create objects, so a route object proved intent but not necessarily authority.

An RPKI ROA (Route Origin Authorization) is a cryptographically signed object in the Resource Public Key Infrastructure. Per ARIN, a ROA states which AS number is authorised to originate a given prefix, and it carries three key elements: the origin AS, the prefix, and a maximum prefix length. Because it is signed with a certificate tied to the resource holder, a router (or a validator feeding one) can verify the claim without trusting a database's access controls. This is Route Origin Validation (ROV): networks that enforce it drop announcements a ROA marks Invalid, and APNIC Labs put the global ROV filtering average at 26.92% on 29 July 2026. The step-by-step ROA guide for the RIPE Database covers creating one, and the RPKI checker shows how a prefix and origin validate today.

Here is the clean way to hold the distinction:

They are complementary, not substitutes. The IRR still drives how most providers construct the actual prefix lists loaded into routers, especially anything involving downstream customers and as-sets. RPKI adds the cryptographic layer that says "and this origin is genuinely authorised," closing the gap that unauthenticated IRR entries left open. RFC 7909 defines how to sign RPSL objects with RPKI keys. In practice the link runs through the registries: ARIN's IRR Auto-Manager, live since 13 January 2025, creates a matching route object with each ROA and removes it when the ROA goes. In the RIPE region the two stay separate: the route object goes in the RIPE Database, the ROA in the RPKI Dashboard.

Both systems key off your AS number as the origin, so it helps to be clear on what an ASN is before you register either, and on what RPKI is for the validation side. The short version for a working operator: publish accurate route objects so filters accept you, and publish ROAs so validators trust you. Skip either and some slice of the Internet will treat your announcement with suspicion. Neither one covers the AS path: that is what ASPA adds.

Common route object mistakes to avoid

These are the problems that most often get a prefix filtered:

• Wrong origin AS. The origin in the object must match the AS actually originating the prefix in BGP. A typo here is invisible until a filter rebuild drops you.
• Object in a registry your upstream does not mirror. Correct object, wrong place. Confirm which registries your provider builds filters from.
• Missing more-specifics. If you announce a /24 out of a covering /22, some providers expect an object for what you actually announce. Register the exact prefixes you originate.
• Stale objects after a change. Renumbering, moving space between ASes, or ending a lease leaves orphaned objects that can cause conflicts. Clean them up.
• No as-set for downstream customers. If you provide transit, your upstream needs an as-set to build filters for your customers' prefixes, not just your own.
• ROA and route object that disagree. If your route object says AS64501 and you originate from AS64501, but your ROA authorises AS64500, ROV marks the announcement Invalid while the IRR filter accepts it. Keep the origin AS the same in both.

Frequently asked questions

Do I need a route object if I only peer at an IXP? Usually yes. DE-CIX's route servers check RPKI first: a Valid route is accepted with or without a route object, an Invalid one is rejected, and a NotFound route has to resolve through IRR data, which means a route object and an as-set that includes your AS.

What is the difference between a route and a route6 object? Only the address family. route is for IPv4 prefixes, route6 is for IPv6 prefixes. The attributes and the origin-pairing logic are the same.

Can I create a route object for space I lease? Yes, with the holder's authorisation in the RIPE Database. The holder creates the object, or adds your maintainer to mnt-routes: on the covering inetnum or inet6num. An LOA alone will not get the object accepted.

Does a route object secure my routing? It documents intent and drives filtering, but it is not cryptographic on its own. For cryptographic origin validation, pair it with an RPKI ROA.

Who creates the object if Via-Registry sponsors me? For a /48 you lease from us, we create the route6 object and the ROA at provisioning. For a PI block, you manage route6 objects from the dashboard and sign ROAs in your own End User hosted CA.

Do I still need a route object if I have a ROA? Often yes. NTT builds customer prefix filters from IRR data and wants an exact-match route object, while Arelion accepts a route object or a ROA and DE-CIX route servers accept an RPKI-valid route without one. Publishing both costs nothing in the RIPE Database and covers every filter type.

The bottom line

A route object is a two-line claim, prefix plus origin AS, that IRR-built filters read before deciding whether to carry your traffic. Create it in the registry your upstream mirrors, keep its origin AS the same as your ROA, and your announcement propagates the way it should.

If you do not have an ASN yet, our ASN registration costs €130 per year through our sponsorship (as of September 2026), and a /48 leased from us (€40 per year) comes with its route6 object and ROA already in place. If you are still weighing options, our ASN registration cost breakdown and PI vs PA resources guide cover what comes with the resources these objects describe.

Official References

• RFC 2622: Routing Policy Specification Language (RPSL)
• RFC 4012: Routing Policy Specification Language next generation (RPSLng)
• RFC 7909: Securing RPSL Objects with RPKI Signatures
• RIPE Database docs: Descriptions of Primary Objects (route / route6)
• RIPE Database docs: Protection of Route(6) Object Space
• ripe-731: RIPE-NONAUTH route object clean-up
• ARIN: IRR Auto-Manager
• NTT Global IP Network: Route Registry FAQ
• Arelion: Routing security
• ARIN: Route Origin Authorizations (ROAs)
• Peering Toolbox: Internet Routing Registry