RPKI now protects 70% of internet routes

Where the unprotected addresses are is just as concentrated. Of all routed IPv4 space not in RPKI-valid routes on September 28, nearly 60% is in the United States, and about one in four addresses belongs to the US Department of Defense (more on who holds IPv4 in an upcoming post). Most of that is space the Department began announcing in 2021 to watch for misuse, not to run services.

In early 2025 there were concerns that IPv6 adoption of RPKI was slowing. Instead, it accelerated and has now overtaken IPv4. In RPKI's 2024 year in review for RIPE Labs, Job Snijders noted IPv6 ROA growth "seems to be stalling." Over our window, IPv6 routed prefixes marked valid rose from 56% to 79% while IPv4 prefixes rose from 54% to 68%, putting IPv6 roughly ten points ahead. The Hurricane Electric RPKI report shows the same ordering.

Two other metrics he flagged also changed: the average number of address blocks per ROA climbed back from 2.31 at the end of December to 2.62, and publication points, which he counted falling from 63 to 53 and read as consolidation, rose from 73 to 91 as more organizations began hosting their own repositories instead of relying on their registry.

RPKI validates who may originate a prefix. It does not validate the path, and it cannot catch an attacker who stays inside the permission you published, so it's not bulletproof.

On August 28, 2026, a route for 162.55.80.0/24 (a block of 256 addresses) appeared with Hetzner's AS24940 forged as the origin. Hetzner's ROA covered the surrounding /16, a block 256 times larger, and allowed announcements as small as a /24, so the forged route satisfied it. The route was RPKI-valid, no legitimate /24 existed to compete with it, and longest-prefix-match meant everyone preferred it. That was enough to obtain a genuine TLS certificate and serve a malicious Virtualizor update to hypervisors, as documented by Kentik. Nothing about RPKI failed. The ROA permitted it.

We measured how common that posture is. Of 855,217 RPKI-covered IPv4 routes, 138,698, or 16.2%, have a ROA looser than the route announced and no more-specific route of their own filling the gap. For IPv6 it is 20.9%. That leaves roughly 18 million more-specific prefixes an attacker could announce today, forge the origin, and come out RPKI-valid and uncontested.

Operators in the same business make very different choices here. Among hosting providers, Contabo has an open window on 540 of 553 covered routes and DigitalOcean on 780 of 863, while OVH sits at 11.5%. Access providers are worse still: Cablevision at 98.1%, Shaw at 96.5%, Bharti Airtel at 85.0%.

RFC 9319 already says the best practice is to leave maxLength unset. maxLength is the setting that lets a ROA also cover smaller blocks inside it, so leaving it unset means a ROA matches only the block actually announced. Hetzner tightened three prefixes after the incident, including the one that was hijacked, though 49 of its 63 covered routes remain open.

RPKI coverage can also disappear without causing an outage. A missing ROA simply removes the protection, and nobody notices unless they look. We found several cases where that happened over the past year.

Unlike China, Mauritius saw its RPKI coverage fall. The share of its IPv4 addresses in valid routes fell from 94.0% to 69.0% between September 2025 and September 2026. SEACOM (AS37100) lost four of its six ROAs on January 1. One covered 105.16.0.0/12, a block of about a million addresses, 46% of which are in Mauritius. That block alone explains Mauritius's drop, and it still had no ROA on September 28.

Two other operators show the same thing happening and then being fixed. Saudi Telecom (AS25019) lost RPKI protection on 19 routes, including six large blocks totaling about 1.6 million addresses, when the ROAs for those six blocks disappeared between March 30 and April 13. Saudi Arabia's coverage recovered when the ROAs came back on September 21 and 22.

In Morocco, Orange Maroc (AS36925) is the only large operator that publishes ROAs, and most of them went missing twice: from July 2025 to July 2026, and again from July 25 to September 3. Morocco went from 20% covered to almost none, and back.

There is a critical measurement trap here. Some validation methods can count an RPKI record as failed even though it is still providing protection in practice.

Every signed record carries a link to the certificate above it. When an operator moves its repository, that link can go stale, and a check that inspects records one by one will report a hard failure. But the validation that actually produces the list routers use never follows that link, it walks down from the trust anchors instead.

We found thousands of records flagged as failed that were present in every independently validated set we checked, with their routes still RPKI-valid. So if you are reading anyone's RPKI numbers, including ours, it is worth knowing which of the two they counted. A count of failing records is not a measure of lost protection.

ROAs secure the origin of a route. They say nothing about whether the path used to reach that origin makes sense.

ASPA, or Autonomous System Provider Authorization, addresses that. A network publishes a signed record naming its authorized upstream providers, which lets others check observed AS paths against them and catch route leaks that origin validation misses.

Deployment is early but fast. On September 28, 2025, 131 networks had published ASPA records. By September 28, 2026 there were 3,272, 25 times as many.

The growth comes in steps rather than a curve. RIPE NCC sat at about 85 networks from September to late November, then climbed to 470 by the end of December. ARIN stepped up from January 21, APNIC at the end of June and again in September, when its count nearly doubled. Each jump follows a registry making ASPA signing available, so tooling has been the main driver. One detail: APNIC announced its support on July 9, and its curve started climbing on June 26.

