What are RPKI and ROA? Why a wrong ROA makes your announcement invisible
By Datafex Engineering TeamPublished 5 min read
There is a missing piece in the design of BGP: the protocol itself never asks whether an ASN is actually entitled to announce the range it is announcing. It accepts what its neighbour sends and spreads it to the world. RPKI closes that gap by adding a layer of signed records — and it is the record that everyone preparing to announce their own range through another network has to be most careful with.
When it is wrong, the result is not "being unprotected". Your announcement is rejected outright by operators that validate. This article covers the fields a ROA is made of, what the three validation outcomes mean, and what the two classic mistakes look like from the outside.
A ROA says three things
A ROA (Route Origin Authorisation) is a record signed by the holder of the range, and it has three fields:
| Field | What it says |
|---|---|
| Prefix | Which range I am speaking about |
| Origin ASN | Which ASN is entitled to announce it |
| maxLength | Up to what prefix length that entitlement holds |
Put as a sentence: "this range may be announced by this ASN, at a length no longer than this." When a validating router sees an announcement in the routing table that does not match the triple, it rejects it deliberately.
Three outcomes: valid, invalid, not-found
Validating an announcement produces one of three results.
Valid — a ROA covering the range exists and the announcement matches it on both origin ASN and length. This is the state you are aiming for.
Invalid — a ROA covering the range exists but the announcement does not match it. Either the origin ASN differs, or the prefix is longer than maxLength allows. Operators performing RPKI validation will not accept the traffic at all in this state.
Not-found — no ROA covers the range, so RPKI says nothing about your announcement. That does not mean the announcement will be rejected; it means you are not getting the protection RPKI offers.
The critical distinction: RPKI-based rejection targets the invalid state, not not-found. A range that has never been touched by RPKI therefore carries less reachability risk than one with a wrong ROA. Creating the record buys protection; creating it and then forgetting to update the announcement produces an outage directly.
Classic mistake one: not updating the origin ASN
The scenario is always the same: the range has been announced from your own ASN for years, and the ROA names that ASN. Then you decide to announce the range through a protection provider's network. The announcement arrangement changes, the ROA stays on the old value. Result: invalid.
There is an important nuance here — depending on the design, the origin ASN that belongs in the ROA may be yours or may be the ASN taking on the announcement. What decides it is who actually originates the announcement. So do not guess the value; in a BGP protection build the record values — origin ASN, maxLength and the IRR route object — are given to you in writing alongside the transition plan. You make the update, because the RIPE account is yours; the provider tells you what the values should be.
The symptom is insidious too: an invalid announcement is rejected not by everyone, only by the networks that apply validation. So some regions reach you and others do not, and "it works for us" can hide this mistake for hours.
Classic mistake two: leaving maxLength wide
The appeal of a wide maxLength is obvious: set it generously and you never have to revisit the ROA if you later split the range and announce longer prefixes. The price is paid directly on the security side.
RPKI checks only two things: the ASN making the announcement and the prefix length. Keeping maxLength longer than what you actually announce also makes a more specific announcement valid — one made with your origin ASN, but not made by you. Because a longer prefix is more specific in routing, it pulls the traffic to itself, which means you have opened the door for parts of your range to be announced by someone else.
The practical rule is simple: set maxLength equal to the prefix length you actually announce today. When you need to split, you update the ROA then — a job of a few minutes.
IPv4 and IPv6 records are separate
An IPv6 range is announced with the same logic: a route6 object is defined in the IRR and a separate RPKI ROA is created for the IPv6 prefix. The records for the two families are entirely independent, and updating one while forgetting the other is a common mistake. On a dual-stack service the symptom is especially confusing: the same domain opens for some clients and fails for the ones that prefer IPv6.
Timing: records first, announcement second
Record changes can take hours to spread. That is why the order is never reversed: the ROA and IRR are updated, propagation is waited out, the validation state is confirmed as valid from independent sources, and then the announcement is brought up. Trying to fix the record after the announcement is live means extending the outage by the propagation delay.
Three things are watched during the cutover: whether the range is visible from independent observers — RIPE RIS, looking glass services, public BGP monitoring tools — whether RPKI validation reads as valid, and whether real user traffic arrives over the expected path.
Why this matters even without your own range
If you do not hold a range you do not manage the ROA, but you live with its consequences: when the records behind the addresses you use are wrong, the reachability problem shows up in your service. Under IP rental the addresses are announced through the Datafex network, so responsibility for those records stays with us; what stays on your side is rDNS and routing configuration.
If you are planning to move your own range, write down the origin ASN and maxLength on your current ROA before you start. Those two numbers shape the whole transition plan — send them along when you write to us.