要約

  • 過去の rpkic_run.sh は両方の処理で rpkic_rpkiv5_cache を選ぶ一方、接続先を /var/cache/rpki-client から /root/cache に変えている。
  • 名前付きボリュームの存続は、アプリケーションが以前のキャッシュを使うことの証明ではない。選択されたイメージの実効的なキャッシュパスは今回確認していない。
  • イメージ文字列、共通の引数、トラストアンカーの接続は同じである。他の三つの起動スクリプトは、それぞれの接続先を維持している。
  • 対象は 2024 年 4 月 1 日の固定コミットを 2026 年 9 月 14 日に調べたものだ。新たな移行や本番障害を報告せず、コンテナや検証器を実行していない。

「残っている」から「使われている」まで

移行前のキャッシュを引き継いだ、という説明には少なくとも二つの条件がある。以前のデータが保存されていること。そして次のアプリケーションが、そのデータを意図した場所から読んでいることだ。LACNIC の公開移行検証ツールでは、最初の条件を支えるボリューム名は変わらない。しかし、コンテナ内でデータを見せる位置は変わる。この間にある関係を、名前だけで埋めることはできない。

リポジトリの README は比較の順序を明示している。まず現在のサービスに対して依拠当事者ソフトウェアを動かし、最初の処理が完了してキャッシュが満たされるまで待つ。そのコンテナを止め、同じキャッシュを引き継いで置き換え先のサービスに対する処理を開始する。ここでの依拠当事者は、RPKI の資料を処理して検証済みの経路情報を作るソフトウェアである。

この目的にとって、キャッシュは便利な付属品ではない。比較開始時の条件そのものだ。既に取得した状態を持つソフトウェアと、何も持たずに最初から情報を発見するソフトウェアでは、調べている状況が異なる。新規状態での試験にも価値はある。ただし、それを README のいう状態引き継ぎの試験として説明するには、追加の観察が必要になる。

rpki-client の起動ファイルは、この点を具体的に追える。current という処理は rpkic_rpkiv5_cache を /var/cache/rpki-client に接続する。rpkiv5 という処理も同じ名前のボリュームを選ぶが、接続先は /root/cache だ。ホスト側の保存先を選ぶ部分は同じで、コンテナ内の座標を指定する部分が異なる。これは公開された指示の差であり、実行結果の差ではない。

Docker が約束する範囲

Docker の公式資料は、ボリュームのソースとコンテナ内の接続先を区別する。名前付きボリュームは、それを使ったコンテナが削除されても存続し、別のコンテナで再利用できる。ソースの名前はどの保存領域を選ぶかを決める。接続先のパスは、その領域の内容がコンテナ内のどこに現れるかを決める。アプリケーションがどこを読むかは、それとは別の関係だ。

したがって、同じボリューム名は重要な肯定的証拠である。スクリプト上、保存領域を別物に置き換えているわけではない。接続先が変わっても、そのこと自体がデータを消去するわけではない。一方で、保存領域が残るというプラットフォームの性質を、アプリケーションのキャッシュ再利用まで広げることもできない。両方向の飛躍を避ける必要がある。

イメージ内部の設定やディレクトリの別名によって、二つの接続先が実質的に同じ役割を果たす可能性はある。起動処理が別のキャッシュ位置を選ぶ可能性もある。今回、そのイメージ、入口処理、シンボリックリンク、権限、実効的なパスは確認していない。したがって、再利用できたとも、キャッシュなしで起動したとも断定しない。疑問はまだ解決していない。

Docker はさらに、既に内容のあるコンテナ内ディレクトリへマウントすると、そこに元々あったイメージのファイルが見えなくなる場合を説明している。初めは空のボリュームに、既存のコンテナ内容が既定のコピー動作で入る場合も説明している。これらは接続先が意味を持つ理由だが、今回選ばれたイメージで何が起きたかを明らかにするものではない。

日付は結論の一部である

