IPinfo's October data pass frames 70% coverage as the milestone where RPKI stops being a nice-to-have. They point to the late-2023 inflection — AWS enabling ROA signing and tier-1 carriers (NTT, Telia, Lumen, Arelion) moving from 'log invalid' to actually dropping invalid announcements — as the trigger for mainstream enforcement.
Surfaced the IPinfo analysis to the HN community, implicitly endorsing the thesis that 70% is a meaningful threshold for closing the long-standing BGP hijack window after a decade of flatlined adoption.
Argues that BGP's 1989-era trust model — anyone announcing a route is assumed to have the right to — has been exploited roughly quarterly for twenty years, from the 2008 YouTube/Pakistan Telecom incident to the 2018 Route 53 ETH theft and recurring China Telecom leaks. RPKI's X.509-anchored origin claims cryptographically bind AS numbers to prefixes, closing the specific gap each of those incidents exploited.
Acknowledges that residential ISPs, Southeast Asian and African regional telcos, and a chunk of US cable operators remain partial or non-enforcers. But argues this matters less than it used to because the backbone they peer with now drops invalids one hop in, meaning lazy downstreams get filtered regardless of their own posture.
IPinfo's October data pass puts RPKI coverage at roughly 70% of advertised IPv4 routes and north of 55% of IPv6 — a milestone the routing community has been chasing since the standard was published in RFC 6480 back in 2012. For a protocol whose adoption curve looked flatlined through most of the 2010s, crossing 70% is the moment RPKI stops being a nice-to-have and starts being the default.
The numbers behind the headline are worth sitting with. In 2019, fewer than 10% of prefixes had a valid Route Origin Authorization (ROA). By 2022 that was ~30%. The IPinfo analysis shows the inflection point hit in late 2023, when AWS flipped on ROA signing for its massive address space and tier-1 carriers — NTT, Telia, Lumen, Arelion — moved from "log invalid" to actually dropping RPKI-invalid announcements at their borders. Cloudflare's `isbgpsafeyet.com` scoreboard, which started as a mild shaming campaign, now shows most major transit providers in the green.
The long tail is where it still gets interesting: residential ISPs, regional telcos in Southeast Asia and Africa, and — awkwardly — a non-trivial chunk of US cable operators remain partial or non-enforcers. But the backbone they peer with increasingly does enforce, which means an invalid announcement from a lazy downstream gets filtered one hop in regardless.
BGP is the protocol that stitches the internet together, and it was designed in 1989 on the assumption that everyone announcing a route had a right to announce it. That assumption has been wrong roughly once a quarter, loudly, for two decades. The 2008 YouTube/Pakistan Telecom incident, the 2018 Amazon Route 53 hijack that drained ~$150k in ETH, the 2022 KlaySwap theft, the recurring China Telecom route leaks — all of them exploited the same gap: nothing in BGP cryptographically ties an AS number to the prefixes it's allowed to originate.
RPKI closes that gap by anchoring origin claims in X.509 certificates issued by the five RIRs, so a router can ask "is AS X actually authorized to announce 192.0.2.0/24?" and get a cryptographic yes/no. It doesn't solve path validation (that's BGPsec, which is going nowhere), and it doesn't stop a determined attacker who compromises an authorized AS. What it does is make the garden-variety fat-finger hijack — the kind that takes Cloudflare or Facebook off the internet for an afternoon — mechanically impossible to propagate past an enforcing peer.
The interesting question is why *now*. Three things converged. First, the economics finally flipped: once Cloudflare, Google, AWS, and Hurricane Electric were all enforcing, the cost of *not* having ROAs became "your prefix doesn't reach half the internet," which gets a networking team's attention in a way that abstract security arguments never did. Second, the tooling got boring in a good way. Krill (NLnet Labs) and Routinator made running a validator a Dockerfile instead of a weekend. ARIN, RIPE, APNIC, LACNIC, AFRINIC all expose hosted CA options now — you don't have to run your own if you don't want to. Third, regulators noticed. The FCC's 2024 BGP security order and the EU's NIS2 directive now treat unmitigated route hijacks as reportable incidents, which turned RPKI from a networking team's problem into a compliance team's problem — and compliance teams get budget.
The community reaction has been quietly triumphant. Job Snijders, one of the ROV evangelists at NTT and now Fastly, posted that "we are past the point where RPKI is debatable." The MANRS initiative (Mutually Agreed Norms for Routing Security) saw its participating network count more than double in 18 months. Even the holdouts have stopped arguing the premise and started arguing the implementation details — which is how you know the fight is over.
If you run your own ASN and announce your own prefixes, the action item is unambiguous: create ROAs for every prefix you originate, through your RIR's hosted portal if you don't want to run Krill yourself. It takes about 20 minutes per prefix the first time, five minutes once you know the UI. The RIPE NCC and ARIN portals both have decent docs. If you're multihomed, make sure every upstream AS that *could* legitimately originate your prefix is covered — a common footgun is signing a ROA for your primary ISP's AS and then watching failover traffic get filtered because the backup AS wasn't authorized.
If you're a developer at a company that doesn't own its address space — which is most of you — the implication is subtler but still real. Your cloud provider's BGP hygiene is now part of your availability story, and "does this vendor publish ROAs and enforce ROV" is a reasonable question to put on a procurement checklist. AWS, GCP, Azure, Cloudflare, Fastly, and Akamai are all solidly in the green. Some second-tier CDNs and bare-metal providers are not. If you're building anything latency-sensitive or financial, the handful of networks that still accept invalids are a tail risk you can now actually measure.
The adjacent concern is monitoring. RPKI tells you whether a route *should* be valid; it doesn't tell you whether someone is announcing a more-specific prefix inside yours (the classic hijack-via-longer-prefix trick, which ROV also blocks if the more-specific isn't covered by a ROA). Tools like BGPAlerter, ThousandEyes, and Kentik's route monitoring will tell you when your prefix is being announced from an AS you don't recognize. If you haven't set up alerting on your own prefixes, now is the time — the attackers who used to get away with hijacks are getting squeezed into narrower windows, and they're going to try harder.
The next milestone is 90%, and the honest answer is it probably takes another three to four years — the last 20% is residential ISPs and smaller regional networks where the economics are weaker and the tooling knowledge is thinner. The more interesting fight is ASPA (Autonomous System Provider Authorization), the IETF draft that extends RPKI to validate *paths* and not just origins, closing the route-leak gap that RPKI alone can't touch. If ASPA ships and gets even half the adoption curve RPKI did, BGP in 2030 will look almost unrecognizably more trustworthy than BGP in 2020. For a protocol everyone has been predicting the imminent death of since 2005, that's a strange and welcome outcome.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.