RPKI and ROA: Authorize and Verify an IPv4 Origin
RPKI lets a resource holder publish signed Route Origin Authorizations (ROAs) for its prefixes. A ROA identifies a permitted origin ASN and prefix length. Publish the intended authorization, verify its visibility in validation data, then coordinate the BGP change with your upstreams.
What the validation state tells you
Routers use validated prefix-origin data derived from RPKI to classify announcements into three states:
| State | Meaning | Operator check |
|---|---|---|
| Valid | At least one covering authorization matches the origin and permits the announced length | Confirm it matches your intended routing plan |
| Invalid | Covering authorization exists, but none matches both origin and length | Compare the actual origin and prefix length with all covering records |
| NotFound | No validated authorization covers the prefix | Confirm whether publication is missing or not yet visible |
One matching authorization is enough for Valid, even if another covering record differs. A wrong origin can be Invalid rather than NotFound because a less-specific ROA covers the route.
Validation does not prove the entire AS path, prevent every route leak, or guarantee forwarding. Creating a ROA also does not turn on validation or filtering on your own routers. Router-side validation deployment remains a separate task.
Before publishing
Have the actual prefix-origin plan, access to the resource holder’s RPKI service, an inventory of current announcements and a rollback plan. For leased space, the holder or its authorized administrator controls publication; tenant access is an arrangement to confirm, not an automatic right.
A letter of authorization and an IRR route object serve separate purposes. Check each requirement with the upstream.
Inventory existing and planned announcements
List every exact prefix and origin, including less-specific aggregates, intended more-specific routes and temporary migration origins. Check existing authorizations before adding one: the first covering ROA can make an existing route Invalid if its origin or length is omitted.
Example: 192.0.2.0/24 originated by documentation ASN AS64496. If providers A and B only carry it, both paths retain origin 64496. If the provider will originate the prefix under its own ASN, that is a different authorization plan.
Confirm RPKI control and choose exact authorizations
A ROA binds one origin ASN to one or more prefixes, with optional maximum lengths. Prefer authorizations for the routes you actually intend to originate.
For the example, authorize prefix 192.0.2.0/24, origin 64496, with an effective maximum length of 24. Depending on the portal, that means omitting an optional maxLength or entering 24 explicitly.
Avoid setting a broad maximum just in case. For example, 192.0.2.0/24 with maxLength: 25 also permits its /25 more-specific routes for that origin. Separate exact-prefix entries can limit authority to the routes you intend, including planned exceptions for mitigation services. Authorization does not override a network’s prefix-length filters.
Publish through the applicable registry service
These hosted-service entry points were checked on 15 November 2026. Account eligibility, privileges and portal labels can change. Use the current instructions linked by the NRO’s guide to all five registries.
| Registry | Where to start | Before committing |
|---|---|---|
| RIPE NCC | RPKI Dashboard; create a hosted certification authority if needed, then create the ROA | Review affected announcements and any invalidation warning |
| ARIN | ARIN Online, Routing Security; enroll the eligible resources in hosted RPKI, then create the ROA | Check the selected organization, origin and prefixes |
| APNIC | MyAPNIC, RPKI / Route Management; use an account with the required privilege and MFA | Review pending changes and commit the intended ROA publication |
| LACNIC | The holder’s RPKI service; create a ROA using the current hosted instructions | Check the prefix, origin and maximum length |
| AFRINIC | MyAFRINIC, Resource Certification; activate the service where required and issue the ROA | Check the resources, origin and applicable validity fields |
Some portals offer both IRR and ROA options. Verify which records you are publishing. For a delegated certificate authority, use that system’s publication workflow rather than assuming the hosted portal controls it.
Verify the published origin authorization
Check the intended pair independently of the portal. This read-only example uses the documented RIPEstat validation API:
curl --fail --silent --show-error --get \
'https://stat.ripe.net/data/rpki-validation/data.json' \
--data-urlencode 'resource=AS64496' \
--data-urlencode 'prefix=192.0.2.0/24' \
| jq '.data | {status, description}'The prefix and ASN are documentation values, not a live success test. Replace them with the planned pair. RIPEstat reports valid, invalid_asn, invalid_length or unknown; its unknown corresponds to no covering authorization in that view.
Check through another validator or the upstream’s own view and record observation times. A Valid result for a proposed pair does not prove the route is currently announced. Repository publication, validator refresh and router updates run on different schedules.
Change BGP and remove obsolete authorizations
For an origin migration, publish authorization for the new origin while retaining the old one for the explicitly approved overlap. Verify the new pair before changing BGP. Both origins can be valid during that window; this is a deliberate permission, not an error by itself.
After cutover, confirm the observed origin and traffic, wait through the agreed rollback period, then retire obsolete ROAs and IRR objects with their administrators. A resource transfer can also change certification authority; coordinate with both holders and the registry instead of assuming every transition can use the same overlap.
Worked example: changing the origin ASN
Assume the same authorized holder can publish for documentation prefix 192.0.2.0/24 throughout the change. The old origin is AS64496; the approved new origin is AS64499. This is an illustrative migration plan, not a recorded production change. For a registry transfer that changes certification control, agree a different handover sequence with the registries and both holders where needed.
| Stage | Published authorization and routing state | Verification and action |
|---|---|---|
| Before the change | Exact /24 authorization for 64496; BGP still originates from 64496 | Old pair is Valid; preserve its working state as the agreed rollback |
| Prepare new origin | Add an exact /24 authorization for 64499 while retaining the approved old one; stage the new IRR record and upstream filter | Validate the proposed new pair independently; confirm the provider is ready before changing BGP |
| Cut over | Both intended origins remain authorized during the agreed window; change the actual BGP origin to 64499 | Observe 64499 from relevant external networks and test service traffic and the return path |
| Recover if acceptance fails | The agreed old authorization and routing arrangement remain available | Restore the approved old BGP origin through the responsible operator; recheck traffic before retrying |
| Complete | New origin works and the rollback period ends | Remove obsolete permission and IRR records for 64496, then confirm the intended published and observed state |
Two transit providers carrying the new origin do not themselves require two additional origin authorizations. Add a provider’s ASN only if that provider is intentionally originating the prefix.
Stage the new origin permission before changing BGP, verify the new route and service, then retire obsolete permission after the agreed rollback window. This conceptual example assumes the same authorized holder retains publication control. ROA values show permitted origin ASNs; BGP values show the intended observed origin. The ASNs and prefix are reserved for documentation.
View full diagram
Failure case: the IRR changed before the ROA
Suppose the IRR object now names AS64499 and BGP has moved to 64499, but the only validated covering authorization still permits 64496. The new announcement is Invalid, because a covering record exists and none matches the new origin. The IRR update does not change that result.
Confirm the intended origin with the holder and upstream, then publish the approved matching authorization or use the agreed rollback if service cannot wait for publication and refresh. Recheck the validator and provider views before resuming. Do not delete all ROAs to make the warning disappear, or widen maxLength when the actual error is the ASN.
If both exact-prefix origins are intentionally authorized and visible to the validator, either matching origin can be Valid. A remaining old authorization does not make a matching new route Invalid. Conversely, Valid does not mean the old permission is still needed: retire it at the agreed removal point.
Use the prefix-announcement runbook for upstream acceptance and forwarding checks. If a validation check fails, compare the published data with the intended origin before changing it; widening maxLength or deleting all authorizations can conceal the actual mistake.
When arranging IPv4 address services, confirm who controls RPKI publication, who can request changes and how the upstream will verify readiness. No fixed publication time follows from acquiring the addresses.