That coverage is now enough to ask the better question: how much of observed routing is ASPA-valid?

On September 28, 2026, 9.7% of observed routing passed ASPA checks, up from 6.2% a year earlier. Most of that is automatic: under the draft rules, a path through only one or two networks always passes, and those short paths were about 6% of routing in both years.

Take them out and the records networks have published verify about 3.5% of routing, up from roughly 0.1%. That is the real progress.

Almost all the rest is not failing. It is unknown, because too few networks along those paths have published records to tell. In practice, ASPA can check only a small slice of routing today, and that slice grows with every network that publishes a record.

More interesting is the part that can be judged and fails. Paths breaking ASPA's rules mid-path, the signal a collector can read with most confidence, rose from effectively zero to 0.048% of observations. That is not necessarily routing getting worse: a path can only be called invalid once enough of it has declared providers, so as publication grew, paths that were previously unjudgeable became testable and some failed.

Attributing those failures needs care, because the gap sits mid-path: one provider with a stale record makes every one of its customers' routes look invalid, so ranking by origin blames the wrong party.

Attribute to the hop instead and the networks at the top are the ones doing it right. Cogent, Arelion, and GTT each declare AS0, which says they buy transit from nobody. That is true, and it is exactly what stops a stale record further down the path from hiding as "no attestation." The real gaps are smaller: of 3,272 networks publishing ASPA records, 479 have upstream providers visible in our routing data that they never declared, across 658 missing relationships.

The largest single cause is one operator. Syrian Telecom (AS29386) publishes a record naming four carriers. Three of them carry just 16% of the transit we observe through it, and the fourth carries none. The four carriers that handle the other 84% are missing from the record, so about 40% of paths arriving through them fail the check, and the rest come out unknown.

Through Syrian Telecom's own routes and those of two Syrian networks that reach the Internet through it, that record accounts for 21% of all mid-path ASPA failures on the Internet. Another 3 points come from AS201550, a second Syrian Telecom network whose record copies the same four carriers instead of naming the Syrian Telecom networks it connects through. Which means the global ASPA failure rate is not yet a measure of the Internet's health. About a quarter of it comes from one operator's incomplete records.

Eighteen years after PCCW Global passed on Pakistan Telecom's announcement for YouTube's addresses, PCCW is a gap in the newer system. ASPA would not have stopped the 2008 incident; RPKI's origin check is what covers that. But ASPA lets others check PCCW's place in a path, and AS3491 has not published a record. That breaks nothing on its own. Still, nearly 6,000 paths crossing PCCW read ASPA-invalid today, because networks below it publish records that leave PCCW out.

RPKI now protects most Internet routes, and invalid routes barely travel. The gaps that remain are mostly in the hands of the networks that own the addresses:

IPinfo tracks the RPKI status of every routed prefix daily: ipinfo.io/data/rpki.

Methodology: All figures come from IPinfo's routing and RPKI datasets, one RPKI snapshot per day. RPKI validity is the share of routed prefixes classified valid against the validated authorization set, not the validation status of individual RPKI objects. Routing data comes from the public RIPE RIS and RouteViews collectors, which IPinfo ingests daily. A prefix's visibility is the number of distinct BGP peers of those collectors carrying it. Across every prefix seen by at least one of them the figure was 70.3% on September 28, 2026; requiring two or more removes isolated announcements and gives 71.4%. Propagation figures are medians; the corresponding means are 519, 515 and 9, pulled up by a tail of more widely seen invalids.

Country figures use IPv4 only and count addresses, not prefixes. Each routed prefix is split across countries by IPinfo geolocation, so a /16 with half its addresses in Italy counts 32,768 addresses toward Italy. Where routes overlap, each address is counted once, and current geolocation is used for every year. An address counts as covered if any RPKI-valid route includes it. The prefix share in Chart 3 assigns each prefix to the country of its first address. The weighted invalid share in Chart 3 is counted per route: it multiplies each route's addresses by the number of vantage points that see it.

Propagation-weighted figures begin in 2024, as the underlying peer data does not exist for earlier snapshots. Yearly comparisons use September 28 snapshots unless another period is stated.

Figures are single-day snapshots rather than averages. The daily series is stable enough that this makes no practical difference: RPKI-valid share moves a median of 0.05 points a day, and a seven-day mean around each date differs from the single-day value by less than 0.1 points.

The maxLength measurement covers prefixes seen by two or more vantage points on September 28, 2026, which drops isolated announcements. An "open window" is a routed prefix whose covering ROA permits a longer prefix than the one announced, with no more-specific route of the operator's own inside that range.

ASPA figures cover daily observations from September 9, 2025 to September 28, 2026, weighted by route observations rather than distinct AS paths. The 0.048% figure is mid-path invalidity only; terminal-hop invalidity is excluded because it turns on the collector peer's own record, and a single incomplete record there taints that peer's entire table. Two peers account for 70% of it.