Authorise your prefix with RPKI ROAs and IRR objects

Two separate databases decide whether the internet accepts a route you originate:

1. RPKI answers "is this ASN cryptographically authorised to originate this prefix, at this length?"
2. IRR answers "has this ASN published an intent to route this prefix?"

They are independent. A prefix can be RPKI Valid and still be dropped by a network that filters on IRR data, and it can have a perfect IRR object while RPKI marks it Invalid. Networks that do route origin validation reject Invalid outright, so an RPKI mistake is the more dangerous of the two.

The BGP session walkthrough treats both as prerequisites and assumes they already exist. This article is how you create them.

Every address, ASN, and object below is a documentation example. AS64500, 203.0.113.0/24, and 2001:db8:100::/48 are reserved for exactly this purpose. Replace them with the resources your RIR issued to you.

Do this before the session, not after

Publish and verify the authorisation first, then bring up BGP. The order matters for a practical reason: if you announce a prefix that is Invalid, the failure is silent from where you are sitting. Your session reaches Established, show route export looks correct, and the route simply does not arrive at a large share of the internet. You end up debugging BIRD when the problem is in a database.

Authorising first also fails safe. A ROA that exists before any announcement causes nothing to happen. A ROA that arrives late leaves a window where your route is Invalid in front of every validating network.

What each system holds

You want both. RPKI is the one that actively gets your route dropped; IRR is the one that quietly leaves you out of a peer's filter.

1. Create the ROA

Hosted RPKI at your RIR is the right choice unless you have a specific reason to run your own certificate authority. The RIR holds the key material and publishes to its repository for you.

Create one ROA per prefix you intend to originate. Each needs three fields:

Repeat for IPv6:

If you announce from more than one ASN, create a separate ROA per origin. A ROA authorises one origin ASN; it does not accept a list.

2. maxLength is the field that breaks announcements

maxLength is the longest prefix the ROA authorises. A route is Valid when a covering ROA matches the origin ASN and the announced length is less than or equal to maxLength.

The failure is asymmetric, so both mistakes are worth understanding.

Setting it too short breaks your own traffic. A ROA for 203.0.113.0/22 with maxLength 22 makes every more-specific announcement Invalid. The moment you deaggregate to 203.0.113.0/24 for traffic engineering or a partial migration, that /24 is rejected by validating networks while the /22 stays up. The symptom is confusing: some destinations reach you, some do not, and nothing in your router logs mentions it.

Setting it too long invites hijacks. A ROA for 203.0.113.0/22 with maxLength 24 authorises anyone who can inject a more-specific /24 from your ASN to be treated as Valid. Because a more-specific route wins regardless of validation state, a permissive maxLength hands an attacker a route that passes origin validation.

The rule that avoids both: set maxLength equal to the prefix length you actually announce. RFC 9319 makes the same recommendation. If you announce a /22 as a single route, use maxLength 22. If you deliberately announce four /24s, publish ROAs matching those /24s rather than widening the /22.

NotFound is not a failure. It means no ROA covers the prefix, and most networks still accept it. Only Invalid gets you dropped.

3. Publish the matching IRR object

An IRR route object states that your ASN intends to originate the prefix. Upstreams and peers run tools such as bgpq4 against IRR data to build prefix lists, so an absent or stale object shows up as your route missing from someone's filter.

A RIPE-style route object looks like this:

route:          203.0.113.0/24
origin:         AS64500
mnt-by:         MAINT-EXAMPLE
source:         RIPE

And the IPv6 equivalent uses route6:

route6:         2001:db8:100::/48
origin:         AS64500
mnt-by:         MAINT-EXAMPLE
source:         RIPE

Create these through your RIR's database interface using the maintainer object that holds your resources. ARIN members can publish through ARIN's IRR; networks whose RIR database is not widely mirrored sometimes register in RADB as well.

Two rules keep IRR from becoming a liability:

• The origin ASN must match the ROA. An IRR object saying AS64500 and a ROA saying AS64501 is a contradiction that will be resolved against you.
• Delete objects you no longer use. Stale route objects for prefixes you have returned or moved are a known source of hijack legitimisation, because filter generators trust them.

If your upstream builds filters from an as-set, make sure your ASN is a member of the set they use. An object that exists but sits outside the referenced as-set will not appear in the generated prefix list.

4. Verify before you announce

Do not trust the portal's success message. Check the published result from outside.

Publication is not instant. The RIR signs and publishes to its repository, then every validator in the world picks it up on its own refresh interval, commonly somewhere between ten minutes and an hour. Re-check rather than assuming a stale answer is final.

Query RIPE Stat for the validation state. This works for any resource, not only RIPE-allocated ones:

curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=203.0.113.0/24' \
  | jq '.data.status, .data.validating_roas'

A status of valid with a ROA listed for your origin is what you want. unknown means the ROA has not propagated yet or was never created.

Check the IRR object is really there:

whois -h whois.ripe.net -- '-T route 203.0.113.0/24'
whois -h whois.radb.net -- '-i origin AS64500'

The second command lists every object registered against your ASN across RADB, which is the fastest way to spot stale entries you forgot about.

Confirm what a filter generator would actually build. This is the closest thing to seeing your prefix through an upstream's eyes:

bgpq4 -4 -l AS64500-IN AS64500
bgpq4 -6 -l AS64500-IN6 AS64500

If the output does not contain your prefix, no amount of correct BGP configuration will get you into that peer's prefix list.

Run a validator locally if you operate a network of any size. routinator and rpki-client both fetch the global repository and expose validated payloads, which is also what you would feed your own routers for inbound validation:

routinator vrps -a -p 203.0.113.0/24

5. Then bring up the session

With status reported as valid and the IRR object visible, provision the session and prefix in VPS Control and follow the BGP session walkthrough. The ASN verification code goes to the contact address published for your ASN, so confirm that mailbox works before you start.

Announce one prefix first and confirm it globally before adding the rest. A single working announcement proves the authorisation chain end to end.

Diagnosing an Invalid state

Overlapping ROAs deserve their own note. Validation considers every ROA that covers the prefix, and one permissive entry can mask a mistake in another. After changing origin ASN or renumbering, list what is published and remove what no longer applies.

Checklist

• A ROA exists for every prefix you originate, IPv4 and IPv6.
• maxLength equals the length you actually announce.
• The origin ASN in the ROA matches the ASN in the IRR object.
• route and route6 objects are published and current.
• Stale objects for returned or moved prefixes are deleted.
• RIPE Stat reports valid for the exact prefix and origin pair.
• bgpq4 output contains your prefix.
• Your ASN is a member of any as-set your upstream filters on.

Authorisation is the layer people skip, and it is the layer that fails quietly. A route that is Invalid looks perfect from your own router right up until you ask someone else whether they can see it.