All five RIR trust anchors · refreshed every 10 minutes
RPKI Validator
NOC Operator Toolkit
Check whether an AS is authorised to originate a prefix, and see exactly which ROA decided it. Free. No API key. No rate limits (be reasonable).
Live Demo
Validate a route
Give it a prefix and the AS announcing it. Leave the AS out to see who the RPKI authorises instead, or enter an AS on its own to list every ROA it holds.
1,004,364 validated ROA payloads·refreshed 8m 32s ago·AFRINIC 31,678 APNIC 295,591 ARIN 269,462 LACNIC 44,848 RIPE 362,785
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
No authentication required. CORS headers are included on all responses.
GET/?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 authorise 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://notoolkit.com/?rpki=1.1.1.0/24&origin=AS13335" | jq .
# who is authorised to originate this prefix?
curl -s "https://notoolkit.com/?rpki=193.0.0.0/21" | jq .
# every ROA an AS holds
curl -s "https://notoolkit.com/?rpki=AS3333" | jq '.roas'
POST/
The same lookup with a JSON body.
curl -s -X POST https://notoolkit.com/ \
-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, normalised. 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 authorises this announcement. Non-empty exactly when the state is valid. |
| authorised_origins | The ASes the covering ROAs authorise, 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. |
FAQ
Common Questions
What is route origin validation?
The holder of a prefix publishes a signed Route Origin Authorisation 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 authorisations, and the answer is one of three:
Valid (a ROA authorises it), Invalid (a ROA covers the prefix but
does not authorise 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
authorise — 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.
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.
Is there an API?
Yes — see the documentation above.
GET /?rpki=1.1.1.0/24&origin=AS13335 returns
JSON, and no key or sign-up is needed. RPKI state also appears on every path in the
looking glass, alongside what the IRR says.