Shikanoko Networks (SKNK)
Back to blog

SKNK Technical Guide

What Is ROV? How Route Origin Validation Classifies BGP Routes

Route Origin Validation (ROV) compares a BGP announcement with validated RPKI data and classifies it as Valid, Invalid, or NotFound. Learn what each state means and what to check next.

RPKI is the data system that publishes cryptographically signed route authorizations. A ROA is the authorization record itself: which ASN may originate which prefix, and how specific the announcement may be. ROV is the judgment made at the receiving router — it compares an incoming BGP announcement with validated RPKI data and returns Valid, Invalid, or NotFound. Invalid does not automatically mean the route is unreachable, but many networks filter Invalid routes or lower their priority. NotFound is not Invalid; it only means no covering authorization was found.

Definition Box: Route Origin Validation (ROV) is the router-side process of comparing a BGP announcement with validated RPKI authorization data to determine whether the route origin is Valid, Invalid, or NotFound.

White-Face Xiaolu feeds one route letter into a sorting machine with three distinct, unlabelled exits: one continues onward, one meets a gate, and one falls into a tray.

ROV places every received route into one of three classes; what happens next is the receiving network's decision.

Where Does ROV Sit in the Whole Chain?

Before ROV ever runs, several other parties have to do their jobs. The full path looks like this:

White-Face Xiaolu turns a route-validation machine: a signed authorization goes in, a route is checked, and local policy has three possible exits.

A resource holder publishes a ROA; a validator turns it into VRP data; the router uses that data to classify a received route before local policy decides what to do.

Three details are worth making explicit, because they cause the most confusion:

  • The router usually does not do the cryptography itself. Validating the certificate chain and ROA signatures is the validator's job; routers consume that output and compare each received route against it. ROV is therefore only as fresh as the last validator sync.
  • ROV runs exactly at the point "I have seen the route, now how do I treat it?" It is a classification step on the receiving side — it does not create or announce routes.
  • The state alone decides nothing. Local routing policy decides the outcome — drop, deprioritize, tag, or log. Two networks can run the same ROV engine and act completely differently on the same state.

What Is RPKI? covers the system behind this chain, and What Is a ROA? covers the authorization record in detail.

RPKI, ROA, VRP, ROV: Four Words, Don't Mix Them

These four terms describe four different things. Confusing them is how operators end up debugging the wrong layer.

Term What it is Who is responsible for it What it does NOT mean
RPKI The overall framework of resource authorization and validation: certificates, repositories, signed objects, and the rules for checking them RIRs, resource holders, validator operators It is not a BGP protocol and does not carry routes
ROA One authorization record: a prefix, an Origin ASN, and an optional maxLength The party holding authority over the resource certificate It does not prove the route is live or being announced
VRP Validated ROA Payload (VRP) — the output of the validator, formatted so routers can compare routes against it Validator software It is not the original ROA; it is the validated, cached view of it
ROV The process of classifying a received BGP announcement using VRP The network receiving the route It does not validate the full AS_PATH or the route's quality

The shortest way to keep them straight: RPKI is the system, ROA is the permission slip, VRP is the checked copy of the slips the router can read, and ROV is the act of checking a route against that copy.

Valid, Invalid, and NotFound: What Each State Means

The comparison rules come from RFC 6811, which defines BGP Prefix Origin Validation.

State When it happens Operational meaning What to check next
Valid At least one covering authorization allows this prefix, this Origin ASN, and this prefix length The origin is authorized Continue with propagation, IRR, and upstream filter checks
Invalid (ASN) A covering authorization exists, but the announced Origin ASN does not match Often filtered by strict ROV policies Compare the actual origin ASN with the ROA
Invalid (Length) The Origin ASN matches, but the announcement is more specific than maxLength allows Often filtered by strict ROV policies Compare the actual announcement with maxLength
NotFound No covering authorization exists for this announcement No origin authorization conclusion was reached Confirm whether a ROA should exist at all

Two worked examples with documentation addresses

The examples below use 2001:db8:1234::/48 — part of the IPv6 documentation range — and private-use ASNs, so nobody mistakes the case for a real resource.

Example 1: a clean match.

