要約

  • 調べたStarlaのソースはワークスペースのパッケージ版を0.8.0、共通のファームウェア値を5120と定義し、結果にmver=2.6.4を付ける。この組み合わせだけでは実行ファイルを一意に特定できない。
  • 登録メッセージにはStarlaの名前とコンパイル時のパッケージ版が既に入る。実装があらゆる場面で隠されている、あるいは計測が誤っているという発見ではない。
  • 互換性、配備されたビルド、実行方法、収集の欠落、独立した適合性試験は別々の証拠を要する。過去の結果を残し、不明な履歴は番号から推定して埋めないことが重要だ。

同じ番号を見て、同じ計測器が動き続けたと判断してよいのか。

Starlaの公開コードは、この問いを一般論より狭い場所に置く。2026年9月7日付のコミット82bf0d9c42883bfe4d8a20d4ee444e7a0f8b55f1では、Cargoワークスペースのパッケージ版が0.8.0である。一方、結果を整形する経路はmverに2.6.4を設定する。共通のファームウェア値は5120だ。これらは一つのプログラムの古さを競って示す数字ではなく、異なる宣言に属する。ワークスペースの版、結果の整形。

このソースの状態から、どのホストが何を導入したかは分からない。公開された版、配布されたパッケージ、実際に起動されたバイナリを同じものとして扱うこともできない。確認できるのは、調べた出力生成経路の互換性番号が、実装とビルドの唯一の識別子にはなっていないという点である。

別実装を認めることと、同一性を証明すること

開発者は2026年4月9日、RIPE NCCのフォーラムでStarlaをRIPE Atlas Software ProbeのRustによる書き直しとして紹介し、そのまま置き換えられると説明した。既存の計測サービスを別の環境から利用できるようにし、一つのコード基盤に依存しすぎないようにする意義はある。ただし、同じように計測するという説明は開発者の主張であり、本調査が独立に検証した結果ではない。開発者の紹介。

互換性を保てば、利用者の道具をすべて作り直さずに済む。従来のフィールドやタイムアウト表現を読めることは、実用上の大きな利点である。しかし、読める出力を作る二つのプログラムが、同じ依存関係、修正履歴、ビルド設定を持つとは限らない。差が観測に影響するかどうかは、さらに調べる必要がある。

Starla自身も二つの版を分けて定義している。共通のFIRMWARE_VERSIONは5120で、別の版文字列はCARGO_PKG_VERSIONから得る。ファームウェア定数の開発者コメントは、参照プローブの値に合わせる理由をコントローラーの受け入れに求める。この記述は値を選んだ側の説明であり、現在のコントローラーの規則を本調査が試験した証拠ではない。共通のバージョン定義。

違う実装であることは、それ自体で品質の否定にならない。むしろ別実装としての来歴を残せば、何を互換とし、何を試験し、何がまだ不明かを説明しやすい。参照実装と同じ数字を使うことに、同じ実行ファイルであるという追加の意味まで持たせる必要はない。

Atlasには既に計測コードの版がある

RIPE Atlasの公式文書は、fwをファームウェア版、mverを計測コードの版と説明する。mverの主番号は結果の非互換な変更、副番号は古い解析器でも読めるフィールド追加、末尾の番号は出力形式を変えないコード修正を表す。単なるJSON形式の名前より多くを伝える仕組みであり、「ソフトウェア版が全くない」と評するのは誤りだ。公式の結果バージョン文書。

その仕組みを認めたうえで、番号を付ける範囲を問う必要がある。一つのコード系列の中なら、同じ規則で付けた番号から変化を追える。別の系列が互換性のために同じ値を採用すると、値だけでは系列を区別できなくなる。調べたStarlaの2.6.4は、ワークスペースの0.8.0ではない。番号の一致は、プログラムの来歴まで一つにするものではない。

結果を解析する人は、値を読むための情報を求める。ネットワークの変化を説明する研究者は、観測方法が比較期間を通じてどう保たれたかも知りたい。同じフィールドが読めるという確認で前者は進むが、後者の仮定はまだ残る。どの程度の証拠が必要かは、結論の細かさによって違う。

通常の到達性監視に、毎回バイナリ単位の比較が必要とは限らない。一方、わずかな遅延差をネットワークの変更に帰すなら、計測器の連続性が説明の一部になる。その場合も、版が同じだから変わらなかったと断定したり、来歴が不完全だから結果が偽だと断定したりするべきではない。本調査は誤った結果も実装間の差も発見していない。

登録には名前が入る。その先は時間の問題だ

Starlaの登録コードは、重要な反証を提供する。環境を表す文字列はOS、OS版、アーキテクチャ、starla、コンパイル時のパッケージ版を含む。この文字列はファームウェア値とともに初期化メッセージへ入る。実装の名前は、サービスへ送るあらゆる情報から消えているわけではない。登録時の識別情報。

ここで未確認なのは、特定の過去の結果について、読者がどの時点の宣言とどの実行ファイルを対応付けられるかである。Starlaの出力生成コードを読むことは、RIPE NCCの内部記録全体、公開プローブ情報、結果の付加処理を監査することではない。登録情報が保存されていない、他の画面でも識別できない、と一般化する根拠は得ていない。

現在の名前が分かっても、過去の問題は残りうる。ホストはプローブのサービス上の識別を保ったままプログラムを更新できる。今日の説明は正しくても、先月の障害時に動いたビルドを示すとは限らない。パッケージ版が判明しても、その版から作られたどのバイナリかは、別の材料を要する。

役立つ単位は、一定期間に適用された生産者の履歴である。この実装宣言と、分かる場合にはこのビルドが、いつからいつまでの結果に対応したかを示す。ホストの申告、保管された登録情報、検証済みの記録を区別する。不明な期間を、5120と2.6.4だけから埋めてはいけない。

