RPKI Validator
Check whether an AS is authorized to originate a prefix, and see exactly which ROA decided it. Free. No API key. No API rate limits you’ll ever reasonably hit.
Live Test
Validate a route
Give it a prefix and the AS announcing it. Leave the AS out to see who the RPKI authorizes instead, or enter an AS on its own to list every ROA it holds.
1,014,505 validated ROA payloads·refreshed 1m 15s ago·AFRINIC 31,856 APNIC 297,796 ARIN 273,457 LACNIC 45,655 RIPE 365,741
Examples:
1.1.1.0/24 · AS13335
8.8.8.0/24 · AS15169
wrong origin
2606:4700::/32
every ROA of AS3333
Enter a prefix above and click Validate to see the response.
Reference
API Documentation
The parameters and fields for this tool. Keys, errors, CORS and rate limits work the same for every tool: see the API guide.
GET/v1/rpki/{prefix}?origin={asn}
Validate a prefix and origin AS against the current validated ROA set. Without origin, the response lists the covering ROAs and the ASes they authorize instead of returning a state.
| Parameter | Type | Description |
|---|---|---|
| rpki | string | An IPv4 or IPv6 prefix, a bare address (validated as its own host route), or an AS number to list that AS's ROAs. |
| origin | string | Optional. The origin AS to validate against, as 13335 or AS13335. asn is accepted as an alias. |
# validate a route
curl -s "https://api.notoolkit.com/v1/rpki/1.1.1.0/24?origin=AS13335" | jq .
# who is authorized to originate this prefix?
curl -s "https://api.notoolkit.com/v1/rpki/193.0.0.0/21" | jq .
# every ROA an AS holds
curl -s "https://api.notoolkit.com/v1/rpki/AS3333" | jq '.roas'
POST/
The same lookup with a JSON body.
curl -s -X POST https://api.notoolkit.com/v1/rpki \
-H 'Content-Type: application/json' \
-d '{"rpki":"1.1.1.0/24","origin":"AS13335"}' | jq .
GETResponse fields
| Field | Description |
|---|---|
| prefix | The prefix that was validated, normalized. A bare address becomes a /32 or /128. |
| origin_asn | The AS it was validated against, or null when none was given. |
| state | valid, invalid or not-found: the RFC 6811 outcome. null when no origin was given. |
| reason | A sentence explaining the state. For invalid it says which of the two ways it got there. |
| covering_roas | Every ROA whose prefix covers this one, most specific first, each with its max_length, asn and trust anchor. |
| matched_roas | The subset that actually authorizes this announcement. Non-empty exactly when the state is valid. |
| authorized_origins | The ASes the covering ROAs authorize, whether or not you asked about one of them. |
| rpki | How many payloads the set holds, when it was refreshed, and whether that copy is stale. |
| aspa | AS queries only: the AS’s ASPA: published, the providers it names, and customer_count, how many ASes name it. null when ASPA data is unavailable. |
FAQ
Common Questions
What is route origin validation?
The holder of a prefix publishes a signed Route Origin Authorization naming the AS
allowed to originate it and how specific the announcement may be. Validating a route is checking its
prefix and origin AS against those authorizations, and the answer is one of three:
Valid (a ROA authorizes it), Invalid (a ROA covers the prefix but
does not authorize this announcement) or NotFound (nobody has published a ROA at all).
My route is Invalid and I didn’t expect that.
There are only two ways to get there. Either the prefix is being announced by an AS its holder did not
authorize (a hijack, a leak, or more often a transit arrangement nobody updated the ROA for),
or the announcement is more specific than the ROA’s maximum length allows.
The second is much the more common, and is usually self-inflicted: a ROA written with
maxLength equal to the prefix length makes every deaggregated announcement of that
space Invalid the moment you start announcing one. This tool says which of the two it is.
NotFound isn’t a failure, is it?
No. It means no ROA covers the prefix, so RPKI has nothing to say about it either way. Plenty of
the internet is still in this state, and networks that filter on RPKI drop Invalid
routes while accepting NotFound ones. It is not a reason to worry, but it is a reason to publish a ROA.
My origin is Valid. Does that mean the route is fine?
Only that the right AS is announcing it. Origin validation says nothing about the rest of the AS path,
which is where route leaks happen: a leaked route keeps its genuine origin and stays Valid here. To check
the path itself, use the ASPA validator, which tests every hop against the
providers each AS has published.
Where does the data come from?
From Routinator, running here as part of NoToolkit. It fetches the repositories of
all five RIR trust anchors, validates every certificate chain and signature itself, and produces the
validated payload set this tool answers from. Nothing is taken on trust from a third-party API.
I just published a ROA and it isn’t showing.
Give it a while. The copy here is refreshed every ten minutes and its age is shown above the box, but
the slow part is upstream: your RIR has to publish the new object into its repository first, and every
relying party on the internet then picks it up on its own schedule. Minutes to a few hours is normal,
and that delay is the reason to publish a ROA before you start announcing, not after.