RPKI Route Origin Validation Explained: How ROAs Flag Wrong-Origin Routes

Traffic for those addresses can flow to the wrong network. This is called a BGP hijack. BGP, the Border Gateway Protocol, is how networks tell each other which addresses they can reach, and it largely believes what neighbours announce.

RPKI route origin validation is the standard check for one form of it: a network announcing addresses as if it started them, when the holder never allowed it. It catches accidents far better than deliberate attacks, for reasons this guide shows.

Picture a common setup. A payment gateway in Pune runs its own network, numbered AS64501, with one block of addresses, 203.0.113.0/24. It handles about Rs 30 crore (300 million rupees) of payments a day. The setup is made up, but the problem is real.

One Tuesday, a small hosting firm's network, AS64505, mistyped a router setting and announced 203.0.113.0/24 as its own. For 40 minutes (made up), part of the internet sent the gateway's traffic there, and about 9,000 payments failed.

The gateway's internet provider, AS64510, already ran route origin validation, yet it could not help. The gateway had never published a ROA, the signed record of who may announce its addresses. Without one, the wrong route looked no worse than the real one.

Picture a postal network where any post office can claim that letters for PIN code 411001 should come to it. Neighbouring offices pass the claim along, and nobody checks a register. This guide is about adding that register, and the clerk who checks it.

• Autonomous system (AS): one network run by one operator, such as an internet provider. Each has an AS number, like AS64501.
• Prefix: a block of IP addresses, like 203.0.113.0/24. A bigger number after the slash means a smaller block: a /25 is half a /24.
• Route: a BGP announcement that says this prefix can be reached through this list of networks.
• AS path: the list of AS numbers a route has passed through. The last one is the origin AS, the network that first announced it.
• RPKI (Resource Public Key Infrastructure): signed certificates recording who holds which addresses and AS numbers.
• Validator: software that downloads RPKI data, checks the signatures and hands clean results to routers.
• RFC: a numbered standards document from the IETF, the body that writes internet standards.

RPKI route origin validation (ROV) is a check a router runs on each BGP route it receives. It compares the route's prefix and origin AS with signed records published by the address holders. The result is one of three labels, and each operator decides what the labels mean for routing.

RPKI itself is the signing system underneath. It mirrors how addresses are handed out, so only the holder of a block can sign records about that block.

In the postal picture, the PIN code is the prefix, the register is RPKI and the clerk is the router running ROV. Where the picture breaks: the clerk checks only the office that first made the claim, never the offices that relayed it. That gap returns later.

On the 28 September 2026 snapshot of IPinfo, an IP address data company, 70.3% of routed prefixes were RPKI-valid, up from 54.0% on the same date in 2025. A routed prefix is an address block some network announces in BGP. Split by family, IPinfo reports IPv4 prefixes at 68% and IPv6 at 79%.

Counted by IPv4 addresses instead of prefixes, 65.0% sat in RPKI-valid routes. IPinfo built these figures from one RPKI snapshot a day and the public RIPE RIS and RouteViews collectors, servers that record what networks announce.

The same report shows filtering at work. On 28 September 2026, the median valid prefix was seen by 596 of the routers feeding those collectors, and one with no RPKI record by 595. The median Invalid prefix was seen by just two.

IPinfo's reading is that enough networks now check, and they drop Invalid routes. The report gives no count of the networks that do.

A ROA names one AS number and the prefixes that AS may originate, meaning first announce. The prefix holder signs it. RFC 9582 says each ROA identifies a single AS, so if two networks must announce the same prefix, the holder issues two ROAs.

A ROA can also carry a maximum length, written maxLength in the RFCs. It is the longest prefix length the AS may announce inside the listed block. Longer means smaller, so maxLength decides how finely the block may be split.

RFC 9582 gives an example: 203.0.113.0/24 with maxLength 26 lets the AS announce the /24, its two /25s and its four /26s. That is seven prefixes in all, but no /27. Without maxLength, only the exact prefix is authorised.

It compares the route with every Validated ROA Payload, or VRP. A VRP is one entry a validator extracts from a ROA whose signatures checked out: a prefix, a maximum length and an origin AS.

RFC 6811 then asks two questions. A VRP covers a route when the route sits inside the VRP's prefix. A VRP matches when it covers the route, the route is no longer than maxLength, and the origin AS is the same.

Valid means at least one VRP matches. Invalid means at least one VRP covers the route but none matches. NotFound means no VRP covers it at all.

Pause and predict: what would the third row say if the ROA had maxLength 26? Hold that thought until the section on minimal ROAs.

You can run the RFC 6811 logic yourself. This sketch uses only Python's built-in ipaddress module, and it ran unchanged on Python 3.13. Its AS numbers and blocks come from ranges reserved for documentation (RFC 5398 and RFC 5737), so no real network uses them.

