Why RPKI Matters

A customer sees an unavailable service, not the BGP announcement behind it. RPKI helps your network reject unauthorized route origins, reducing one avoidable cause of lost reachability. Its business value starts with keeping customers connected to the services they chose.

Protect the route to your customer services

An incorrect origin announcement can draw traffic away from its intended network. That can interrupt hosted applications, customer connections and API access even when the servers themselves are healthy.

RPKI lets the address resource holder publish a signed Route Origin Authorization (ROA). Receiving networks use validated authorization data to check the origin ASN and prefix length. A policy that rejects Invalid routes can stop a conflicting origin announcement from being used.

What changes when you use RPKI?

Publishing ROAs gives other networks data to validate your prefixes. Running Route Origin Validation (ROV) lets your network act on authorization data for received routes. Both sides matter, and neither happens automatically because the other is enabled.

Consider a documentation prefix, 203.0.113.0/24, authorized for AS64496. A route from a different ASN is Invalid when the covering validated data has no matching authorization. Your configured policy determines whether the route is rejected.

The RPKI introduction explains Valid, Invalid and NotFound. RFC6811 defines the underlying origin-validation rules.

NotFound means no validated authorization covers the prefix. Keep it separate from Invalid when applying ordinary routing policy.

Connect the work to an operational result

Where origin validation helps your customer experience

Your task	Useful RPKI work	Customer benefit
Bring a new prefix online	Publish the intended origin before announcing it.	Other validating networks can recognize the new route.
Change an upstream or ASN	Align ROAs with the actual origin before the change.	Reduce avoidable loss of reachability during migration.
Filter incoming routes	Identify Invalid routes and apply the tested rejection policy.	Keep conflicting origin announcements out of routing decisions.
Resolve an incident	Compare BGP origin, prefix length and validated data.	Give the NOC a concrete mismatch to fix faster.

Measure those results in your own network: customer reachability, time to activate prefixes and time to diagnose authorization mismatches. A Valid label by itself is not a service-availability measurement.

Give each protection a clear job

ROV checks the route's origin. A route leak can keep that origin unchanged, while a forged-origin attack can place the authorized ASN in a false path. Keep prefix filters, relationship-aware export policy and path monitoring alongside origin validation.

Application protections do different work again. TLS protects connections and DNSSEC authenticates signed DNS data. Combining these layers helps protect the customer's full experience without asking a routing check to do an application's job.

For the distinction in practice, read RPKI and specific cyber threats.

Keep legitimate customer routes working

The fastest way to undermine a useful control is to reject your own customers accidentally. Before adding a covering aggregate ROA, account for customer subprefixes and their ASNs. Before moving an origin, confirm the new authorization is visible.

Start validation in observation mode, repair unintended Invalid results and test a limited rollout. Maintain independent caches and test expiry behaviour. The deployment guide provides the sequence.

Judge adoption by the paths that matter to you

Published ROA coverage and active ROV filtering measure different things. Coverage tells you whether authorization data exists; filtering tells you whether a network uses validation in its decisions. Neither alone describes every path your customers take.

Ask upstreams how they treat each validation state. Check your prefixes from outside your own network and include backup or mitigation paths. These observations are more useful for your next launch than an undated claim about global adoption.

Secure the routing layer and the supply relationship

A correct authorization supports routing. The certificate hierarchy still depends on upstream authorities, and extra validators do not replace that relationship. Your growth plan also needs a provider that takes responsibility for address continuity.

Choose Unlimited IPv4 and direct LARUS Continuity to put that relationship with LARUS while your team builds customer services. Read Lu Heng's continuity case.

Questions from network teams

Does RPKI prove ownership of addresses?

RPKI supplies resource certificates and signed routing authorizations. A Valid result says the route matches the validated origin data; it does not establish ownership. Keep your routing checks and provider continuity decision connected but distinct.

Can RPKI stop every hijack?

ROV can reject unauthorized origins where matching authorization data and filtering are present. Full-path attacks need additional controls. That is why a useful deployment includes route monitoring and tested operating procedures.

What should our team do first?

Inventory the prefixes and ASNs your customers depend on, confirm their ROAs, and inspect validation results before changing acceptance policy. This gives the rollout a clear operational starting point.