Skip to main content

IPv4 guide

RPKI and ROA: Route Origin Authorization Explained

RPKI lets resource holders authorize route origins. A ROA names an origin ASN, one or more IP prefixes and their allowed lengths. Route Origin Validation checks announcements against validated authorizations; each network's routing policy decides what happens next.

What is RPKI?

Resource Public Key Infrastructure links Internet number resources to cryptographic keys through resource certificates. Relying-party validators check certificates and signed objects against configured trust anchors. A resource certificate establishes authorization over covered resources; it does not certify a customer's identity, reputation or service quality.

What is a ROA?

A Route Origin Authorization is a signed object authorizing one ASN to originate its listed IPv4 or IPv6 prefixes. The signing certificate must cover those prefixes; the ASN can belong to another organization. Validated ROA Payloads (VRPs) carry prefix, origin ASN and maximum length to the routing system. A ROA can contain multiple prefixes; multiple ROAs can authorize different origins for the same prefix.

How Route Origin Validation works

Validation of one route against the available VRPs
StateConditionOperational meaning
ValidAt least one covering VRP matches the origin ASN and permits the announced prefix length.Origin authorization matches; other routing filters still apply.
InvalidAt least one VRP covers the route, but none matches both ASN and permitted length.Investigate the mismatch. A network with a reject-Invalid policy drops this route.
NotFoundNo VRP covers the route.No covering authorization in this data set; acceptance still depends on policy.

Coverage includes a less-specific parent prefix. One matching VRP is sufficient for Valid even if another covering VRP does not match. Invalid is a validation result, not an automatic rejection instruction. RFC 6811 separates validation from local routing policy. Different validators can temporarily see different records.

Protection and its limits

ROAs support filtering of unauthorized route origins where networks apply that policy. ROV does not authenticate the full AS path, encrypt traffic, prevent every route leak or prove reachability. An attacker can forge a path ending in an authorized origin. A Valid route can still fail provider prefix filters or lack a working return path. ROA publication and ROV deployment are separate activities.

Hosted versus delegated RPKI

In a hosted service, the registry operates the CA and signing infrastructure; authorized account users manage the intended authorizations. In a delegated model, an organization operates its own CA and arranges publication, renewal and monitoring. ARIN documents delegated participants issuing resource certificates to downstream customers. A lease alone grants neither portal access nor a delegated certificate: verify the actual authority chain, covered resources and operator permissions.

Get maxLength right

When maxLength is omitted, only the listed prefix is authorized. A larger value also permits every contained prefix down to that length for the named ASN. RFC 9319 recommends minimal ROAs for the prefixes actually originated, rather than broadly authorizing unused subprefixes.

Documentation-only example: 203.0.113.0/24 and AS64496
AuthorizationWhat it permits
/24, maxLength omittedOnly 203.0.113.0/24 from AS64496.
/24, maxLength 25The /24 and both contained /25s from AS64496.
Explicit /24 and 203.0.113.0/25 entries, maxLength omittedOnly those two prefixes; the other /25 is not authorized by these entries.

These reserved addresses and ASN illustrate authorization, not deployable routes. RPKI validity does not make an IPv4 /25 globally accepted. Confirm upstream filters and coordinate planned more-specifics before changing announcements. Do not widen maxLength to diagnose an unrelated reachability problem.

Diagnose an unexpected result

  1. Record the observed prefix, length, origin ASN, validator, time and upstream symptom.
  2. Inspect every covering VRP, including parent prefixes and other origins. Compare with the intended route.
  3. Check publication, resource-certificate validity, validator refresh and router-cache state.
  4. Ask the authorized operator to correct the specific record or routing mistake, then verify propagation and reachability independently.

Deleting one ROA does not imply NotFound: another covering authorization may leave the route Valid or Invalid. Loss or expiry of an object's supporting certificate changes the usable VRP set as validators refresh. Avoid blanket deletion or disabling validation as a routine fix.

RPKI for leased IPv4 space

Identify who requests, approves, publishes and verifies each change. This may be the holder's hosted-service operator or a properly delegated downstream CA; never infer the model from the lease or a ROA screenshot. Record the prefix, actual origin ASN, specific announcements, authorization scope, normal and emergency response times, escalation contact, renewal monitoring and exit procedure. These are terms to agree, not i.lease service guarantees.

Is RPKI required by my network?

Check the applicable provider requirements and registry service conditions. There is no universal routing policy implied by publishing a ROA. Coverage statistics alone do not show which paths reject Invalid routes or whether your service works.

Prepare and verify a change

If you hold the prefixes

  1. Inventory active routes, authorized origins, covering records and rollback requirements.
  2. Publish the intended minimal authorizations and verify them through fresh validator data before a planned routing change.
  3. Confirm router state, provider acceptance and service reachability after the change. Remove obsolete authorization only after the old origin is no longer needed, accounting for propagation.

For deliberately unannounced space, evaluate an AS0 ROA under the applicable operational procedure. AS0 expresses that no ordinary origin is authorized by that record; it is not an absolute veto if another VRP matches. Plan authorization before bringing the space into use.

If you lease the prefixes

  1. Agree publication authority and an emergency change path before onboarding.
  2. Test intended prefix/origin pairs against the published VRPs; a not-yet-announced route is not an observed BGP Valid route.
  3. Coordinate ASN or upstream changes, lease expiry, route withdrawal and removal of obsolete ROAs. Check the remaining covering records.

A registry transfer is a separate transition. ARIN removes transferred resources and associated ROAs from the source certificate. Follow the receiving registry's procedure and coordinate new authorization with the transfer and route change; do not assume the seller's ROAs survive.

Prepare an IPv4 operating request

Include the prefix, RIR, origin ASN, current validation evidence and timestamp, authority model, intended change and timing. Do not send private keys or account credentials. Discuss IPv4 routing responsibilities or review managed IPv4 leasing. Any publication or response commitment must be agreed for your resource.

Verify authorization and delivery separately

Keep the resource holder, ROA operator and network operator aligned through every change. A correct record, a refreshed validator, an accepted route and a reachable service are different checks.

Frequently asked questions

What does RPKI stand for?

Resource Public Key Infrastructure.

What is a ROA in networking?

A signed Route Origin Authorization for an ASN and listed prefixes.

Who can create a ROA?

An authorized hosted-service operator or a CA with a valid resource-certificate chain covering the prefixes. A lease does not create that authority.

Does RPKI encrypt traffic?

No. Origin validation does not provide traffic confidentiality.

What is maxLength?

The longest prefix length permitted by an entry. Omission authorizes only that entry's exact prefix.

What does Invalid mean?

There is coverage but no matching authorization in the available VRPs. It is not proof of an attack.

Is RPKI mandatory?

Verify your provider and registry requirements; do not infer a universal mandate.

Can a ROA name another organization's ASN?

Yes. Authorization over the prefix and ownership of the origin ASN are different.

Who creates ROAs for leased space?

The operator with verified hosted or delegated authority. Name that operator in the operating agreement.

What happens on expiry?

Recompute the route's state from the usable VRPs after refresh; remaining coverage determines the outcome.

Does RPKI replace an LOA?

No. Confirm the provider's LOA and IRR requirements separately.

Standards and related guidance