確認したのは fdbecab2890e0da2f9a393ac4be2659d14f54ca2 という固定コミットであり、日付は 2024 年 4 月 1 日である。調査日は 2026 年 9 月 14 日だ。公開されている歴史的ツールを今読むことは、その資料を現在の移行計画や稼働状態へ更新することではない。本稿は当時の実行履歴を再構成せず、今日の本番コンテナ構成も示さない。

README の置き換え側の処理は、ホスト名の対応を変えて新しい RRDP サービスへ向ける。RRDP はスクリプトが指定するリポジトリ取得の接点である。その後、出力を手作業で比較し、有効な経路起点ペイロード、VRP の件数を例として挙げる。これは検証の意図を説明する記述であり、その比較が実際に完了したことの記録ではない。

README には、子の認証局がまだ複製されていないという当時の注意書きもある。この記述を現在の未複製状態の告発に使ってはいけない。歴史的な制約は、その時点の説明として残すべきである。同様に、ファイルに書かれたサービスアドレスを実際の接続先や現在の運用先として扱うことも、本稿で取得した証拠の範囲を超える。

調べた資料一式には、二つの処理でアプリケーションがどのキャッシュを読んだかを確定する、完了した対の実行記録は含まれていない。これは内部で一度も試験しなかったという主張ではない。公開指示から分かることと、実行観察から分かることを分けている。前者が不足を見つけるきっかけになっても、後者を想像して埋めることはできない。

同じファイルにある反証を落とさない

rpki-client の二つの処理は、多くの文字列を共有する。イメージは rpki/rpki-client:8.2。ローカルのトラストアンカーディレクトリは、どちらも /etc/tals へ接続される。引数は共通の -s 480 -c -v -v -v。バックグラウンド実行と独自 DNS の共通オプションも同じである。別のイメージバージョンはコメントであり、実行する選択として読んではいけない。

これは何もかも無制御に変える実験という物語への反証になる。イメージ選択、信頼入力、共通の引数、ボリュームのソースは、少なくとも指示の段階で維持されている。批判はこの事実を残したうえで接続先の違いに絞るべきだ。懸念を強く見せるために一致点を捨てると、実験のどの関係が未確認なのか、かえって見えなくなる。

もっとも、イメージ文字列が同じことは、実際のイメージを検査したこととは異なる。今回、イメージの取得やダイジェストの確認はしていない。引数の意味についても、版に固有の根拠なしに説明を追加しない。同じ文字列が二つの処理に現れる、という静的な観察が限界だ。これを容器内部の動作保証に変えることはできない。

置き換え処理には RRDP のホスト名を 96.126.99.186 に対応させる設定が追加される。このアドレスには接続していない。サービスの変更は移行実験の目的に沿うが、保存領域の見せ方の変更は別の入力である。もし後者が実効的なキャッシュを変えるなら、出力を前者だけに帰属させることは難しくなる。今あるソースは、その仮定を確認も否定もしていない。

隣の起動処理が示す限界

FORT の起動ファイルは、現在側と置き換え側の両方で /root/cache を保つ。置き換え側には RRDP とリポジトリのホスト名対応が加わる。新しい Routinator のファイルは、両側で /home/routinator/.rpki-cache を保つ。0.12 より前の版向けのファイルも、自分の二つの処理ではその接続先を維持し、イメージ文字列 v0.10.1 を選ぶ。

これらはキャッシュの正しい再利用を証明する実行結果ではない。しかし、公開ツールの移行手順に接続先の変更が一般的に必要なわけではないと分かる。観察された差は rpki-client の対に属する。「公開スクリプトの一組で接続先が違う」は支持できる。「LACNIC の検証器全体がキャッシュを失う」は支持できない。対象を広げるには別の証拠がいる。

隣接ファイルには副次的な比較条件も見える。新しい Routinator の現在側は --refresh=120 を含む共通のサーバー引数を使う。置き換え側は独自に引数を書き、同じオプションを明示しない。この版の実効的な既定値は調べていない。したがって、更新遅延や異常を観察したとは言わず、対の実行記録に残すべき入力の差としてだけ扱う。

