Summary

  • APNIC and NIXI signed an MoU on 8 September 2026 to support ROV deployment in India, pilot an RPKI repository mirror and expand local training. The public announcement does not establish that any production routing policy has changed.
  • APNIC’s July account placed 88.04% IPv4 and 97.91% IPv6 valid-ROA coverage beside a 0.99% ROV figure described as a share of networks. The linked APNIC Labs method is user-centric and cannot normally identify whether an edge or transit network filtered the invalid test route.
  • A credible deployment receipt must preserve five distinct surfaces: ROA coverage, windowed user observations, configured operator scope, traffic/path exposure and enabling outputs. Joining them by cohort and date is useful; treating them as interchangeable is not.

Two answers on the same date

The APNIC Labs India timeseries has a row dated 8 September 2026. Under its seven-day key, the filter_rate is 1.138930. Under the 112-day key, it is 6.031948. The 14-day value is 1.147895 and the payload’s 28-day value is 2.135396. These are not four competing estimates from four institutions. They are four views produced by one source for one economy on one date.

There is also a small documentary wrinkle worth preserving. The endpoint describes “7, 14, 38 and 112 day” sliding windows, while the data itself supplies keys for 7, 14, 28 and 112. Nothing in the frozen record authorises an editor to decide silently which label is the mistake. The safe public statement is narrower: the payload contains a 28-day key; its description says 38 days; the inconsistency remains.

The point is not that APNIC Labs has found four different Indias. A rolling window carries history. Its composition, sample and measurement dynamics differ from those of a shorter window. The figures are useful only when their window, observation counts, data vintage and method travel with them. Strip those fields away and a rate becomes a portable number with no stable meaning.

That is the evidence problem awaiting the new APNIC–NIXI programme. On 8 September, the two organisations signed a Memorandum of Understanding at APNIC 62 in Mumbai. APNIC says they will work with operators and enterprises to deploy Route Origin Validation, pilot an Indian RPKI repository mirror, build local training and laboratory infrastructure, establish a train-the-trainer programme and promote routing-security practice. It is a substantial list. It is not one measurable object.

The three acts hidden inside “RPKI adoption”

A resource holder can publish a Route Origin Authorization. A validator can retrieve RPKI material and derive an origin-validation state. A network can configure a routing policy that acts on that state. The acts are related, but none performs the next one automatically.

RFC 6811 makes the separation unusually plain. It defines Valid, Invalid and NotFound states. It also says that an implementation must not exclude a route from the decision process merely as a side effect of its validation state unless the operator explicitly configures that behaviour. Rejecting invalid routes, or changing their preference, is local policy.

That distinction changes the meaning of India’s strongest published number. An APNIC article dated 17 August says that in late July, 88.04% of IPv4 route objects and 97.91% of IPv6 route objects were covered by a valid ROA. Those percentages describe signed origin authority for routed resources under the source’s stated unit. They do not say that 88.04% of Indian networks reject invalid announcements. They do not say that 88.04% of traffic crosses such a filter. They do not even say that the same organisations publishing the authorisations operate the networks receiving the routes.

The same article says ROV deployment was 0.99% “of networks filtering out invalid prefixes and announcements” on 29 July. The underlying timeseries does contain a seven-day rate of 0.990652 for that date. But APNIC Labs’ own methodology says the measurement is user-centric because a comprehensive view inside every autonomous system is not available.

The experiment changes the ROA state of routes to controlled web targets. It observes whether users can reach the targets while their route is valid or invalid. If an invalid route is dropped somewhere along the path, the user may fail to reach the beacon. That is valuable evidence of experienced filtering. It is not a census of router configurations.

The methodology also states the attribution problem. As filtering grows in transit networks, an observation can no longer see cleanly through to the edge. An access network may appear protected because its upstream discarded the invalid route. The reverse complexity is possible too: one operator may filter on selected external sessions while maintaining exceptions, staged deployment or other treatment elsewhere. “This user did not reach the invalid beacon” and “this autonomous system configured reject-invalid everywhere” are different claims.

