What Is RPKI?

Your customers need their traffic to reach the right network. Resource Public Key Infrastructure (RPKI) helps by giving BGP routers a way to check which network is authorized to announce an IP prefix. It works for IPv4 and IPv6.

What RPKI does for your network

BGP exchanges routes between autonomous systems. RPKI adds signed authorization data, so a receiving network can check a route's origin ASN against the address prefix. That check is called Route Origin Validation (ROV).

For an ISP or hosting provider, the value is practical: reject announcements with an unauthorized origin before using them to carry customer traffic. Publishing your own authorizations also helps other networks recognize your intended announcements.

New to routing? Start with how BGP connects networks.

From a signed ROA to a routing decision

1. Publish the intended origin. A resource holder creates a Route Origin Authorization (ROA) for a prefix and ASN.
2. Validate the published data. Relying Party software checks certificates and signed objects against its trust anchors, then produces Validated ROA Payloads (VRPs).
3. Deliver the result to routers. A cache supplies the validated prefix, ASN and permitted length through RPKI-to-Router (RTR).
4. Apply your routing policy. The router compares received routes with the VRPs. Your configured policy decides how to use each result.

The validator does the certificate work; the router uses the resulting data. Publishing a ROA and filtering incoming routes are separate actions. Doing one does not automatically enable the other.

Read a ROA: prefix, ASN and maxLength

A ROA identifies an origin ASN and one or more prefixes. Each prefix can have a maximum length, which controls how specific an authorized announcement may be. With no maxLength specified, only that prefix length is authorized.

As a documentation example, a ROA for 203.0.113.0/24, origin AS64496, with maxLength 24 authorizes that exact /24. A different origin ASN does not match. A /25 from the same ASN also does not match that authorization.

Authorize the routes you actually plan to announce, including customer subprefixes and any legitimate additional origin ASNs. Separate precise ROAs make planned routes easier to inspect than a broad maxLength covering unused more-specifics. See the ROA guide and RFC9319's maxLength guidance.

Understand Valid, Invalid and NotFound

What the router's origin-validation result tells you

State	Meaning	Useful next step
Valid	At least one covering VRP matches the origin ASN and permits the prefix length.	Continue evaluating the route with your other BGP policies.
Invalid	At least one VRP covers the prefix, but none matches both origin and length.	Check the ASN, more-specific announcements and recent ROA changes.
NotFound	No validated VRP covers the prefix.	Apply your ordinary routing policy; missing authorization is different from a conflicting one.

A genuine customer route can become Invalid after a migration if its ROA still names the old ASN. Finding the mismatch quickly helps restore reachability. The state rules are specified in RFC6811.

Protect the origin and watch the path

With a matching ROA and a policy that rejects Invalid routes, ROV can block announcements from an unauthorized origin. Other networks must apply validation for that protection to operate along their routing decisions.

Keep watching the full path as well. A route leak can retain the authorized origin, and an attacker can forge an origin in the AS path. Ordinary ROA-based ROV checks the origin, not every hop. Prefix filters, relationship-aware export policy and route monitoring cover different parts of the customer journey.

Read how ROA validation helps against hijacking and the routing-security decision guide.

Put RPKI into everyday operations

• Prepare a clean route list. Include your aggregates, customer announcements, backup origins and DDoS mitigation arrangements.
• Publish before switching. Confirm new authorization in validators before changing the BGP origin or prefix length.
• Keep validation available. Use independent caches and observe session health, data age and expiry.
• Check the customer result. Compare external route visibility and service reachability before and after changes.

Follow the deployment steps or use the RPKI operations guide for an existing service.

Build growth on a stronger continuity foundation

RPKI data follows a certificate hierarchy. Independent validators improve local resilience, while the upstream authority still controls its certificate chain. Origin validation answers a routing question; it does not establish address ownership or replace the provider relationship behind continued service.

Keep your team focused on customers with Unlimited IPv4 and direct LARUS Continuity. LARUS brings the registry relationship into its first-party service. Lu Heng explains the continuity foundation.

Practical RPKI questions

Does RPKI work with IPv6?

Yes. ROAs support IPv4 and IPv6 prefixes. Keep both address families in your route inventory and deployment checks.

Can leased IPv4 use RPKI?

Yes. Coordinate the prefix and intended origin ASN with the party managing its ROAs. Check the published result before announcing the new capacity.

Does Invalid always mean an attack?

No. A wrong ASN, missing customer authorization or incorrect length can produce the same state. Compare the intended route with the validated data to find the cause.

Is RPKI one switch to turn on?

Plan two tasks: publish authorizations for your addresses and validate routes your network receives. Start with visibility, resolve legitimate mismatches, then introduce the intended filtering policy.