BGP & Routing

RPKI Validator

Check if a BGP route is authorized via Resource Public Key Infrastructure (RPKI). Verify ROA validity for any ASN and prefix pair.

Validate Route Origin

About RPKI Route Validation

RPKI (Resource Public Key Infrastructure) is a cryptographic security layer for BGP that allows IP address holders to create digitally signed Route Origin Authorizations (ROAs). A ROA specifies which ASN is authorized to announce a given IP prefix, preventing BGP route hijacking.

Validation States

Valid: A ROA exists that matches the announcement — the origin ASN is authorized and the prefix length is within the allowed range. Routers should accept and prefer these routes.
Invalid: A ROA exists but the announcement violates it — either the wrong ASN is originating, or the prefix is more specific than the ROA's max-length allows. Routers should drop these routes (Route Origin Validation, ROV).
Not Found (Unknown): No ROA covers this prefix at all. Most networks pass these routes currently, but filtering "not found" is increasing as RPKI adoption grows.

Why RPKI Matters

BGP route hijacks — where an AS maliciously or accidentally announces IP prefixes it doesn't own — have caused major internet outages and security incidents. RPKI's Route Origin Validation (ROV) allows routers to automatically reject invalid announcements, making the internet's routing infrastructure significantly more secure. Major networks like Comcast, AT&T, and most Tier-1 providers now enforce RPKI-invalid route rejection.

Expert guide · RPKI Validator

What it does

The RPKI Validator checks one route, an origin ASN plus a prefix such as AS13335 and 1.1.1.0/24, against the published Resource Public Key Infrastructure. It asks the RIPE NCC validation API for the Route Origin Validation state and falls back to RIPEstat's rpki-validation data if that service does not answer. The result is the RFC 6811 state (valid, invalid or not found), a short explanation, and the list of matching Validated ROA Payloads with their ASN, prefix and maxLength.

Why it matters

Reachability today: Major transit providers and many access networks drop RPKI-invalid routes, so an invalid state is not a warning but a partial outage for your prefix.
Change safety: Before moving a prefix to a new upstream, a DDoS scrubbing service or a different origin ASN, checking the new pair prevents announcing something your own ROA makes invalid.
Hijack resistance: A correct ROA turns an origin hijack of your space into an invalid route that validating networks discard automatically.
Customer and lease vetting: Providers can verify that a customer's announcement is authorized by the address holder before accepting it.
Compliance evidence: Auditors and large customers increasingly ask for proof that your prefixes are covered by ROAs, and the VRP list is that evidence.

How to read the results

VALID: At least one VRP covers the prefix, lists the same origin ASN, and has a maxLength equal to or longer than the announced prefix length.
INVALID: One or more VRPs cover the prefix but none match, either because the origin ASN differs or because the prefix is longer than the maxLength allowed; validating networks will drop it.
NOT FOUND: No VRP covers the prefix at all; the route is treated normally by almost everyone, but it has no protection against origin hijacks.
Matched VRPs table: Each row shows the ASN, prefix and Max Length of a ROA payload that matched; when the fallback source answered, only matching payloads are listed.
Description: The validator's own explanation, which often names the reason for an invalid result, such as an origin mismatch or a length beyond maxLength.

Technical background

The Resource Public Key Infrastructure (RFC 6480) is a certificate hierarchy that mirrors address delegation. The five RIRs operate trust anchors; each member receives a resource certificate listing the prefixes and ASNs it holds and can use it to sign objects. The most important object is the Route Origin Authorization, profiled in RFC 6482 and updated by RFC 9582: a signed statement that a given AS may originate a set of prefixes, each with an optional maxLength. Relying-party software, such as Routinator, rpki-client or FORT (developed with support from LACNIC and NIC México), downloads every repository, checks signatures and validity periods, and produces a flat list of Validated ROA Payloads: ASN, prefix and maxLength. Routers receive that list over the RPKI-to-Router protocol (RFC 6810, version 1 in RFC 8210).

RFC 6811 defines how a router uses VRPs. A VRP covers a route if the VRP prefix contains the route prefix. A route is Valid if any covering VRP has the same origin ASN and a maxLength at least as long as the route. It is Invalid if covering VRPs exist but none match. It is NotFound if nothing covers it. Example: a ROA for 203.0.113.0/22 with origin AS64500 and maxLength 22 makes 203.0.113.0/22 from AS64500 valid, 203.0.113.0/24 from AS64500 invalid because of length, and 203.0.113.0/22 from AS64501 invalid because of origin. Policy is up to each network, but the common practice now is to drop invalids and accept everything else.

maxLength is where most mistakes happen. Setting maxLength 24 on a /22 seems convenient because it pre-authorizes every /23 and /24, but it also lets an attacker announce one of those /24s with your ASN forged as origin; the route is RPKI valid and wins by longest match. RFC 9319 therefore recommends avoiding maxLength except when every authorized more-specific is actually announced, and instead creating one ROA entry per prefix you really originate. An AS0 ROA (RFC 6483, RFC 7607) states that a prefix must not be routed at all, which is useful for unused or reserved space.