from ipaddress import ip_network

# The gateway's VRPs: (prefix, maxLength, origin AS)
VRPS = [(ip_network("203.0.113.0/24"), 24, 64501)]

def validate(route, origin_as):
    net = ip_network(route)
    covered = False
    for prefix, max_len, asn in VRPS:
        if net.version == prefix.version and net.subnet_of(prefix):
            covered = True  # this VRP covers the route
            if net.prefixlen <= max_len and origin_as == asn:
                return "Valid"  # covered and matched
    return "Invalid" if covered else "NotFound"

print(validate("203.0.113.0/24", 64501))    # Valid
print(validate("203.0.113.0/24", 64505))    # Invalid: wrong origin
print(validate("203.0.113.128/25", 64501))  # Invalid: too long
print(validate("192.0.2.0/24", 64509))      # NotFound

What just happened? The subnet_of call is the cover test, and the second if is the match test. Running it should print four lines: Valid, Invalid, Invalid and NotFound.

Real validators handle cases this sketch skips. When a route's AS path ends in an AS_SET, a bundle of merged AS numbers, RFC 6811 sets its origin to NONE, which never matches. Such a route can be Invalid or NotFound, never Valid.

APNIC, the registry that hands out addresses in the Asia-Pacific region, describes ROV in routers as typically meaning rejecting Invalid routes, so Valid and NotFound routes are still accepted. The standard leaves that choice to each operator.

RFC 6811 and its 2018 clarification, RFC 8481, say a router must not drop a route because of its state unless it is explicitly configured to. By the standard, turning on validation only labels routes. The drop needs a separate policy line.

NotFound routes stay accepted for a practical reason. About three in ten routed prefixes still are not RPKI-valid, so dropping everything without a matching ROA would cut off a large part of the internet.

You can test your own provider. Cloudflare's Is BGP Safe Yet site, online as of 19 October 2026, announces a route that is deliberately Invalid and hosts a page on it. If that page loads for you, your provider accepted the Invalid route.

They get it over the RPKI to Router protocol, RTR, version 1 of which is RFC 8210. The validator, which RFC 8210 calls relying-party software, gathers and checks RPKI data into a cache. The router keeps a connection open to one or more caches.

RFC 8210 makes the router poll the cache for updates on a timer. When a cache has new data, it can also send a Serial Notify message, which the RFC calls only a hint. The router may then send a Serial Query for the changes or a Reset Query for everything.

RFC 8210 lets a router keep a preference-ordered list of caches. A provider can therefore run two validators on separate machines and lose one without losing the feed.

ROAs follow the chain that hands out addresses. IANA is the body that keeps the global pool of addresses and AS numbers. RFC 6480 puts IANA at the top, five Regional Internet Registries (RIRs) below it, and, in some regions, National Internet Registries (NIRs) as a third tier.

India is in APNIC's service region, and its NIR is IRINN, operated by NIXI, the National Internet Exchange of India. APNIC members create ROAs in the MyAPNIC portal. APNIC calls its hosted mode, where it runs the certificates for you, the recommended option for most members.

As of 19 October 2026, IRINN members request ROAs by email from their registered address. The request names the AS number, the prefix and the most specific announcement length.

The most specific length decides how many prefixes you authorise

IRINN's own example, a /22 with /24 as the most specific length, produces seven ROA prefix entries: the /22, both /23s and all four /24s. If you announce only the /22, six of those entries authorise blocks you never announce.

That is the loose setup the next sections warn about. Give the length you actually announce, and ask for more only when you announce more. If you announce a /22 and one /24 inside it, ask IRINN to list each announced prefix at its own length instead.

Trust anchors and TAL files

A trust anchor is the starting certificate a validator trusts without checking further up. RFC 6480 lets each validator operator choose its own, naming IANA or the five RIRs as obvious defaults. APNIC runs its RPKI under a single trust anchor.

Validators find a trust anchor through a Trust Anchor Locator, or TAL, defined in RFC 8630. A TAL is a small file listing where to download the certificate and the public key it must carry.

It does not stop an attacker who fakes the origin, and it does not check the rest of the path. RFC 6811 says it provides no path validation and calls it more a protection against misconfiguration than true security.

Forged-origin hijacks

In a forged-origin hijack, an attacker announces your prefix with your AS number placed at the end of the AS path, as if the route started with you. RFC 6811 notes the attacker need only prepend the valid origin AS.

IPinfo reports a real case. On 28 August 2026, a route for 162.55.80.0/24 appeared with the hosting company Hetzner's AS24940 forged as the origin. At the time, Hetzner's ROA covered the surrounding /16 but allowed blocks as small as a /24, so the route was RPKI-valid.

