Summary

  • LACNIC’s pinned migration-validation launcher uses rpkic_rpkiv5_cache in both rpki-client actions, but changes its container destination from /var/cache/rpki-client to /root/cache.
  • A named volume can persist while its attachment point changes. The source alone does not establish where the selected image actually reads its cache, or whether any run lost cached data.
  • The image, shared command arguments and trust-anchor bind remain the same in the two actions. The other three reviewed launchers preserve their respective cache destinations.
  • These are historical scripts at a 1 April 2024 commit, inspected on 14 September 2026—not evidence of a new migration, a failed production cutover or an executed validator test.

The storage survives; the coordinate moves

The two lines agree about the thing Docker should preserve. They disagree about where the next container should find it. In rpkic_run.sh, the action named current attaches the named volume rpkic_rpkiv5_cache to /var/cache/rpki-client. The action named rpkiv5 attaches the same named volume to /root/cache. The left-hand side of the volume expression stays still; the right-hand side moves.

That is a small difference with a precise evidential consequence. The repository’s README describes an experiment in which a relying party first validates against the existing service, populates its cache, stops, and then runs against the replacement service with the cache carried forward. A relying party is the software that processes RPKI material and produces validated routing information. The intended comparison is not simply between two fresh installations. It is between one service and its replacement as seen by an application with prior state.

Preserving a Docker volume is a sensible way to carry that state across a container’s lifetime. It does not, by itself, show that the application in the replacement container sees the state at the path it uses. Docker’s official documentation distinguishes the volume source from the mount destination inside the container. The name selects the backing store; the destination selects the container directory where its contents appear. The script supplies evidence of the first continuity and changes the second coordinate. The rpki-client launcher and Docker’s volume documentation support that distinction.

The application could nevertheless reuse the intended cache. The image might select another path, provide an alias, or arrange its directories in a way the launcher alone does not reveal. None of those possibilities has been checked here. Nor has the contrary outcome—a cold cache, discarded data or a failed migration. The finding is a changed attachment coordinate in a public experiment, not a demonstrated failure of the application behind it.

What the experiment was trying to hold constant

The README is unusually useful because it states the sequence rather than merely offering container commands. Start the current action, wait for a first complete run with the cache populated, stop that container, and start the rpkiv5 action. The replacement action uses a hostname override to direct the application towards the replacement RRDP service. RRDP is the repository-fetching surface named in the scripts. The README then asks the operator to compare outputs manually, giving the number of valid route-origin payloads, or VRPs, as an example.

That description makes cache continuity part of the experiment’s design. A result from an application carrying prior state answers a different question from a result obtained after discovering everything afresh. The difference need not make either result bad. A fresh-state test can be valuable in its own right. It simply cannot silently stand in for the cache-preserving sequence the README proposes. The issue is attribution: what was changed, what was retained, and which observation belongs to which starting condition?

There is also a date boundary. The inspected repository state is the immutable commit fdbecab2890e0da2f9a393ac4be2659d14f54ca2, dated 1 April 2024. It was reviewed on 14 September 2026. The README’s note that a child CA had not yet been replicated belongs to that historical description. It cannot establish what is replicated today. This article does not announce another migration or reconstruct the actual 2024 execution. The historical README describes intent, not a present-day service report.

The strongest counterevidence is in the same script

The rpki-client launcher does not change everything. Both actions use the image string rpki/rpki-client:8.2. Both bind the local trust-anchor directory to /etc/tals. Both use the shared argument string -s 480 -c -v -v -v and the same detached/custom-DNS options. Alternative image versions appear as comments, not active selections. Those are positive controls in the published source and should travel with the criticism.

The image string is not an inspected image digest, however. No image has been pulled or examined, and no entrypoint, directory alias, permission arrangement or effective application cache path has been verified. This review also does not assign version-specific meanings to the command-line flags. It records that the same strings appear on both sides. That is enough to narrow the question to the changed volume destination without pretending to have completed a container audit.

The replacement action additionally maps the RRDP hostname to 96.126.99.186. That address is an input in the historical launcher; this review has not contacted it. A service-address change is expected in a migration experiment. The storage-path change is a separate input. If the image resolves both destinations to the same effective cache, the experiment may preserve the intended state. If it does not, a subsequent result could mix a service change with a starting-state change. The public launcher alone cannot choose between those explanations.

Not a general defect in every launcher

The adjacent scripts matter because they prevent an institutional generalisation. The FORT launcher attaches its named volume at /root/cache in both actions. Its replacement action also supplies RRDP and repository hostname mappings. The newer Routinator launcher keeps /home/routinator/.rpki-cache in both actions. The older, pre-0.12 launcher preserves that same destination within its own pair and selects the image string v0.10.1.

These are comparisons of source instructions, not certificates that three applications reused their caches correctly. Nevertheless, they show that a changed destination is not necessary to express the repository’s migration sequence. They also confine the observed discrepancy to the reviewed rpki-client pair. “The harness changes one application’s mount destination” is supported. “LACNIC’s validators lose their caches” is not. The relevant counterpoints are in the FORT launcher, the newer Routinator launcher and the older Routinator launcher.

There are other visible differences worth recording without turning them into another accusation. The newer Routinator script’s current action uses a shared server argument string with --refresh=120; its replacement action supplies a separate inline string without that explicit option. The effective default is not established here. The dnsmasq configuration contains replacement RRDP/repository mappings and commented older mappings, while the README discusses editing the DNS option if that service is not used. Neither file establishes which DNS service actually ran in an experiment. These inputs belong in a matched run record, not in a claim about an observed refresh delay or a baseline already pointing to the wrong service. The captured DNS configuration is configuration evidence only.

Persistence is a narrower promise than reuse

Docker documents that a named volume can outlive the container that used it. Reusing its name in a later container is therefore meaningful; changing a destination does not itself erase the backing data. Docker also explains that mounting over an existing container directory can obscure that directory’s image contents, and that an initially empty volume can receive pre-existing container contents under the default copying behaviour. These are platform rules, not observations of this image or its cache.

Three identities should remain separate. The store is the host-managed volume. The attachment is the directory exposed inside a particular container. The application state is the material the relying party actually reads and treats as its cache. A stable store name proves neither a stable attachment coordinate nor the application’s use of that coordinate. Conversely, a moved attachment proves neither deletion nor loss of useful state. Keeping these identities separate avoids both an unearned continuity claim and an unearned failure claim.

The README’s suggested VRP-count comparison adds a fourth distinction: output size is not output identity. Two sets can have the same number of entries while differing in membership. This is ordinary comparison logic, not a finding that these outputs differed. A count can be a useful first observation and still be insufficient for the more specific claim that a matched migration preserved the intended validated view from an established cache. The reviewed source package does not supply a completed paired execution receipt establishing that claim.

Sources

The seven linked documents comprise six immutable files in LACNIC’s public repository and Docker’s official volume documentation. They come from two publication sites, not seven independent investigations. The review reads instructions and documentation; it does not execute the scripts, inspect a live validator or certify a production outcome.