dnsmasq の設定は置き換え先の RRDP とリポジトリへの対応を含み、過去の対応をコメントとして残している。README は、この DNS サービスを使わない場合のオプション編集にも触れる。どの DNS サービスが実際に動いていたかは確認していない。設定だけで現在側の基準が既に置き換え先を向いていたと推測すれば、別の未確認の物語を作ることになる。

件数より前に、開始状態を知る

VRP の件数は、比較の入り口として分かりやすい。だが同じ要素数の集合が、異なる要素を持つことはあり得る。これは本稿が出力差を見つけたという意味ではない。件数という観察が答える質問は、集合の一致より狭いというだけだ。その一致さえ、前のキャッシュを使ったことを直接示すわけではない。結果と由来は分ける必要がある。

キャッシュが満たされた状態での比較を主張するなら、以前の状態が保存され、その状態を次のアプリケーションが実際に使った関係を示す必要がある。空の状態からの発見試験なら、そう明記して評価できる。問題は試験の価値を下げることではなく、実際に観察した条件と、結果に付ける名称を一致させることにある。名称が観察を追い越してはいけない。

保存領域、接続先、アプリケーション状態、出力という四つの記述を分ければ、疑問はかなり小さくなる。ボリューム名を保持した証拠は保存領域の選択に関するものだ。接続先の相違はコンテナ内の露出に関するものだ。アプリケーションが読んだキャッシュと、その状態から得た出力は、さらに別の観察である。どれか一つで残り全部を保証する必要はない。

文字列の修正と実験の説明は別である

二つのパスを同じ文字列に直せば、見た目の一貫性は改善するかもしれない。だが適切な接続先は、アプリケーションがどこを使うかに依存する。内部の配置が分からないまま同じにしても、実効的な関係を確認したことにはならない。まずその関係を示し、次に指示を修正する。この順序なら、小さな修正を過去の実行保証へ膨らませずに済む。

固定コミットも実行のすべてを固定しない。その時にホスト上でどの同名ボリュームが使われたか、イメージタグが何を指したか、アプリケーションが既に何を取得していたかは、別の記録である。それらが変化したと決めつける必要はない。ただ、実行に関する結論を出すなら、ソースの同一性だけに全責任を負わせられないと認める必要がある。

懸念を解消する資料にも、明確な居場所があるべきだ。二つの接続先が実質的に等価であるという版固有の説明が得られれば、結論を狭める。一組の実行が旧キャッシュを利用した観察が得られれば、その実行についての判断を更新する。それをすべての版と環境に拡大しない。疑問を永久に維持することではなく、解決条件を明示することが目的だ。

観察と仮定を分ける

公開指示を読む人が必要とするのは、すべての未知事項を一度に消す保証ではない。どこまでが観察で、どこからが環境についての仮定かという境界である。この場合、同じソース名と異なる接続先は観察である。二つのパスがアプリケーションにとって等価かどうかは仮定のままだ。その境界を表示すれば、次に調べる対象も小さくできる。広い安全性試験に話を移さず、イメージがどの位置を使うかという関係に集中できる。

説明は結果の前にも役立つ。実行者が試験を始める前に有効なキャッシュ位置を確認できれば、後で出力差を解釈するときに開始条件を探し直す負担が減る。これは今回その負担が発生したという報告ではない。簡潔な指示を次の利用者へ渡す際、関係を明記することの利点である。同じ名前を繰り返すだけでは持ち運べない前提を、短い説明で共有できる可能性がある。

資料

根拠は七つの文書である。歴史的 README、rpki-client の起動ファイル、FORT の起動ファイル、新しい Routinator の起動ファイル、古い版向けの起動ファイル、DNS 設定、Docker のボリューム資料を読んだ。公開元は二つであり、七件の独立調査ではない。コンテナ削除、ボリューム整理、検証器の実行は行っていない。