要約

  • AFRINICが公開するRoutinator 0.14.2は、シリアル23421で有効な入力VRP 39,059件、重複8,212件、最終VRP 30,847件を報告した。
  • 次のシリアル23422では入力が39,058件、重複が8,211件となり、最終件数は30,847件のままだった。差分はIPv4だけに現れた。
  • Routinatorの定義では、重複とは同一認可を含むROAから生じるVRPの重なりである。どの出現を重複側に数えるかは処理順で変わり得る。
  • 二つの応答は、変化したタプル、ROA、保有者、BGP経路、ルーター判断を特定しない。集計を運用上の結論にするには、ソースオブジェクトから最終集合までの系譜と、別系統のルーター証拠が要る。

19分間で動いた二つの項と、動かなかった一つの項

2026年8月29日06時37分53秒UTCに完了した検証シリアル23421では、AFRINIC信頼アンカーに39,059件の「存在し有効なVRP」が記録されていた。そのうち重複は8,212件、最終集合への寄与は30,847件だった。危険と判定されたVRPも、ローカル例外で除外されたVRPもゼロである。したがって、この時点の集計は 39,059 - 8,212 = 30,847 となる。

06時57分08秒UTCに次の検証が完了し、シリアルは23422へ進んだ。入力は39,058件、重複は8,211件、最終件数は30,847件である。引かれる前と引く数が同時に1件ずつ減り、答えは変わらなかった。

内訳も境界をはっきりさせる。IPv4は入力37,804件から37,803件、重複8,136件から8,135件へ減ったが、最終件数は29,668件で固定された。IPv6は入力1,255件、重複76件、最終1,179件のすべてが同じだった。有効な公開点は両方とも1,408、拒否された公開点はゼロである。

一方、ROAの数にも1件差がある。前の応答は有効12,171件、無効ゼロ、後の応答は有効12,170件、無効1件を示す。数字だけを眺めれば、一つのROAが無効化され、それが重複1件の減少を生んだように見える。しかし、応答には両者を結ぶオブジェクトIDがない。時刻が近く、差が同じであることは、因果関係を公開記録に追加しない。

さらに、最終「件数」が同じことと、最終「集合」が同一であることも違う。1タプルが消え、別の1タプルが加われば、件数は30,847のままでいられる。今回の算術は冗長な出現が一つ減った説明と整合するが、タプル単位の差分なしに集合の同一性までは証明できない。

ROAからルートまでを一つの名詞で呼ばない

この差分を正しく読むには、少なくとも四つの記録を分ける必要がある。

ROAはRPKI内の署名済みオブジェクトである。一つの起点ASと一つ以上のプレフィックス認可を含み、それぞれに最大長を持たせることができる。一つのROAから複数のVRPが生じ得るし、ROAには証明書チェーンと公開場所がある。

VRPは起点検証用に導かれたタプルで、IPアドレス、プレフィックス長、最大長、起点AS番号から成る。ROAファイルそのものではない。同じ認可が別オブジェクトまたは別の公開経路を通れば、同じVRPが複数回現れることがある。

最終集合は、その多重性をそのままルーターへ渡さない。Routinatorは重複、ローカルフィルター対象、設定によっては危険なVRPを除き、固有の出力を作る。同じ認可が二回届いても、起点検証に同じ命令を二つ並べる必要はない。

BGPルートはさらに別である。受信した更新からプレフィックスとAS_PATH末尾の起点を取り出し、VRPと比較する。少なくとも一つが一致すれば Valid、カバーするVRPはあるが一致しなければ Invalid、カバーするものがなければ NotFound となる。重複VRPの総数だけから、特定ルートの状態は一つも導けない。

役割も同じように分かれる。資源保有者は認可に署名し、リポジトリはオブジェクトを配布し、検証器は自らの構成と処理順で検証・帰属させ、ネットワーク運用者はキャッシュ選択とルーティング方針を決める。AFRINICのドメインで検証器が公開されているからといって、配下の全ROAの意図や、接続する全ルーターの判断までAFRINICが決めたことにはならない。

「重複」は関係を示すが、過失を示さない

表計算の重複行なら、削除対象に見える。暗号署名された分散公開系では、同じ認可が複数現れる理由は一つではない。重なるROA、再発行、移行、冗長な公開経路、あるいは単純な誤りがあり得る。集計値は原因欄を持っていない。

