What is RPKI? ROAs and route origin validation explained

02What is a ROA?

A Route Origin Authorization (ROA), profiled in RFC 9582, is a signed object that names one origin ASN and one or more prefixes it may announce, each with an optional maximum length. The maximum length, or maxLength, is the longest prefix the AS may announce inside the ROA's prefix; without it, only the exact prefix is authorised.

• Prefix: the address block, for example 193.0.0.0/21
• Origin ASN: the AS allowed to originate it under this ROA, for example AS3333
• maxLength: the most specific announcement allowed; /21 here means no more-specifics
• Several ROAs can cover the same space, for example one for your own ASN and one for a DDoS mitigation provider
• A ROA for AS 0 states that the space should not be routed at all (RFC 6483), useful for unused blocks

03Valid, invalid, not found: how origin validation works

RFC 6811 defines the states. A ROA covers a route if the route's prefix is the ROA prefix or a more specific part of it. It matches if it covers the route, the route is no longer than maxLength, and the origin ASN is the one in the ROA. Valid means at least one ROA matches; invalid means at least one ROA covers the route but none matches; not found means no ROA covers it at all.

Every row below was checked against RIPEstat's validator, using the RIPE NCC's real ROA for its own address block; RIPEstat reports not found as unknown.

04Why does an RPKI-invalid prefix lose reachability?

Because a growing number of networks drop invalid routes rather than just marking them. When a large transit provider rejects your announcement, every network behind it loses the route too, and the only remaining paths run through networks that do not validate. The result is partial, hard-to-diagnose unreachability: some users reach you and others time out.

Coverage has grown quickly. The NIST RPKI Monitor, which validates the unique prefix-origin pairs seen by the RouteViews collectors, reported for 23 October 2026 that 71.0% of IPv4 pairs were valid, 27.5% not found and 1.5% invalid; on 23 October 2024 the valid share was 53.5%. Measured by address space instead, 63.3% of announced IPv4 space was covered by valid announcements.

The 1.1.1.1 incident of 27 June 2024 shows both sides. AS267613 announced 1.1.1.1/32; Cloudflare's ROA allowed nothing longer than /24, so the route was invalid and networks performing ROV ignored it, while networks that did not validate accepted it. The same mechanism will drop your legitimate announcement if your ROA is wrong.

05How do I create a ROA?

ROAs are created where your address space is registered. Most holders use their regional registry's hosted RPKI service, which keeps the keys and signs on their behalf; some large networks run a delegated certificate authority instead.

• List every announcement first: prefix, origin ASN and where it is announced, including more-specifics used for traffic engineering or DDoS mitigation
• RIPE NCC: the RPKI dashboard can create ROAs from announcements it already sees and previews which routes a change would make invalid
• ARIN: hosted RPKI in ARIN Online needs a registration services agreement (RSA or LRSA) covering the resources
• APNIC, LACNIC and AFRINIC also operate RPKI services; look in your registry's member portal
• Set maxLength equal to the prefix length unless you really announce every more-specific; RFC 9319 recommends avoiding maxLength
• Verify the result with a validator, then enable your registry's alerts for invalid or not-found announcements

06ROAs for DDoS protection and bring-your-own-IP

Routing-based DDoS protection works by having the protection network announce your prefix, or a more specific part of it, so that attack traffic arrives there to be filtered; clean traffic is then delivered to you, usually through a GRE tunnel, as compared in GRE vs IPIP. If the provider originates the route from its own ASN while your ROAs name only your own ASN, the announcement is invalid and validating networks will not use it, exactly when you need it most.

RFC 9319 covers this case directly. Its example gives the customer a ROA for its own ASN and a second ROA authorising the mitigation provider's ASN for the protected block, created well in advance because RPKI data reaches routers more slowly than BGP updates. It also states the cost: while the protected block is not announced, its addresses are open to forged-origin sub-prefix hijacks, and if that second ROA uses maxLength to allow any /24 inside a /22, every /24 not under mitigation is exposed as well.

That risk is not theoretical. In August 2026 a /24 inside a /16 was hijacked with a forged origin, and because the holder's ROA allowed any length from /16 to /24 the hijack was RPKI-valid; the details are in what BGP hijacking is. For how routed protection fits into the bigger picture, see what DDoS mitigation is.

prefix 192.168.0.0/16   origin AS64496   maxLength 16   # your normal announcement
prefix 192.168.0.0/22   origin AS64500   maxLength 22   # provider, during mitigation

# looser variant discussed in the same RFC, with its stated risk:
prefix 192.168.0.0/22   origin AS64500   maxLength 24   # any /24 can be diverted, but
                                                        # unannounced /24s become hijackable

07What RPKI does not protect against

Origin validation stops the most common accident, someone announcing space that is not theirs, and many sub-prefix hijacks. It leaves gaps, which is why it is one layer among several alongside filtering and monitoring.

08How to check a prefix's RPKI status

RIPEstat exposes a validator through its public API. Pass the origin ASN and the prefix; the data.status field returns valid, invalid_asn, invalid_length or unknown. To find out whether your own ISP drops invalid routes, Cloudflare's isbgpsafeyet.com deliberately announces an invalid route and tests whether your browser can still reach it.

curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS3333&prefix=193.0.0.0/21'
# data.status: "valid"

curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS3333&prefix=193.0.0.0/22'
# data.status: "invalid_length"

curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64496&prefix=193.0.0.0/21'
# data.status: "invalid_asn"