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 millions of 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 their ASN registration, 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.

This article explains what route and route6 objects are, the RPSL language and IRR system behind them, how networks turn them into filters, how to create one in the RIPE Database, and how they relate to RPKI ROAs. If you are a Via-Registry sponsored customer, we create these objects for you as part of provisioning, but understanding them is still worth your time.

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 mirror each other. 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.

Why does a BGP announcement actually need a route object?

Because your upstream will not carry a prefix it cannot see a route object for. This is not a courtesy, it is filtering policy at the biggest networks on the Internet.

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).

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. Every prefix you announce needs a matching record.

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 to the RIPE Database web interface, 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 (the API). For automation, syncupdates accepts the object as text over an HTTP request and returns a plain-text acknowledgement. This is how scripts and 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 that belongs to someone else (leased IPv4, a customer's PI block), you need maintainer authorisation over that address space, or a Letter of Authorization from the holder, before the object will be accepted. Note that this is about the prefix, not the AS number.
• 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 Via-Registry sponsored customers, we handle this. When we assign your resources, we create the matching route and route6 objects as part of provisioning, so your prefixes are filter-ready without you touching the RIPE Database. IPv6 /48s we sub-assign from our allocation come with their route6 objects and RPKI ROAs configured automatically at assignment time, which is one less moving part between you and a working announcement.

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

Both. They answer overlapping questions with different trust models, and the modern consensus is to 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): announcements that conflict with a valid ROA are marked Invalid and typically dropped.

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. The two systems are even converging: RFC 7909 defines how to sign RPSL objects with RPKI signatures, and RIRs increasingly generate authenticated route objects straight from ROA data.

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. 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.

Common route object mistakes to avoid

A few recurring problems account for most "why is my prefix filtered" tickets:

• 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 ROA authorises AS64500 but your route object says AS64501, ROV can mark you Invalid. Keep origin AS consistent across both systems.

Frequently asked questions

Do I need a route object if I only peer at an IXP? Usually yes. Most IXP route servers build filters from IRR data and RPKI, so an announcement without a matching route object (or a valid ROA) is commonly rejected at the route server.

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, if you have authorisation. You need the address holder's maintainer permission or a Letter of Authorization so the RIPE Database accepts the creation against the covering address space.

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? We do, as part of provisioning your resources, including route6 objects and RPKI ROAs for the IPv6 space we assign.

The bottom line

A route object is a two-line claim, prefix plus origin AS, that the entire filtering economy of the Internet reads before deciding whether to carry your traffic. RPSL is the language, the IRR is the distributed home, as-sets are how the claim scales to downstream customers, and RPKI ROAs are the cryptographic proof that sits alongside it. Get the object right and in the right registry, keep its origin AS consistent with your ROA, and your announcement propagates the way it should.

If you would rather not manage any of this by hand, our ASN sponsorship includes route object and RPKI setup as standard, so your prefixes arrive filter-ready. 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
• NTT Global IP Network: Route Registry FAQ
• Arelion: Routing security
• ARIN: Route Origin Authorizations (ROAs)
• Peering Toolbox: Internet Routing Registry

Facts checked July 2026.