ROA:  2001:db8:1234::/48, Origin AS65001, maxLength /48
BGP:  2001:db8:1234::/48, Origin AS65001
ROV:  Valid

The announcement matches the authorization exactly. ROV says the origin is authorized — nothing more: no claim about propagation, IRR objects, or acceptance.

Example 2: two ways to land in Invalid, and one way to land in NotFound.

ROA:  2001:db8:1234::/48, Origin AS65001, maxLength /48

BGP:  2001:db8:1234::/48, Origin AS65002   → Invalid (ASN)
BGP:  2001:db8:1234::/52, Origin AS65001   → Invalid (Length)
BGP:  2001:db8:1234::/48, Origin AS65001
      with no ROA published at all         → NotFound

The first announcement uses the wrong origin ASN. The second announces a /52 inside a block whose authorization caps at /48 — more specific than maxLength. The third has no covering authorization at all, so no conclusion can be drawn: that is NotFound.

The difference between the two Invalid flavors matters for troubleshooting: an ASN mismatch points at the origin routing design, while a length mismatch points at maxLength in the ROA. What Is a ROA? explains maxLength and why it is the most common source of operational mistakes.

Why Is the BGP Session Established but the Route Still Failing?

Walk the chain in order and ROV slots into one specific position:

  1. The BGP session comes up with your upstream.
  2. The router receives your prefix in a BGP update.
  3. ROV classifies the announcement — if it is Invalid, this is where things stop.
  4. The upstream applies its policy: reject the route, deprioritize it, or refuse to propagate it onward.
  5. Even when ROV returns Valid, the route can still be blocked by IRR filtering, a customer prefix whitelist, an export policy mistake, a broken next hop, or a propagation problem downstream.

White-Face Xiaolu operates a closed filter gate on an otherwise continuous connection, with a route envelope stopped at the gate.

An Established BGP session proves the connection is up; policy can still stop an individual route from being accepted or propagated.

So "Established but not working" has two very different stories: an Invalid route acted on by the upstream's ROV policy, or a route that is fine on origin but broken elsewhere in the chain. These tools help you tell the two apart:

What ROV Does Not Do

ROV answers exactly one question — is the announced origin authorized? Everything beyond that is outside its scope:

  • It does not validate the full AS_PATH. Only the route's Origin ASN is checked — typically the right-most ASN in the last segment of the AS_PATH. Intermediate ASNs are never examined by origin validation; that would be BGPsec's job, and BGPsec is not widely deployed.
  • It does not stop all route leaks. A leak that uses a correctly authorized origin ASN can still pass ROV. Origin validation filters a specific attack class; it is not a general anti-leak mechanism.
  • It does not guarantee global acceptance. Valid is a statement about authorization, not about whether every network will accept, propagate, or prefer the route.
  • It does not replace IRR Route Objects. IRR data feeds prefix filters and routing policy; ROV feeds origin classification. Most networks that filter on IRR data do so independently of ROV. See What Is an IRR Route Object?.
  • It does not prove commercial or contractual ownership. A valid authorization proves a resource-certificate relationship, not who paid for what or who holds the legal title.
  • "Invalid route" is not the same as "invalid ROA." A ROA can be perfectly well-formed and cryptographically sound while the route simply does not match it. Fixing the announcement and fixing the authorization are different tasks.

The Troubleshooting Order When a Route Is Invalid

When ROV reports Invalid, work through this list in order. Skipping ahead — for example, editing a ROA before recording what the router actually announced — usually wastes the first round of fixes.

White-Face Xiaolu uses a magnifying glass to compare a route card with an authorization template, while older cards wait to one side.

