Summary

  • RIPE Atlas allows one host up to two software probes behind one IP address and four behind one BGP-visible prefix; across hosts, it caps one IPv4 prefix at 32 probes and one IPv6 prefix at 64.
  • The policy is candid about cost, limited information from dense deployment, exceptions and adjustable maxima. The unresolved evidence question is how a particular BGP route state became a particular held cohort.
  • A privacy-safe hold-decision receipt should bind the time, routing view, resolved prefix, counts, threshold tier, release condition and exception review without exposing hosts or teaching evasion.

Four numbers and a changing boundary

RIPE Atlas has a practical scarcity problem. Every connected probe consumes central resources. Many software probes on one network can also produce results similar enough that the marginal information is small. The system nevertheless rewards active hosts with credits, so the platform has both a reason to welcome useful deployments and a reason to prevent the reward from encouraging dense replicas.

RIPE NCC put numbers on that compromise in an April 2026 rollout message. One host may connect up to two software probes from the same IP address. The same host may connect up to four from the same IP prefix “as seen in BGP”. Across all hosts, no more than 32 may connect from one IPv4 prefix, or 64 from one IPv6 prefix, again “as seen in BGP”. A probe above a limit is not allowed to connect until another drops out.

The four limits are not four versions of the same test. Two is an account-and-address rule. Four is an account-and-routing-prefix rule. Thirty-two and 64 are system-wide routing-prefix rules, separated by address family. A host can pass one test and fail another. The policy therefore needs to remember not only a count but which population was counted.

RIPE NCC did not present the numbers as immutable natural constants. The message says the maxima may be adjusted. It also recognises a case in which several probes appear to share a network while being geographically dispersed, and invites the host to explain the deployment by email so that a limit can be relaxed. At rollout, it estimated that 71 probes belonging to 13 hosts were in scope. That is a dated planning snapshot, not a current tally and not proof that 71 probes were eventually held.

The phrase “as seen in BGP” does important work. It avoids treating a registry allocation, an ASN or a host’s typed description as the operating network boundary. It uses the Internet’s observable routing structure. But a BGP-visible prefix is not welded to the probe. Announcements can become more specific or aggregate; they can be withdrawn; an origin can change; different observation points can see different states. The probe need not move for its apparent cohort to move.

That last step is an inference from network mechanics, not a reported failure. The public record reviewed here does not identify a probe that was held solely because a route changed. Nor does it tell us which routing source, collectors, visibility threshold, observation time or prefix-selection rule the enforcement system uses. Those unknowns are precisely why the decision state should be retained.

The large-prefix objection was substantive

The public discussion thread quickly tested the assumption that proximity inside a prefix means redundancy. Robert Scheck asked whether the cross-host rule would affect AS3209 or AS3320. He recalled using multiple probes in a large access network to investigate a case in which probes inside the same BGP-visible prefix behaved differently.

That is not proof that every extra probe deserves admission. It is evidence that prefix membership and measurement interchangeability are different concepts. A large consumer prefix can contain access paths, aggregation equipment, local policies and failure domains that do not collapse into one experience merely because the global routing table presents a common covering route.

RIPE NCC’s reply, preserved in the official thread-replies record, was measured. It said the limits had been chosen not to affect the number of software probes usually connected in those large networks. It would monitor the situation, and the algorithm could later give big prefixes more leeway. This is evidence of an acknowledged tuning surface, not a promise that every large prefix will receive a separate quota.

The exchange also asked a simpler operational question: would a host see a specific reason, rather than merely a disconnected probe? RIPE NCC said a specific tag would be added and that the 13 hosts in the rollout estimate would be contacted before enablement. The 15 July release notes now say that a probe’s overview tells its host when it is on hold because of a farming violation.

That improvement matters. A named hold separates deliberate admission control from an ordinary network or controller failure. It tells the host which kind of problem to investigate. Yet a label is not a receipt. “Farming violation” does not say whether the operative test was two, four, 32 or 64; which prefix was resolved; what the count was; or when a changing route state will be reconsidered.

A prefix field is not decision provenance

The current probe-management FAQ repeats the four limits, the BGP-prefix wording and the geographically dispersed exception route. The wider hosts and sponsors FAQ supplies the incentive context: hosts earn credits, while RIPE Atlas seeks a topologically diverse network and explicitly wants to deter credit farming.

The public probe-list API reference documents prefix_v4 and prefix_v6. That is useful descriptive state. It does not, in the material reviewed, define a farming-decision object joining a prefix field to a threshold, a cohort, a route snapshot and a review. Nor should every internal anti-abuse feature automatically become a public API. Exact addresses and account associations can be sensitive; excessive detail can assist gaming.

The proper demand is narrower. The affected host and the operator need enough durable information to reproduce the decision. The public needs aggregates that show how the policy behaves without identifying deployments. Those are different disclosure layers.

RIPEstat’s BGP State documentation is helpful as an illustration, not as a claim about the Atlas implementation. It shows the kinds of coordinates a reproducible route observation can carry: a resource, a timestamp, selected route collectors, source identifiers and query time. Nothing reviewed here says the anti-farming system uses RIPEstat, RIS, all RIS collectors or that endpoint’s computation. The lesson is simply that “seen in BGP” can be made much more exact than a phrase.

What the receipt should bind

A useful private receipt begins with a decision timestamp, address family and a privacy-protected representation of the source address. It records the prefix that the system resolved at that moment, the route-state timestamp and the routing-data boundary used to resolve it. If multiple covering or competing routes were visible, it records the choice rule rather than requiring the host to reconstruct one later.

Then it names the test. Was the probe the third from the same host and address, the fifth from the same host and prefix, the thirty-third in an IPv4 cohort, or the sixty-fifth in an IPv6 cohort? The receipt records both the count immediately before the decision and the applicable maximum. It also states how admission order is determined when several probes arrive around the same time.

Finally it records the release path. “Until others drop out” is understandable policy language, but an operator needs to know when the cohort is recounted, whether a routing change triggers reevaluation, whether a queue exists, and what event returned the probe to service. An exception record should carry the request time, disposition, reviewer, rationale class and expiry without publishing the host’s sensitive explanation.

The public counterpart can be aggregate: holds and releases by threshold tier and address family; time-to-release distributions; the number and outcome of exception requests; changes caused by threshold revisions; and a privacy-safe count of reevaluations following prefix-boundary changes. If those numbers reveal a gaming risk at low volume, they can be delayed or bucketed.

This proposal does not presume that RIPE NCC lacks internal logs. It asks for an explicit evidence contract between a host-visible sanction-like state and the mutable network observation that produced it. It also does not call every affected host a farmer. “Farming violation” is the product’s state label; threshold membership alone is not a finding of bad faith.

Sources