Summary

  • APNIC's 24 October 2025 availability paper evaluated a repository mirror mainly as a way for a newly initialised relying party to fetch APNIC data during an outage. Under the paper's certificate-validity assumptions, the mirror would remain useful for approximately five days; APNIC assessed the benefit as very marginal.
  • The APNIC–NNIX MoU signed on 15 May 2026 instead describes a Hangzhou mirror intended to reduce latency. APNIC's announcement names validation speed, data availability and network latency as pilot measures.
  • Those records need not conflict. The first asks how long a static copy helps under loss of the primary repository; the second asks whether proximity improves ordinary access and performance. A result for one question does not answer the other.
  • The checked public record does not establish that the mirror is operational, define the metrics, publish a baseline or target, identify the serving architecture, or supply the separate agreement required by the MoU. A public hypothesis crosswalk would make the pilot testable without disclosing sensitive topology.

One mirror, two questions

The most important word in a pilot is often not the name of the equipment. It is the question placed beside it.

APNIC has now published two records about an RPKI repository mirror. Read only by noun, they appear to point in opposite directions. One says that mirroring has little value. The other announces a mirror pilot and presents it as a way to improve access, reliability and validation performance.

The apparent reversal dissolves when the questions are kept intact.

The first record is APNIC's RPKI availability concerns, dated 24 October 2025 and still listed in APNIC's technical-document index. It asks what happens if APNIC's repository can no longer be reached. Its mirror is an outage instrument.

The second is the APNIC–NNIX announcement and signed memorandum of 15 May 2026. Their mirror is a local pilot in Hangzhou. Its stated centre of gravity is latency and the everyday performance of validation.

A resilience test and a proximity test can use related infrastructure without producing interchangeable evidence. That distinction should be part of the public pilot record, not reconstructed months later from separate PDFs.

The 2025 paper models a long outage

APNIC's paper starts from the availability of the trust anchor and associated repositories. It says APNIC considered the technical risk minimal and did not recommend changes in that area. It then works through several possible responses, including repository mirroring, a public RTR cache, indefinite stale-state use and a separate trust anchor.

Those designs are not synonyms. The repository-mirror section describes current APNIC data copied to a server in an economy and controlled directly by APNIC. Relevant relying parties might reach it through BGP anycast or DNS. The intended benefit is narrow: if the ordinary APNIC repository is unavailable, a relying party without cached state can still initialise from the mirror.

The paper also states the clock behind its conclusion. It says member certification authorities in the APNIC trust-anchor repository have a seven-day validity period and are reissued every two days. In normal circumstances, that leaves at least five days of validity. A mirror cut off from fresh publication would therefore become stale on roughly the same horizon.

From that model, APNIC calls the benefit very marginal. The beneficiary is the uninitialised relying party; the failure state is long-term repository inaccessibility; the useful interval is approximately five days. The paper does not say that a mirror can never lower fetch latency, help diagnose reachability or provide experimental evidence about local access. Those are not the questions it sets out to decide.

Its reasoning also protects against a more dramatic misreading. Repository unavailability does not automatically cause every route to be rejected. The paper says a newly started relying party with no APNIC data would mark relevant routes unknown, and conventional operator policy should accept that state. Existing relying parties keep cached data until it expires. The result may reduce the protection supplied by RPKI, but it is not the same mechanism as a universal routing shutdown.

The NNIX pilot moves the measurement target

Seven months later, APNIC and the National (Hangzhou) Novel Internet Exchange signed a non-binding MoU. The mirror appears inside a broader programme of IPv6 and RPKI training, lab infrastructure and assistance with ROA and Route Origin Validation deployment.

The MoU says the parties are to deploy an RPKI Repository Mirror to support reduced network latency and explore joint metrics for improvement in network-traffic latency. APNIC's accompanying announcement adds two other named measures: validation speed and data availability. It says changes in those measures could inform whether similar mirrors might be used elsewhere.

