Summary

  • AFRINIC’s Resource Certification page labels a live link “RIPE NCC Validator”, but the destination identifies itself as Routinator; AFRINIC’s separate relying-party page also calls the same RIPE service Routinator.
  • The live redirect avoids a dead end, but it does not preserve software provenance. A versioned guidance manifest should bind every tool label to the implementation, maintainer, service operator, support state, tested version, intended use and migration record.

A dead link announces its own failure. A successful link can conceal a quieter one. On 8 September 2026, the Validators section of AFRINIC’s main Resource Certification page offered “RIPE NCC Validator” as a clickable choice. Follow it and the address remains familiar—rpki-validator.ripe.net—but the returned document is titled “Routinator”. Its own description calls it the user interface for Routinator, with a Prefix Check and statistics from validation runs.

That is not a recent or secret substitution. RIPE NCC announced in June 2021 that support for its validator would end on 1 July. It urged operators running the old software to move to alternatives and stated why maintenance status mattered: without updates, continued use could lead to security incidents. In September of the same year, RIPE NCC described the next step. The public service at the old hostname would be migrated to Routinator on 16 September. The URL survived; the software behind it did not.

AFRINIC already has the corrective fact elsewhere on its own estate. The page at validator.afrinic.net is headed “RPKI Relying Party Software”. It lists an AFRINIC-hosted Routinator and, among other options, labels the RIPE endpoint “RIPE NCC: Routinator”. Place the two AFRINIC pages side by side and the discrepancy becomes narrow and verifiable. One surface names the current implementation. The main guide retains the predecessor’s product name.

A redirect is not a change record

There is a generous reading. Whoever maintained the link preserved a useful service for readers. An operator who clicks does not arrive at an abandoned download page; the operator reaches a working Routinator interface. The separate AFRINIC recommendation page gives the implementation its correct name. Experienced routing teams should in any case install relying-party software from a maintained project or package channel, not treat a public web interface as their production validator.

All of that is true, and none of it closes the record.

A hostname can be stable while the code, maintainer, support terms and intended use change. Here the old name and the new implementation occupy the same URL. A reader looking only at the AFRINIC label could reasonably understand “RIPE NCC Validator” as the software being named. A reader looking at the destination sees Routinator. A procurement file, operating runbook or training slide copied from one side will record a different dependency from a file copied from the other. The link’s success suppresses the ordinary signal that would force someone to reconcile the two.

The distinction is especially important because RIPE NCC’s migration account drew another boundary: its public validator service was best-effort and was not recommended as a production dependency with guaranteed uptime. “Which product is this?” and “what may I rely on it for?” are separate questions. Neither can be answered from a durable URL alone.

The software sits inside the evidence chain

RPKI relying-party software is not merely a dashboard skin. RFC 8897 describes an RP as the software that acquires and verifies Internet Number Resource data from the repository system. The resulting validated information supports BGP decisions. The RFC collects baseline requirements scattered across thirteen technical documents into four broad jobs: fetching and caching repository objects, processing certificates and revocation lists, processing signed objects, and distributing validated data.

That does not mean every visitor to a Prefix Check is outsourcing a router decision to the displayed service. A public checker may be used for inspection or troubleshooting, while an operator’s production RP runs elsewhere. It does mean that a product name carries operational meaning. It points to a particular implementation, release lineage, defaults, defect history, maintainer and migration path. Replacing the name with a hostname discards that context.

NLnet Labs’ stable documentation makes the current identity concrete. Routinator 0.15.2 exposes a web interface on the /ui path. It can show Prefix Check results and information from the last validation run, along with HTTP and RPKI-to-Router connection metrics. Those are the same identifying features declared by the live RIPE endpoint. The observed destination is therefore not merely a generic page wearing a new title; it presents the documented Routinator interface.

AFRINIC’s main list also names RPKI.net rcynic and RPSTIR. The checked page does not show versions, maintainers, support states or verification dates for them either. That observation is not a licence to declare those entries unsafe or unsupported. This evidence package does not establish their current lifecycle. It establishes that the catalogue gives the reader no visible way to tell.

Publish the join, not another recommendation

The remedy need not be a security certification programme. AFRINIC does not have to warrant every line of third-party code, predict every vulnerability or choose one validator for every network. It needs a small public join between the guidance it displays and the dependency a reader will actually meet.

A versioned relying-party guidance manifest could carry one row for every listed tool or service:

  • the exact displayed label and canonical product name;
  • the implementation project and current code maintainer;
  • the operator of any hosted service and its final URL;
  • lifecycle state, supported release line and last verification date;
  • the function AFRINIC checked, such as public Prefix Check or repository validation;
  • the intended use: demonstration, best-effort inspection, evaluation or production;
  • the predecessor and migration target when an implementation changes;
  • the authoritative support or security notice;
  • the date and reason for correction, retirement or removal.

Prior versions should remain visible. That last detail matters. Silently correcting “RIPE NCC Validator” to “Routinator” would improve today’s page but erase the answer to a later question: when did AFRINIC’s public guidance acknowledge the 2021 migration? A manifest turns an editorial fix into accountable provenance.

The unit of evidence should also remain narrow. “Link checked” proves reachability. “Page title checked” supports an implementation identification. “Release tested” requires a version and a defined function. “Suitable for production” needs an explicit basis and should not be inferred from the existence of a public endpoint. One green mark cannot stand for all four.

What this record does not prove

Nothing in the captured pages shows that AFRINIC distributes the retired RIPE NCC code. The link is not broken. The live RIPE service identifies itself as Routinator, and AFRINIC’s other recommendation page does too. There is no evidence here that an operator installed the wrong package, that AFRINIC’s repository produced invalid data, that a route was accepted or rejected incorrectly, or that any security incident occurred.

Nor can the absence of visible version fields prove that the pages have never been reviewed. A maintainer may have checked every destination recently and left no public receipt. The finding concerns what a reader can verify, not what an internal team may know.

The narrow problem is enough. RIPE NCC made a lifecycle decision, communicated an end-of-support date, changed the implementation behind a durable service address and documented the migration. AFRINIC’s own secondary page reflects the new identity. Its main RPKI guide does not. In a system built to turn distributed assertions into verifiable routing evidence, the tools used to read that evidence deserve a traceable name.

Sources