Summary

  • A 2023 Japanese ROV trial organized adoption around three checks: normal operation, protection from Invalid routes, and the ability to recover when something went wrong.
  • The public record documents an experiment-to-guideline chain. It does not show that all 18 RPKI participants rejected routes in production, that nobody suffered an outage, or that JANOG or JPNIC controlled an operator’s routing policy.

Security projects often describe failure as the condition they are designed to prevent. This one did something more useful: it put failure inside the test. Before an operator could treat Route Origin Validation as ready, the exercise asked whether the network would continue to work normally, whether the control would act on an Invalid route, and whether the operator could respond if the control itself produced an unwanted result.

That sequence is the governance story. It does not prove that ROV was harmless. It shows that adoption was framed as a reversible decision rather than a one-way technical upgrade.

The work surfaced publicly at JANOG52 on 5 July 2023. JANOG convened the discussion and published the programme and presentations by Taiji Kimura of JPNIC, Katsushi Yamaguchi of BIGLOBE and Osamu Nakamura of Keio University and WIDE. But the conference was not the project owner and it did not acquire authority over participating networks.

The authority chain was more distributed. Japan’s Ministry of Internal Affairs and Communications sponsored the project. NTT Communications was the prime contractor. Mitsubishi Research Institute and JPNIC supported it as subcontracted actors. JPNIC planned parts of the RPKI and DNSSEC experiment, designed and operated test environments, compiled results and later issued the guideline. Facilities were hosted at Keio University, Osaka University through the Cyber Kansai Project, and the University of Nagasaki. Participating organizations carried out tests. Each autonomous system still decided its own route policy.

JPNIC’s FY2023 report records 18 companies participating in the RPKI track, compared with eight for DNSSEC and ten for DMARC. Those numbers describe participation in project tracks. They are not counts of production deployments, completed roll-outs or independently certified successes.

The project offered three kinds of exposure: hands-on experience, experiments in a project environment, and verification in a participant’s own environment. This separation matters. A course in a participant environment might be closer to operational reality, but the published record does not identify which companies took which course or whether any test changed a traffic-carrying BGP session.

Inside the project facilities, engineers could introduce deliberately Invalid BGP routes and exercise ROV against ROA data. The equipment included virtual or hardware routers from Arista, Cisco, Juniper and Nokia. Multi-vendor testing broadened the exercise; it did not prove feature parity, production safety or predictable behaviour at every scale.

The trial’s “three confirmations” were more revealing than the vendor list. First, the network should normally keep operating after validation was introduced. Second, it should protect against Invalid routes. Third, the operator should be able to respond if a fault occurred. The surviving JPNIC guideline turns those ideas into an operational sequence: apply validation while continuing to accept Invalid routes so load and affected routes can be observed; verify deliberately Invalid examples; then verify that a local exception or policy change can restore a route that has been classified Invalid unintentionally.

That last step is not a loophole outside the security design. It is part of the design. The guideline documents removal of ROV policy, router-restart checks, cache reconnection and responses to unintended Invalid classifications. Where cache disconnection might exceed a hold period, it discusses stopping ROV for a neighbour or router, or using SLURM so Invalid or NotFound routes are not discarded.

But reversibility needs its own boundary. SLURM produces a local, customized view of RPKI information; it does not correct the global system. A local override can preserve reachability while also creating a separate trust decision. The public material does not say who approved such exceptions, how long they lived or how they were reconciled later.

The standards explain why the policy boundary belongs to the operator. RFC 6811 makes origin-validation state a local property of a route. Validation alone must not silently remove a route; filtering or preference changes require explicit local policy. It also warns that manipulated validation data can become a denial-of-service vector. ROV checks the relationship between a prefix and its origin AS. It does not validate the complete AS path, and a technically correct state does not decide what an operator ought to do with it.

One presentation added a snapshot of potential exposure. At 09:00 on 8 March 2023, an AS2500 RIB contained 905,690 IPv4 routes, of which 77 were Invalid, and 170,405 IPv6 routes, of which 231 were Invalid. That is one stored route view from one AS at one moment. It measures neither packets nor customers, and it cannot tell us what rejecting those routes would have done across Japan.

The process continued after JANOG52. JPNIC’s report records a JANOG52.5 follow-up on the experiment and guideline. JPNIC later formally published the document, and Version 1.1 was current on 27 March 2026 under an expert team. That is evidence of institutional learning, not evidence of universal adoption.

The most defensible success criterion is therefore modest and practical: could an operator see an unintended outcome, retain the authority to act, and get back to a known state? The trial made that question visible. The public record does not yet tell us how often participants had to answer it.