That is a different evaluation frame. A locally reachable copy may be unpersuasive as a way to preserve fresh signed objects through a prolonged loss of the publisher, yet still be useful if ordinary fetches become faster or more consistent from selected networks. Conversely, a measurable latency improvement would not show that the mirror extends the validity of objects, preserves publication during an upstream failure or changes how an uninitialised relying party behaves on day six.

Even the phrase validation speed needs decomposition. It might mean time to fetch repository data, time for a relying-party implementation to validate objects, time to complete a refresh, time to deliver validated payloads to a router, or time for local routing policy to act. Network proximity directly controls only part of that chain. APNIC's public announcement names the measure but does not define it.

The same is true of data availability. A measurement could count successful HTTP requests, complete RRDP update sessions, timely snapshots, cryptographically valid object sets, freshness within a threshold, or accessibility from a selected set of networks. Those are materially different denominators. A pilot can produce a good number under one definition while users still fail under another.

The MoU records intent, not activation

The public memorandum draws a clear boundary around the present state. Section 9.1 makes mirror deployment and joint metrics subject to a separate written agreement. Later clauses say the MoU is non-binding, that the contemplated activities are indicative, and that neither party must commit funds or resources unless separately agreed. It also records no transfer of funds between the parties.

APNIC's May EC minutes preserve the same level of certainty. The Director General told the Council that the coming NNIX MoU included a China mirror-server pilot. The EC noted the update. The minutes do not record a resolution approving a design, budget or production cutover.

APNIC's current partnerships page continues to describe the parties as working to establish the pilot. The checked public sources do not supply the separate implementation agreement, an activation date, a serving address, a topology, a start-of-measurement notice or results.

That absence must be stated narrowly. It does not show that engineering has not started or that an agreement does not exist internally. It shows only that the reviewed public evidence stops at an announced, conditional pilot. A news analysis should not promote intent to deployment merely because the announcement uses confident future tense.

A mirror is not a new source of authority

APNIC's current Certification Practice Statement names its public repository endpoints: rpki.apnic.net for rsync and rrdp.apnic.net for RRDP, with separate endpoints for its publication service for self-hosted clients. The checked section does not name a Hangzhou endpoint or another trust anchor.

That matters because three layers are easy to collapse in ordinary language.

A repository mirror distributes copies of signed objects. A trust anchor identifies the root from which a relying party begins validation. A public RTR cache supplies processed routing-validation data to routers. APNIC's 2025 paper treats all three as separate options and identifies different risks for each. The NNIX record says repository mirror; it does not establish a new trust anchor, transfer certification authority to NNIX or create an unverifiable public RTR service.

The public pilot record should say this plainly. It can name the mirror's role, the source repository, the URI presented to relying parties and the organisational allocation of operations without publishing credentials, detailed internal topology or security-sensitive failover controls. Readers need authority boundaries, not a network diagram.

Publish the hypothesis beside the result

A compact crosswalk would make the two APNIC records cumulative rather than competitive.

Field 2025 availability assessment 2026 NNIX pilot
Question What helps if APNIC's repository is inaccessible? Does a local mirror improve defined performance and access measures?
Principal beneficiary An uninitialised relying party during an outage Networks included in the Hangzhou pilot's observation set
Architecture stated publicly Economy-level mirror controlled directly by APNIC; possible DNS or BGP direction Repository mirror with APNIC and NNIX; detailed serving and control design not public in the checked record
Public measure Approximate useful period under certificate-validity and reissue assumptions Validation speed, data availability and network latency; definitions and targets not public in the checked record
Decision state Analysis that did not recommend the examined changes Non-binding, indicative pilot subject to a separate agreement

The pilot entry should then add a baseline, target, denominator, vantage points, observation window, freshness test, start and end state, result and uncertainty. Closeout should say whether the result retains, narrows, replaces or simply does not test the 2025 conclusion.

This is not paperwork added after an experiment. It is what prevents metric choice from becoming outcome choice. If latency improves, APNIC should be able to say exactly what became faster and what did not. If no improvement appears, it should be able to distinguish a sound negative result from a failed deployment, an unsuitable vantage point or an undefined measure.

Sources