Concentration is a strategy, not yet a measurement

NIXI’s chief executive offers a serious reason not to count every network equally. APNIC’s announcement attributes to him the view that a small number of large operators carry most of India’s Internet traffic, and that their ROV adoption alone could meaningfully improve routing security for the economy.

That hypothesis may be right. A programme that reaches the networks carrying the largest share of paths and users could produce more protection than one that trains a long tail of small ASNs but never reaches production. The user-centric APNIC Labs measure is also relevant because it gives more weight to where users actually encounter the routing system.

Yet concentration makes the denominator more important, not less. The announcement does not name the operators, quantify their traffic share, define which traffic is in scope, distinguish domestic peering from transit, or show which session classes would carry an invalid-route policy. An operator with a large retail base may still rely on several upstream and peering paths. A policy deployed on one border is not automatically a policy experienced on every path.

Counting operators would miss that exposure. Counting users would not identify the responsible control. Counting covered route objects would measure a different side of the exchange. A traffic-weighted measure could be informative, but only after the traffic method, sampling boundary and cohort are disclosed. The national result has to join these observations without melting them into one score.

A five-surface deployment receipt

APNIC’s Board-approved 2026 Activity Plan already points in the right direction. It calls for reporting assistance to Members that create and maintain valid ROAs and its measurable impact, assistance to identified operators deploying ROV and its measurable impact, and Asia-Pacific RPKI usage reporting every six months. The plan does not prescribe a receipt. It does recognise that activity and impact are not the same report.

A useful public receipt would keep five surfaces intact.

First, the ROA record should name IPv4 and IPv6 separately, state whether the unit is route objects or address span, split Valid, Invalid and NotFound, and bind every percentage to a cutoff and dataset version. A rising valid-ROA share is real progress on authorisation. It is not downstream enforcement.

Second, the I-ROV observation should carry the beacon method, economy-assignment method, observation counts, window, timestamp and known path-attribution limit. Publishing several windows is better than picking the most flattering one. A change should be described as a changed measurement unless the evidence also joins it to a deployment event.

Third, the operator-policy record should identify the target cohort, publicly or through a stable privacy-preserving code, and state the ASNs or bounded count, rollout date, policy generation, covered customer, peer and transit session classes, exception rules and rollback state. It need not expose router addresses, customer data or sensitive topology. It must expose enough scope to make “deployed” falsifiable.

Fourth, the exposure record should describe the traffic-share method, user or path coverage, observed handling of controlled invalid announcements, incident and exception results, and the post-rollout observation period. This is where NIXI’s concentration thesis can be tested. If a few operators account for most of the relevant exposure, the receipt can show it without pretending every Indian network changed.

Fifth, the enabling record should report the repository mirror against explicit access and resilience baselines, and training through stages such as attendance, lab completion, planned change, production change and retained configuration. A nearby mirror may improve data retrieval. A successful course may make deployment possible. Neither should be booked as filtering until the policy record says so.

The join key is the quiet part of the design: cohort and date. Without it, five dashboards remain five anecdotes. With it, the programme can say that a defined set of operators received assistance, deployed a stated policy scope, covered a measured share of paths or traffic, produced a bounded user-side change, and did so while ROA coverage and repository access were in a known state.

What the receipt must not claim

The MoU is one day old at the evidence cutoff. It cannot be evaluated as though it were a finished deployment. The July 0.99% figure should not be subtracted from 88.04% to manufacture an 87.05-point “gap”; the measures do not share a denominator. The September window values should not be presented as proof of a sudden rollout. The frozen sources identify no large operator as an adopter or non-adopter.

Nor does origin validation secure the whole AS path. A matching ROA helps determine whether the announcing origin is authorised for a prefix. ROV does not by itself attest every relationship in the route, eliminate every leak, or decide the operator’s local response. A careful programme can make a large improvement without pretending to solve a larger problem.

Sources