Start from the actual BGP announcement, then compare its prefix, length, and Origin ASN with the covering authorization before changing a ROA.

  1. Record the exact announcement. Write down the precise prefix, its length, and the Origin ASN as announced in BGP. Guessing from memory is how "it should be right" moments happen.
  2. Query the ROV state and covering authorizations. Use a validator or an RPKI lookup tool to see which ROAs cover the prefix and what they authorize.
  3. Check the ASN. Does the announced Origin ASN match the ASN in the covering ROA?
  4. Check the prefix length. Is the announcement more specific than maxLength? If yes, you either need to announce the less-specific prefix or add a separate ROA for the more-specific one.
  5. Check for old or conflicting ROAs. A leftover ROA can make a route Invalid only when no other matching VRP authorizes it.
  6. Confirm who actually has the authority to modify the ROA. This is not always you.
  7. Fix, then wait, then verify. After the authorization changes, publication, validator sync, and upstream policy refresh all take time. Re-check BGP visibility only after that settles — and verify from multiple public viewpoints.

A note for SKNK customers: if your prefix is an IPv6 PA /48 allocated by SKNK, the ROA authority is held by SKNK, not by you. Confirm that your actual Origin ASN matches the authorization on file — do not assume you can create or modify ROAs yourself in the RIPE Portal. Contact SKNK for any ROA change, and treat the turnaround time as part of your launch plan.

Common Misconceptions

"NotFound means the route is bad."

No. NotFound means no covering authorization exists — the system reached no conclusion. It is a gap in authorization data, not a judgment about the route.

"Valid means the route is reachable everywhere."

No. Valid is an origin-authorization result, not a reachability report. Propagation, acceptance, next hops, and the data plane are separate checks — a Valid route can still be invisible on the public Internet.

"If I have a ROA, I don't need IRR Route Objects."

Not necessarily. The ROA feeds ROV; IRR objects feed the prefix filters many upstreams still build. Whether IRR is required depends on what your upstreams and peers actually use. Keep the records your upstreams require; for many networks, that means maintaining both.

"Does ROV make BGP converge slower?"

ROV itself adds negligible delay to route processing. The delays that matter are operational: after you change a ROA, publication, validator refresh, and upstream policy updates take time. That is a propagation lag, not a protocol slowdown.

"I should drop every Invalid route from day one."

Not necessarily. Strict drop policies are a valid choice, but many operators start with a softer posture — logging, tagging, or deprioritizing Invalid routes — while they verify their own data is correct. A hard drop on day one can turn a small authorization mistake into an outage. Decide the policy deliberately, not by default.

"Can one prefix be covered by multiple ROAs?"

Yes. Multiple ROAs can cover the same prefix with different origin ASNs or different maxLength values. A route is Valid if at least one covering authorization matches it; a mismatch against one ROA does not matter if another covers the announcement. This is also why stale ROAs cause confusing Invalid results — but a leftover ROA only makes today's announcement Invalid when no other matching VRP authorizes it.

FAQ

What is the difference between ROV and RPKI?

RPKI is the framework — certificates, repositories, signed objects, and the rules for validating them. ROV is the process of comparing a received BGP route against validated RPKI data to produce Valid, Invalid, or NotFound.

What makes a route RPKI Invalid?

A covering ROA exists, but the announcement does not match it. Either the Origin ASN differs from the one in the ROA, or the announced prefix is more specific than the ROA's maxLength.

Does NotFound mean a route should be dropped?

Not automatically. Whether a NotFound route is accepted, deprioritized, or dropped depends on the receiving network's local policy.

Can a route be RPKI Valid but unreachable?

Yes, frequently. Valid only means the origin is authorized. The route can still fail IRR filtering, export policy, next-hop reachability, or propagation — read ROV results together with BGP observation.

Does ROV validate the whole BGP path?

No. It checks only the route's Origin ASN — typically the right-most ASN in the last segment of the AS_PATH. Intermediate ASNs are not examined.

Who can fix an Invalid ROA?

Only the party holding authority over the relevant resource certificate. If you hold the resources directly with the RIR, that is you. If your prefix comes from a Sponsoring LIR — for example a PA IPv6 /48 — the LIR holds the ROA authority. Confirm who can modify ROAs before you need a change during a launch.

Does ROV replace IRR filtering?

No. ROV classifies route origin authorization; IRR data feeds prefix filters and routing policy. They are separate systems with separate trust models, and neither makes the other redundant. RPKI vs IRR compares them in depth.

In One Sentence

ROV does not decide whether a route is "good"; it checks only whether the announced origin is authorized, then leaves the routing decision to each network's local policy.

Continue Reading

References