Routinatorの文書は、より直接的な注意を記している。同じVRPが複数の信頼アンカーやリポジトリに現れた場合、どの出現を重複と数えるかは処理順に依存する。その順番は検証ごとに変わり得るため、数が予期せず動くこともある。

これは最終出力が無意味だという警告ではない。アンカー別の重複統計には、ソース側の多重性だけでなく、検証器側の帰属規則も含まれるという警告である。そのため、五つのRIRの列をそのまま品質ランキングにすることもできない。大きな数字は管理不良を証明せず、ゼロは完全性を保証しない。比較には同一の構成、時点、ソースグラフ、帰属規則が必要だ。

今回、最終件数が動かなかったことは、話を拡大しないために役立つ。入力側の多重性が1件減っても、最終の固有件数は減らなかった。だから「ルートが失われた」「セキュリティが改善した」「AFRINICが不正な認可を修正した」という見出しは、証拠の層を飛び越える。

詳細な状態APIにも、変化の履歴は自動では入らない

観測したエンドポイントは軽いダッシュボード以上の情報を持つ。Routinatorの文書は /api/v1/status を、信頼アンカー、リポジトリ、RRDP・rsync接続、RTR・HTTPセッションを含む包括的なJSON情報源として説明する。バージョン、シリアル、完了時刻があるため、同じ画面を後から曖昧に引用する必要はない。

ただし、状態フィールドが包括的であることと、差分の原因が包括的であることは別である。二つの応答には、23421から23422までにどのROAハッシュが変わったか、どのタプルが二重から単一になったか、帰属だけが動いたのか、あるいは無効ROAが同じ事象なのかを示す公開の結合表がない。

RTRセッションも運用上の結論を代行しない。キャッシュが30,847件を提供可能だったことと、特定ルーターがそのシリアルを受け取り、特定のBGPルートに方針を適用したことは別の出来事である。後者を語るには、クライアント受領、キャッシュシリアル、ルート観測、方針結果を接続しなければならない。

公開メトリクスが正確になるほど、説明責任は大きな報告書ではなく結合の保存へ移る。内部ログを全面公開する必要はない。集計からオブジェクトへ戻れる最小限の参照を残せばよい。

必要なのは「変わった1件」の系譜受領証

受領証の先頭は検証イベントを固定する。ソフトウェアのバージョンと構成指紋、シリアル、開始・完了時刻、信頼アンカー集合、リポジトリ集合の指紋が必要である。これで数字が測定器から切り離されなくなる。

次に、変化した可能性のある固有VRPについて、起点ASN、プレフィックス、最大長を記録する。ソースROAのハッシュ、公開URI、証明書チェーン参照を結び、各実行での出現回数と重複帰属を残す。

原因は証拠付きの状態値にする。ソース撤回を観測、再発行、検証失敗、リポジトリ到達不能、処理順による帰属変更 は、それぞれを支える記録がある場合だけ使う。なければ 未解決 とし、後続の訂正で更新する。未解決は欠陥ではなく、推測を権限に変えないための状態である。

その後に最終集合の差分を置く。総数ではなく、どのタプルが入ったか、出たか、残ったかをキャッシュシリアルへ結ぶ。ルーティング効果はさらに別欄にし、ルーター受領や実ルートの証拠があるときだけ記す。

公開版に顧客名や内部トポロジーは要らない。公開目的のVRPタプル、暗号ハッシュ、出現回数、状態遷移、訂正履歴で十分である。詳細は保護された運用記録に置きながら、第三者が集計の意味を再現できる。

静かな数字を、静かなまま検証可能にする

二つのスナップショットは、影響を受けたネットワーク、保有者、BGPアナウンスを一つも特定しない。ルーターが違う判断をしたとも、AFRINICが何かを修正したとも示さない。示すのは、入力側の変化が最終件数の変化にはならなかったという限定的な事実である。

この限定は価値を減らさない。むしろ、レジストリが証拠の保管者として力を持つ地点を示す。意図や過失を裁定せず、署名オブジェクト、検証、固有出力、ルーター判断の境界を維持することだ。

30,847という数だけを保存すれば、後から残るのは印象である。どのオブジェクトがその数を作り、どこで多重性が除かれ、どこから下流の判断が始まるのかを保存すれば、同じ数が監査可能な記録になる。

出典