Summary

  • ARIN Suggestion 2026.11 asks rpki.arin.net and rrdp.arin.net to answer ICMP Echo requests. Its public page says “Confirmed,” gives no timeframe and shows no implementation record.
  • An Echo reply would answer one narrow question about reachability from a particular probe. It would not prove that a relying party fetched the repository, synchronized to its latest state or validated its signed objects.
  • Operators need separate observations for network reachability, repository retrieval and signed-data freshness. A ping is useful only when its limits remain visible.

The signal arrives before the schedule

ARIN’s public record for Suggestion 2026.11 is short. Submitted on 6 October 2026 by Job Snijders, it asks that rpki.arin.net and rrdp.arin.net respond to ICMP Echo requests. The author says the replies would help diagnose connectivity and let operators monitor reachability and optimize paths. The page labels the suggestion “Confirmed,” but says the timeframe is “Not specified.” The visible Tracking Information and ARIN Comment sections contain no response or release detail.

Those are the public facts. “Confirmed” is the status label the page displays; ARIN does not define its lifecycle meaning there. It should not be expanded into “implemented,” “scheduled,” or even a promise that a release is imminent. No endpoint measurement, user outcome or incident is recorded on the page.

The suggestion also says three other ARIN services already respond to Echo requests and that other RIRs have made their public Rsync and RRDP endpoints pingable. Those comparisons are statements in the submission. They are not independent measurements for this article.

What an Echo reply can tell an operator

ICMP Echo is a familiar diagnostic because the question is simple: did a reply return from the addressed network endpoint to this probe? The answer is scoped to the probe’s location, address family, route and time. A reply can help an operator investigate an apparent path or reachability problem. It does not exercise every application path that uses the same hostname, and silence does not by itself prove that the repository service failed.

That distinction matters especially for RPKI. ARIN describes its service as publishing resource certificates and signed origin statements that network operators retrieve and validate. The repository is a source of data for relying parties; the ICMP response is not one of those signed statements and is not part of their validation result.

Three questions, three different observations

First is network reachability. An Echo reply shows that a probe received an answer at the network layer. If a monitoring system records this result, it should also identify the probe vantage, address family and timestamp. One successful vantage is not a global reachability survey.

Second is repository retrieval and synchronization. RRDP has its own application-level exchange. RFC 8182 describes an update notification file with a session identifier and serial number, a current snapshot and, where available, deltas. A relying party retrieves those files and checks their hashes before synchronizing. Rsync retrieval is another concrete service transaction. An ICMP reply performs neither transaction.

Third is the state and validity of the data. RFC 9286 defines signed manifests that list repository objects and their hashes and carry update validity information. Relying-party requirements describe how software evaluates manifest state, including stale or invalid cases. A server can answer a ping while a separate retrieval or freshness check reports a problem; a ping can also be unanswered while an application fetch succeeds. Neither mismatch is proof of an ARIN incident. It is why the signals must not be collapsed.

A useful monitoring card would keep the layers apart

If ARIN implements the suggestion, an operator-facing record could name the exact endpoint, probe scope and publication date, then keep the results in separate fields: Echo response; successful RRDP notification and object retrieval; Rsync retrieval; observed RRDP session/serial; and manifest freshness or validation outcome. Each field would need its own timestamp and measurement source. A release note could state which endpoint and address families were covered, when the change reached production, and what was checked after deployment.

This is a proposed reporting design, not a claim that ARIN has agreed to provide it. It also does not require every relying party to use ICMP. A network can decide whether Echo belongs in its own diagnostic set while still checking the repository through the protocol it actually consumes.

The distinction can make troubleshooting faster. If Echo fails while RRDP retrieval succeeds from the same relevant vantage, the first observation should not be reported as proof that RPKI publication failed. If Echo succeeds while RRDP cannot retrieve a notification or object, the reply should not suppress the application-level alert. If files arrive but the signed manifest is stale or invalid, network reachability is not the controlling fact. Each result points to a different investigation.

The ICMP request is therefore useful precisely because it is modest. It asks for an additional diagnostic signal, not a change to RPKI trust. The signal must not be asked to carry more authority than it has.

What remains unknown

As of 14 October 2026, ARIN’s public suggestion page provides no delivery date or post-implementation evidence. The present Echo behavior of the named hosts was not independently tested here. There is no evidence in the cited sources of an outage, stale repository, failed validation, routing impact or customer harm. The proposal’s label does not answer those questions.

That is the practical line for operators: record reachability as reachability, repository synchronization as synchronization, and cryptographic validation as validation. If the suggestion moves from a status label to a deployed change, the public record should make that transition visible. Until then, “Confirmed” is a published status, not a second signal.

Sources