Summary

  • RIPE NCC's Routing Information Service collects BGP updates through globally distributed Remote Route Collectors, typically hosted at Internet Exchange Points, and republishes them as an MRT archive with state dumps every eight hours and update files every five minutes.
  • Those same collectors also originate beacon prefixes on a published timetable, and RIPE NCC states it does not guarantee that those prefixes are visible everywhere — which makes the beacon a calibration probe rather than a certificate of reachability.
  • No document read assigns the service any duty to analyse what it records, to notify an affected network, or to correct a conclusion drawn from its data. The record is complete; the interpretive step belongs to whoever bears the consequence.

RIS describes itself without flourish: a routing data collection platform that collects data on BGP, the protocol by which traffic is routed between networks. Its collection method is the part worth slowing down for. A globally distributed set of Remote Route Collectors, typically located at Internet Exchange Points, peers with volunteers using BGP and stores the update and withdraw messages it receives. Nobody is compelled to peer. The record exists because networks chose to hand over their announcements.

What comes out the other end is deliberately boring in the way good evidence should be. RIS groups received data by route collector and publishes it as an archive of MRT files. The MRT documentation sets the cadence in one sentence: dumps are created every eight hours, updates every five minutes. The distinction matters more than the numbers. A dump captures routing state at a particular time; an update captures changes over an interval. An outside analyst holding both can reconstruct which collector saw a prefix, and when, without asking the operator for anything.

That is a real transfer of capability. A network that lost a route can compare its own logs against a public record rather than against a vendor's assurance. A researcher can test a claim. Absence becomes falsifiable: a missing file is missing in public, where anyone can see it.

Then come the beacons, and the service stops being a bystander.

RIPE NCC does not merely watch. Its collectors actively participate in the routing system by periodically announcing and retracting its own internet resources, so-called beacons, to gather more data about how different networks behave. The mechanics are published to a degree that is almost ostentatious once you read them together. The beacon documentation states a two-hour up, two-hour down schedule for all standard beacon prefixes, with announcements at 00:00, 04:00, 08:00, 12:00, 16:00 and 20:00 UTC and withdrawals at 02:00, 06:00, 10:00, 14:00, 18:00 and 22:00 UTC. Two RRC03 prefixes, 2001:7fb:ff02::/48 and 84.205.66.0/24, run a faster cycle: ten minutes announced, ten minutes withdrawn, announcing at the hour's 00, 20 and 40, withdrawing at 10, 30 and 50.

The configuration is not folklore handed down between engineers. It is a machine-readable inventory naming each beacon prefix, its originating collector and its active intervals — for instance 84.205.67.0/24 from rrc03.ripe.net, live from 00:00 to 02:00 and again in the corresponding blocks through the day. Continuously announced anchor prefixes help separate a change at the originating collector from ordinary routing noise elsewhere. And the announcements carry their own testimony: the BGP AGGREGATOR attribute, per the same documentation, holds timestamps, sequence numbers and announcement identifiers.

Put that together and the beacon is a calibration stimulus with a receipt attached. An analyst who sees a withdrawal cycle at 02:00 knows what the instrument was being asked to observe, and can tell a late observation from a missing one.

Now the sentence that governs the whole arrangement. RIPE NCC does not guarantee global visibility of these prefixes.

Read that as an operational statement rather than a hedge, and the architecture sharpens. The beacon does not certify that a route propagates to the internet. It certifies where the probe was sent and when it fired. The perimeter is checkable; the outcome is not promised. A published methodology plus a machine-readable inventory does not convert a best-effort data service into a conformance standard. It makes the field of view auditable — which is a different, and genuinely useful, achievement.

The mechanism also has a longer memory than its current form suggests. A historical page attributes the beacons in the section from 30 September 2002 to 2 February 2005 to research into unwanted effects on convergence when applying then-current Route Flap Damping practices. The instrument was built to answer an engineering question about damping, and it kept the habit.

Here the accountability trail thins. The documents read for this briefing establish thorough collection, a published cadence, a published beacon schedule and an explicit disclaimer of global visibility. They do not establish any duty to analyse what the archive contains, to notify a network whose route went missing, or to correct a conclusion someone draws from the data. Retention period and warranty language likewise did not appear in the material actually inspected.

That is not a scandal. It is a distribution of work that nobody has written down, and the practical consequence deserves to be said plainly: the power to declare an anomaly actionable defaults to whoever consumes the record — an operator reading its own graph, a researcher, or the affected network itself. Responsibility for interpretation migrates to the party with the least instrument visibility, while the party holding the archive keeps the credibility of the record without the liability of the verdict.

A record that everyone cites can acquire weight its charter never granted it. That risk is structural, not contractual, and it grows with citation rather than with any decision the operator makes. The reading that survives this documentation is the narrow, defensible one: RIS is a witness of high quality, with a published field of view and no verdict column. Treat the archive as evidence, and the burden of drawing the conclusion stays where you are standing.

The evidence boundary here is specific and should travel with the claims. The current beacon and raw-data subpages hosted on www.ripe.net produced no inspected passage; the documentation used above was read on the ris.ripe.net documentation surface, with the reachable pages describing their own updates on 13 October 2026 for the beacon page, 29 March 2024 for the MRT page and 28 November 2023 for the historical page. Nothing read establishes how the operator's registration role interacts with the measurement service, and this briefing does not assert one. The RIPE NCC Routing Information Service is filed here under its directory entry, which is thin and internally inconsistent enough — placing the service in Iran and citing a single archived project page — to be used for identification only, never as evidence about the service.

What would change the classification is a document, not more interpretation. A published analysis duty, a notification obligation, or a stated conformance guarantee would turn a passive instrument into an enforcement-adjacent surface, and the accountability question would move from who reads the archive to who answers for it. Until such a text exists, the honest description is the one the publisher itself supplied: a routing data collection platform that also announces test routes, records what comes back, and promises nothing about who sees them.

That is a strange thing to build and a valuable thing to have. A flight recorder is not asked to rule on the crash. It is asked to be honest about what its instruments could see, and to keep the tape. RIS does both, on a schedule anyone can check. The verdict was never going to be in the box.