ROV only checks the origin. It cannot detect a forged path or a route leak. ASPA, Autonomous System Provider Authorization, is being standardized in the IETF SIDROPS working group as a draft: each AS signs the list of its upstream providers, and routers can verify that a received AS_PATH is plausible. BGPsec (RFC 8205) offers full path signing but has seen almost no deployment.

Creating ROAs is done in the RIR portal; in LACNIC's region that means the hosted RPKI system in MiLACNIC or, for countries with a national registry, the NIC.br or NIC México interface. Publish ROAs before you announce, re-check after any routing change, and remember that validators cache data, so new ROAs typically take minutes to an hour to reach routers worldwide.

Common errors and how to fix them

Problem Announcing a /24 out of a /22 whose ROA has maxLength 22, making the more-specific invalid and unreachable on networks that enforce ROV.: Fix Add a ROA entry for the /24 with the correct origin, or stop announcing the more-specific; avoid simply raising maxLength on the /22 because that weakens protection for the whole block.
Problem Moving traffic to a DDoS mitigation provider that announces your prefix from its own ASN, which your ROA does not authorize.: Fix Create an additional ROA for the provider's ASN covering the prefixes it may announce, ideally before an attack, and remove it if the contract ends.
Problem ROAs created with the wrong ASN after a merger, migration or typo, turning every route invalid at once.: Fix Validate each origin/prefix pair here or with a local validator before and after editing ROAs, and keep the old ROA in place until the new announcement is confirmed valid.
Problem Using maxLength 24 everywhere 'for flexibility'.: Fix Follow RFC 9319: list each announced prefix explicitly with maxLength equal to its length, so forged-origin sub-prefix hijacks remain invalid.
Problem Leased or transferred space keeps an old ROA from the previous holder.: Fix The current resource holder must revoke stale ROAs and issue new ones for the lessee's ASN; verify that no VRP for the old origin remains before announcing.

Do it from the command line

macOS

# ROV state for an origin/prefix pair from RIPEstat
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS13335&prefix=1.1.1.0/24" | python3 -m json.tool | grep -E '"status"|max_length|origin'
# Same check against a locally running Routinator instance
routinator validate --asn AS13335 --prefix 1.1.1.0/24

Windows

# Validation state with PowerShell
(Invoke-RestMethod "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS13335&prefix=1.1.1.0/24").data | Select-Object status,validating_roas
# Check a more-specific to see maxLength effects
(Invoke-RestMethod "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS13335&prefix=1.1.1.0/25").data.status

Linux

# All VRPs your validator holds for a prefix
routinator vrps --format csv -p 1.1.1.0/24
# Run rpki-client with JSON output and count the VRPs it produced
sudo rpki-client -j && jq '.roas | length' /var/db/rpki-client/json
# On an FRRouting router, list routes that are invalid
vtysh -c 'show bgp ipv4 unicast rpki invalid'

Frequently asked questions

What do RPKI valid, invalid and not found mean?

Valid means a published ROA authorizes that origin ASN to announce that prefix at that length. Invalid means ROAs exist for the address space but none authorizes this combination, either because the origin differs or the prefix is too specific. Not found means no ROA covers the prefix at all. Networks that enforce ROV drop invalid routes and accept the other two.

How do I create a ROA?

Log in to your RIR's member portal, open the RPKI section, enable hosted RPKI if needed, and create a ROA listing your origin ASN, the prefix and a maxLength equal to the prefix length you announce. In Latin America this is done in MiLACNIC, or at NIC.br or NIC México for their members. Then verify the pair here; propagation to validators usually takes minutes to an hour.

What maxLength should I use in my ROA?

Use the exact length you announce. If you announce a /22, set maxLength 22. If you also announce two specific /24s, add those two prefixes explicitly rather than raising maxLength to 24 for the whole block. RFC 9319 explains that a loose maxLength lets attackers announce unused more-specifics with your ASN as a forged origin and still be considered valid.

Will creating a ROA break my routing?

Only if it contradicts what you actually announce. Before publishing, list every prefix and origin you and any provider, scrubbing service or customer announce for that space, and make sure each one will be valid. Missing one turns it invalid and it will be dropped by networks that enforce ROV. Done carefully, creating ROAs has no downside and protects against origin hijacks.

Does RPKI stop all BGP hijacks?

No. Route Origin Validation stops announcements with the wrong origin ASN, which covers most accidental and many malicious hijacks. It cannot detect an attacker who forges your ASN at the end of the AS_PATH, nor route leaks of valid routes. ASPA, still an IETF draft, and BGP roles from RFC 9234 address those gaps, together with good prefix filtering.