サービス上の認証も、実行ファイルの同定も、適合性の試験も、それぞれ有用だ。しかし認証が答えるのは接続を許された主体であり、特定のバイナリの動作等価性までではない。ビルドの識別も試験の対象を決めるだけで、試験が通ったことを意味しない。証拠の役割を分けるほど、既存の制御を正当に評価できる。

実装にある選択肢と、普通のジョブの選択

pingのコードには、プロセス内で動くNativeと、Linuxで利用可能なScamperの経路がある。経路の選択後、返される計測には同じ共通ファームウェア値が入る。tracerouteも両方の経路を持ち、共通値とmver=2.6.4を使って完全な結果行を組み立てる。調べた構築部分では、この番号の組み合わせはバックエンドの識別子ではない。pingの実装、tracerouteの実装。

ただし、通常のジョブを追うと制約が見える。固定したスケジューラーは、pingとtracerouteのジョブを実行可能な計測へ変換するとき、backend: Default::default()を設定する。既定値はNativeだ。ライブラリにScamperがあることから、この普通のコントローラージョブがScamperを選ぶ、公開の計測が既に使った、結果に実際の差がある、と述べることはできない。ジョブの変換経路。

この留保は、来歴を記録する意味を弱めない。むしろ機能一覧と実行履歴を分ける理由になる。リポジトリーに含まれる選択肢すべてを、ある観測が使った方法として記載するのは誤りだ。必要なのは、関連する設定と実際に走った経路を対応付けることであり、未使用の能力を実績へ読み替えることではない。

ビルドのダイジェストがあれば、対象のファイルを識別する助けになる。それでも計時、パケット構成、エラー処理が別実装と等価かは、独立した試験を必要とする。結果形式が合う、ファイルが特定できる、計測動作が用途に適するという三つの確認を、同じラベルにまとめるべきではない。

届いた系列には、収集の選別も含まれる

プログラムの違いが関わるのは、成功した結果に付くフィールドだけではない。生成した観測をアップロードまで保存できるかにも、実装上の選択がある。

Starlaの容量制限付きメモリーキューは、新しい結果を受け入れる際に満杯なら最古の項目を先頭から取り除く。送信に失敗した仕事を戻す経路は別で、先頭へ戻したあと、容量を超えた分を末尾から削る。結果の年齢や試行回数による整理もある。「常に最古の結果だけを捨てる」という説明では、経路の違いが消える。キューの順序と再投入。

ハンドラーの既定設定は、10,000件のキューと最大3,600秒の結果年齢を含み、再試行と定期的な整理にも上限を持たせる。これらはソース上の既定値であり、稼働中の設定を確認したものではない。破棄する分岐があることも、実際の損失を発見したことにはならない。既定値と整理処理。

上限には合理的な理由がある。計測へ任意に協力するホストに、送信先が使えない間も無限のメモリーを提供させるべきではない。古い仕事をいつまでも再試行することが、新しい観測を優先するより望ましいとも限らない。研究者側の注意点は、受け取った系列が全試行ではなく、保存と配送に成功した標本かもしれないことである。

空白があれば、宛先が答えなかったのか、仕事が実行されなかったのか、配送が妨げられたのか、ローカルの保存規則が働いたのかを調べる必要がある。安全に示せる省略件数や試行の記録なしに、原因を一つに決められない。逆に、コード上の上限を見つけただけで特定の空白をキュー損失と診断することもできない。

生産者の識別と収集の完全性は関連するが、同じ項目ではない。前者は方法の履歴を示す。後者は読者へ届いた標本の範囲を説明する。実装が分かっても全試行が届いたとは限らず、完全性が不明でも個々の結果が誤っているとは限らない。この二つを保つことが、強すぎる結論を防ぐ。

過去の証拠を残し、用途ごとに確かめる

最初の対応は追加情報であるべきだ。結果と元のフィールドを残したまま、資料がある期間には生産者の対応を付ける。分からない期間は不明と表示する。見慣れた番号から参照実装やStarlaを自動的に割り当てるのは、履歴を調べる代わりに作ることになる。

方法の比較が必要なら、研究の結論に関係する範囲へ試験を絞れる。どのビルド、入力、待機時間、エラー条件、実行環境を比べたかを示し、その試験から何が言えるかを限定する。これは必要な証拠の例であり、既存の試験に欠落があると述べているのでも、本調査が動作差を発見したのでもない。

試験報告と配備の証明も別だ。あるビルドが試験条件を満たしても、過去のホストがそのビルドを使った証明にはならない。導入パッケージの記録があっても、研究に必要な動作が独立に比較されたとは限らない。方法の比較可能性と、観測が試験対象へ属することの両方を、用途に応じて確かめる必要がある。

未知の来歴を理由に、古い結果を隠したり全体を無効と扱ったりしてはいけない。通常の到達性監視には役立つ一方、細かな因果説明には留保が必要というデータもありうる。研究者は使うか捨てるかの二択ではなく、結論の範囲を調整できる。

Starlaの公開コード、登録時の明示的な名前、Atlasの既存バージョン機構は、いずれも評価すべき材料だ。問われるのは別実装の存在ではない。ある分析が前提とした計測器の連続性について、具体的にどの証拠があるかである。互換性を示す値は有用だが、その全体の代わりにはならない。

資料

上記は9月7日のコミットへ固定したStarlaの九つのソースファイル、開発者の4月の紹介、2026年9月14日に取得したAtlasの公式結果バージョン文書に基づく。プローブの導入、登録、実行、有料計測、独立した適合性試験は行っていない。コードの経路と、実際の配備、観測された損失、過去の情報へのアクセスは分けて扱った。