IPinfo reports that Hetzner tightened three prefixes after the incident, including the hijacked one. A RIPEstat lookup on 19 October 2026 shows the covering ROA as 162.55.0.0/16 with maxLength 16. Against it, the same /24 announcement is Invalid, with the reason invalid_length.

Route leaks

RFC 7908 defines a route leak as the propagation of routing announcements beyond their intended scope. Picture a customer network passing one provider's routes on to another provider. The origin is still correct, so ROV sees nothing wrong.

A minimal ROA authorises only the prefixes you actually announce and nothing more. RFC 9319 (BCP 185) says operators should use minimal ROAs whenever possible. It also says to avoid maxLength, because it usually makes a ROA non-minimal.

The danger is a forged-origin sub-prefix hijack. Routers forward traffic using the most specific matching route, called longest-prefix match, so a forged /25 wins over a real /24 for the half of the block it covers. Now the earlier prediction: with maxLength 26, a forged 203.0.113.128/25 ending in AS64501 is Valid.

With the minimal ROA, the same route is Invalid. RFC 9319 cites a June 2017 measurement: of prefixes in ROAs using maxLength, 84% were open to this hijack.

The gap has not closed. On 28 September 2026, IPinfo found 138,698 of 855,217 RPKI-covered IPv4 routes, or 16.2%, had a ROA looser than the route announced. No more-specific route of the holder's own filled the gap. IPinfo counted only routes seen by at least two of the routers feeding the collectors.

RFC 9319 accepts maxLength when every more-specific prefix it allows is actually announced. A DDoS scrubbing service, which filters flood traffic for you during a denial-of-service attack, may also need a non-minimal ROA for blocks it announces only during an attack.

Setting up minimal ROAs, step by step

1. 1

   List what you announce

   Write down every prefix you announce and its exact length.

2. 2

   List who announces it

   Include every AS that announces it, such as a DDoS scrubbing service. Each AS needs its own ROA.

3. 3

   Request the ROA

   In MyAPNIC, create a ROA for the exact prefix you announce. Through IRINN, give your announced length as the most specific length, and ask for each announced prefix separately if you announce several lengths.

4. 4

   Leave out maxLength

   Set none, or set it equal to the length you announce.

5. 5

   Check the result

   Run the RIPEstat lookup below for each prefix and origin AS. Every route you announce should come back valid.

6. 6

   Change ROAs first

   Publish the matching ROA before you announce a new prefix, or before a new AS, such as a provider or scrubbing service, starts announcing yours.

Check your own prefix

RIPEstat, the public data service of the RIPE NCC (one of the five RIRs), returns the validation result for any prefix and origin pair. Replace the AS number and prefix with your own.

curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS13335&prefix=1.1.1.0/24"

Look at the status field inside data. On 18 October 2026 this example returned valid, with one validating ROA: 1.1.1.0/24, maxLength 24, origin 13335.

These status names are RIPEstat's own, not RFC terms, and every lookup named Routinator, an open-source validator, as the one it used. Treat the names as observed output as of 19 October 2026, and pin any script to what the service returns.

With a minimal ROA in place, a repeat of the Tuesday mistake comes back Invalid. Networks that drop Invalid routes ignore it, and the gateway's traffic stays home.

ASPA, Autonomous System Provider Authorization, is a proposed path check, not yet a standard. Each network publishes one signed record listing its provider networks. Its draft says checking paths against these records helps detect and mitigate route leaks and AS path manipulation.

As of 19 October 2026, the current version is draft-ietf-sidrops-aspa-verification-29, updated 16 October 2026. It aims to become a Proposed Standard. Its working group state reads WG Consensus: Waiting for Write-Up. In the IESG, the group that approves standards, its state is still I-D Exists: it has not been sent there yet.

IPinfo counted 131 networks with ASPA records on 28 September 2025 and 3,272 a year later. Treat ASPA as coming, not settled.

Frame it as trust in announcements. Then follow the data from registry to router, and end on the limits.

1. 1

   Name the problem

   BGP largely trusts announcements, so a wrong route can pull traffic away.

2. 2

   Draw the chain

   Trust anchor, registry, signed ROA, validator, RTR feed, router.

3. 3

   Give the three states

   Valid, Invalid and NotFound, and the common local policy of dropping Invalid.

4. 4

   Name the filtering risk

   A wrong ROA gets your own routes dropped by networks that filter Invalid, so publish ROAs before routing changes.

5. 5

   State the limits

   ROV checks only the origin. Minimal ROAs shrink forged-origin risk, and ASPA aims to check paths.

6. 6

   Quote one dated number

   IPinfo found 70.3% of routed prefixes RPKI-valid on 28 September 2026.