APNIC-NNIX RPKI Mirror in Hangzhou: Proximity Buys Speed, Not Trust
Picture the day a Chinese network engineer has to decide whether to repoint their RPKI validator at a brand-new regional mirror. The vendor slide says validation latency drops. The pitch deck shows a graph trending down. The pressure from above is to take the win and move on. The quiet question nobody on the slide is answering: does the faster path actually make the routes any safer, or does it just make a wrong answer arrive sooner? That decision is now live for operators across the region, and getting it wrong looks like nothing at all until an outage finds the gap.
The decision exists because APNIC and the National (Hangzhou) Novel Internet Exchange are trying to engineer a specific failure out of the region. On 15 May 2026, at the Zhejiang World Telecommunications and Information Society Day event, APNIC Director-General Jia Rong Low and NNIX General Manager Qian Junbo signed a Memorandum of Understanding (APNIC blog, 15 May 2026).
Its centerpiece is a pilot: a local mirror of APNIC's RPKI repository hosted at NNIX, plus IPv6 and RPKI training for the exchange's membership. The pitch is latency. Bring the data physically closer, the argument goes, and Chinese operators validate routes faster and more reliably.
The latency framing is correct, and it is also incomplete. A mirror moves bytes faster. It does not move a single object's trust closer to true. I spend my days on the commercial side of a marketplace that lives or dies on clean route objects, so I read announcements like this for one thing above all: where the gap sits between what a Hangzhou mirror actually fixes and what operators will assume it fixes. That gap is where the next outage hides.
What the mirror actually solves
RPKI is a public key infrastructure, originally specified in 2008, that binds Internet number resources, IP addresses and Autonomous System Numbers, to cryptographic certificates (APNIC source). The legitimate holder of a block issues a signed statement, a Route Origin Authorization, declaring which AS may originate that prefix. A relying party fetches those validated payloads into a cache, and routers consult it to mark each announcement VALID, INVALID, or NOT FOUND, with the results carried over the RPKI-to-Router Protocol.
The weak joint in that chain is the fetch. As RPKI has grown, the number of delegated Certificate Authorities has multiplied, and synchronizing the whole tree has become genuinely hard. Relying parties defend themselves with timeouts: if a publication point is slow, they skip it rather than stall the entire run. Skipping is the lesser evil, but it is still a hole, every skipped point is a set of prefixes the validator could not confirm during that cycle. When the path to that point crosses an ocean and a few congested borders, the odds of a skip climb.
This is the precise problem a local mirror addresses. Aggregate the repository onto fast regional links and the fetch stops racing a timeout. Fewer skips, fewer transient "not found" windows, more consistent coverage. APNIC and NNIX have committed to measure the effect on three axes, validation speed, data availability, and network latency, and to use those numbers to decide whether mirrors belong elsewhere too. That is the right instinct: treat the pilot as an experiment with a falsifiable result, not a foregone win.
| What a local mirror changes | What it does not change |
|---|---|
| Fetch latency from regional cache to validator | Whether a ROA names the correct origin AS |
| Frequency of timeout-skips on slow publication points | Whether a prefix has any ROA at all |
| Freshness windows during peak update load | The "not found is accepted" gap in ROV logic |
| Operator distance to current validation data | The reputation history of the address space |
The position: proximity is a performance fix, and people will mistake it for a security fix
Here is the claim I will defend. The Hangzhou mirror improves the *availability* of validation data. It does nothing for the *correctness* of that data, and conflating the two is how operators talk themselves into a false sense of safety.
Two facts from the source make the point. First, the mirror "merely serves a local copy." It does not generate trust anchors and it does not sign anything. If a block in the region has no ROA, the fastest mirror on earth returns the same answer the slow one did: NOT FOUND. And Route Origin Validation, by design, *accepts* NOT FOUND. A missing ROA reads as a shrug, never as a rejection. So the operator who deploys the mirror, watches their validation latency drop, and concludes "we're secure now" has confused a faster path to an unchanged verdict for a better verdict.
Second, the adoption picture says the unsigned space is large and unevenly distributed. ROA coverage for leased prefixes climbed from 29.9% at the start of 2021 to 71.0% by the end of 2024, outpacing the global routing table's 51.5% (RIPE-era measurement, via research synthesis). That is strong progress. It is also a reminder that roughly a third of even the well-covered leased segment, and nearly half the global table, still issues no signed origin statement at all.
And the asymmetry does not run the way the easy story assumes. In the APNIC and AFRINIC regions, small Autonomous System Numbers actually adopt RPKI at *higher* rates than their larger peers, the reverse of the RIPE region, where the large networks drive adoption and small operators trail by roughly 11 percentage points (11% versus 28%). So in APNIC's own territory the unsigned space the mirror reaches is not concentrated in small operators at all; the laggards here skew toward the larger networks. Either way, faster access to a "not found" verdict protects nothing. The mirror shortens the path to whatever answer the data holds, and for an unsigned prefix that answer is still silence.
None of this argues against the mirror. It argues against the headline that will get written about the mirror. The pilot's real value is that it removes a performance excuse: once validation is fast and local, the operator who still hasn't published ROAs has run out of reasons. The training half of the MoU, the labs and hands-on RPKI exercises for NNIX's membership, is the part that closes the correctness gap, and it is telling that APNIC paired the two. Infrastructure shipped without instruction would have delivered speed and left the security exactly where it was.
The failure modes a mirror introduces
Localization is not free, and a fair read of the pilot has to count the new risks it creates alongside the old ones it retires.
The first is a single point of failure. Aggregating the regional fetch onto one Hangzhou node means that if the node loses its upstream feed, every operator who repointed their relying party at it inherits the outage together. The defense is plain plumbing. Maintain redundant upstream peering and keep a fallback to a global publication point, so a mirror failure degrades to "slower" rather than "blind." A mirror you cannot fail away from is a liability, full stop.
The second is staleness, which does more damage than an outright outage precisely because it stays silent. A mirror is only as trustworthy as its last successful sync with the global tree. If the local cache falls behind, whether from a missed refresh, a sync bug, or a clock that drifts, validators downstream may reject a freshly legitimate announcement or, worse, keep honoring a revoked one. The cost of the mirror is a new monitoring obligation: someone has to watch the mirror's lag against the authoritative tree, and alarm on it, with the same seriousness they watch the routers. "We have a local copy" is the start of that job, not the end.
The third is operational drift, and it is human. APNIC's own measured deployment of RPKI inside its network reported no negative BGP outcomes, a clean validation of the cautious "dip a toe in the water" approach where you observe before you enforce. But that result came from disciplined operators who watched their objects. NYSERNet's peer-facing ROV deployment makes the complementary point: the engineering effort was small relative to the stability it bought. The lesson sitting under both cases is that the tooling rarely fails. The *attention* does. A mirror that nobody monitors after the launch quarter quietly rots back toward the timeouts it was built to prevent.
Before you repoint a validator at a regional mirror
If a regional mirror lands near you, Hangzhou today and somewhere else if the metrics justify it, these are the checks I would clear before moving production traffic. The table below pairs each check against the answer that should let you proceed and the answer that should make you stop.
| What to check | A good answer | A stop-and-fix answer |
| Do I have a fallback? | ||
| At least one global publication point configured as backup, so a mirror outage degrades to slow. | Only the mirror, so an outage degrades to blind. | |
| Am I watching the lag? | ||
| Alarm set on the mirror's sync delay against the authoritative tree, not just reachability. | Reachability monitored, sync lag ignored. Stale-but-up is the dangerous state. | |
| Have I actually signed? | ||
| My own prefixes carry correct ROAs, verified independently of the mirror. | No ROAs published, so a faster fetch of NOT FOUND buys no security at all. | |
| Does my ROV policy match my intent? | ||
| A deliberate choice on INVALID (drop) versus NOT FOUND (accept), with every route mapped to its bucket. | Defaults left unexamined, with no idea which routes sit where. | |
| Who owns this after launch? | ||
| A named person and a runbook for the months after the launch quarter. | Nobody owns it once attention moves on. That third quarter is where the risk lives. |
Cleared on all five, the mirror is worth deploying. The point is to deploy it with your eyes open about what it buys.
About
I am Alexei Krylov, Head of Sales at InterLIR, the Berlin-based IPv4 marketplace, and my work runs on the commercial and contractual side of moving address space between holders. The training that shapes how I read this beat is B2B sales sitting on a civil-law foundation, which means I treat a block of addresses the way I treat any asset changing hands: its price tracks the cleanliness of its paperwork and its routing history.
Reputation is the line item I watch closest. A leased or purchased block is worth what its routing hygiene says it is worth, and RPKI validation has quietly become one of the first things a serious buyer checks before signing. So when an announcement like this APNIC-NNIX pilot crosses my desk, the question I ask is whether it makes the address space my clients touch more defensible, and where operators will be tempted to skip a step. A security headline that is really a performance headline gets flagged as such, because clients who confuse the two pay for it later.
Conclusion
The Hangzhou mirror is a sober, well-scoped piece of engineering. It attacks a real bottleneck, the timeout-skip that opens transient validation holes when the repository sits an ocean away, and it ships with the right humility: an explicit measurement plan and a training program bolted alongside the infrastructure. What it does not do, and what its proponents should be careful not to imply, is improve the trustworthiness of any single route object. A faster path to a wrong or absent answer still lands you on a wrong or absent answer.
So watch the signal that actually tells you whether this pilot worked. It is not validation latency, which the mirror will improve almost by definition. The number worth tracking is regional ROA coverage: did the share of signed prefixes in the APNIC space move after the mirror and the training landed, and did the larger networks that trail their smaller peers in this region start to close the gap? APNIC committed to publishing validation speed, data availability, and network latency from the pilot. If those metrics climb while signed-prefix coverage stays flat, the region got a faster path to the same blind spots, and that is the early warning to act on before deciding mirrors belong anywhere else.
Frequently Asked Questions
Not directly. The mirror speeds up how quickly operators fetch validation data and cuts the timeout-skips that open transient gaps, but it does not sign anything or change a single route object's correctness. If a prefix has no ROA, a faster mirror still returns "not found," which Route Origin Validation accepts. Security comes from publishing correct ROAs and the training that teaches operators to do so, not from proximity alone.
Fetch latency and reliability. As RPKI grows, the number of delegated Certificate Authorities rises and synchronizing the whole tree gets harder, so relying parties time out and skip slow, distant publication points, briefly leaving prefixes unvalidated. A regional mirror puts the repository on fast local links, reducing those skips and the short "not found" windows they cause. APNIC and NNIX will measure the gain by validation speed, data availability, and network latency.
Three. It becomes a single point of failure if its upstream feed dies and everyone repointed at it loses validation together, so keep a global fallback. It can serve stale data silently if its sync with the global tree falls behind, so alarm on cache lag, not just reachability. And it invites operational drift, where nobody monitors the mirror after launch and it slowly rots back toward the timeouts it was meant to prevent.
A meaningful share. ROA coverage for leased prefixes reached 71.0% by the end of 2024, ahead of the global routing table's 51.5%, but that still leaves roughly a third of leased space and nearly half the global table issuing no signed origin statement. In the APNIC and AFRINIC regions, small networks actually adopt RPKI at higher rates than their larger peers, the reverse of RIPE, where large networks lead and small operators trail by roughly 11 percentage points (11% versus 28%). So in this region the unsigned space a regional mirror reaches skews toward the larger operators, not the smaller ones.
Only with safeguards. Configure a global publication point as a fallback so a mirror outage degrades to slow rather than blind, and alarm on the mirror's sync lag against the authoritative tree, since stale-but-reachable is the dangerous state. Confirm your own prefixes are correctly signed first, because the mirror protects nothing you have not published, and name an owner who keeps watching it after the launch quarter ends.
