要約

  • AFRINICのResource Certificationページは「RIPE NCC Validator」という名称でリンクを示すが、到達先のタイトルと説明はRoutinatorであり、AFRINICの別の推奨ページも同じサービスをRoutinatorと呼んでいる。
  • 問題はリンク切れではなく、ソフトウェアの来歴がリンクの継続に隠れたことだ。表示名、実装、保守者、サービス運用者、サポート状態、検証版、用途、移行履歴を結ぶ版管理台帳が必要である。

2026年9月8日、AFRINICのResource Certification Programを開くと、Validators欄に「RIPE NCC Validator」がある。リンクは https://rpki-validator.ripe.net/ui/ へ向かい、HTTP応答は正常だ。しかし受け取った文書のタイトルは「Routinator」、説明文もRoutinatorのユーザーインターフェースだと明記する。

障害ではない。むしろ移行が成功した痕跡である。

RIPE NCCは2021年6月15日、自らのRPKI Validatorのサポートを7月1日に終えると発表した。旧ソフトを動かし続ける運用者には代替実装への移行を強く勧め、更新が止まった後の継続利用はセキュリティ事故につながり得ると説明した。同年9月10日の記録では、旧ホスト名で提供していた公開サービスを16日にRoutinatorへ切り替える計画まで示している。

残したのはサービスの住所であって、旧製品ではなかった。

同じ組織の二つの案内

AFRINICには、すでに現在の実装名を示すページがある。validator.afrinic.net は「RPKI Relying Party Software」と題し、ローカル提供としてAFRINIC RcynicとAFRINIC Routinatorを挙げる。他の選択肢では、同じRIPEのURLを「RIPE NCC: Routinator」と表示する。

このページ、リンク先のタイトル、RIPE NCCの移行記録は一致する。主ページの表記だけが旧製品名を保存している。

主ページはRPKI.net rcynic Validation ToolとRPSTIRも並べるが、版、保守者、サポート状態、確認日を表示しない。ここから両者が危険、放棄済み、またはAFRINICの本番環境で稼働中だと推論してはならない。今回の資料が示すのは、読者がその判断に必要な情報をページ上で得られないという事実だけだ。

反論は明快で、しかもかなり強い。リンクをたどる利用者は古い配布物ではなく、現在のRoutinator画面に着く。別ページには正しい名称もある。熟練した運用者なら、RIRの案内ページを本番ソフトの配布元とはみなさず、保守中のプロジェクト、パッケージ、リリースノートを確認する。実害のない古いラベルに過ぎない、という見方は可能だ。

それでもラベルは運用資料へ流れ込む。研修資料、調達仕様、監査調書、障害対応手順に「RIPE NCC Validator」と転記されれば、実際の依存先と一致しない。RIPE NCC ValidatorとRoutinatorは、同じURLを共有した時期があっても、コード系列、保守主体、バージョン、既知の挙動が異なる。リンクが成功するほど、その差を調べるきっかけは減る。

読み手の実装も証拠の一部である

RFC 8897はRPKIのrelying-partyソフトを、リポジトリからInternet Number Resourceデータを取得し検証する仕組みと定義する。検証済み情報はBGP判断を支える。同RFCは十三の技術文書に分散した要件を、取得とキャッシュ、証明書と失効リストの処理、署名オブジェクトの処理、検証済みデータの配布という四群にまとめる。

つまり製品名は画面のブランドではない。どの実装がデータを読み、どの既定値と修正履歴を持ち、誰が更新責任を負うかを特定する入口だ。名称だけで結果の正しさは保証できないが、名称がなければ結果の再現に必要な変数が一つ失われる。

NLnet Labsの安定版文書は現在の対象をさらに限定する。Routinator 0.15.2は /ui にHTTP画面を置き、Prefix Check、直近の検証処理、HTTPおよびRPKI-to-Router接続の指標を提供する。RIPEの現行ページが掲げるタイトル、説明、パスはこの記述に合致する。

一方、公開画面と本番依存先は同じではない。RIPE NCCは移行時に、公開インスタンスはbest-effortであり、稼働保証のある本番サービスとして使うべきではないと記した。正しい台帳は、製品、コード保守者、サービス運用者、想定用途を別々に記録しなければならない。

推奨順位ではなく来歴表

AFRINICが全てのRP実装を認証する必要はない。特定製品を地域標準にする必要もない。必要なのは、ページが名前を掲げた時点で作っている対応関係を、第三者が確認できる形にすることだ。

各項目に次の列を持つ版管理されたガイダンス台帳で足りる。

  • 表示ラベルと正規の製品名
  • 実装プロジェクトと現在のコード保守者
  • 公開サービスの運用者、要求URL、最終URL
  • ライフサイクル状態、サポート対象系列、最終確認日
  • AFRINICが確認した機能と限定された結果
  • デモ、best-effort照会、評価、本番のどの用途か
  • 旧製品、移行先、公式の移行・セキュリティ通知
  • 修正、退役、削除、アーカイブの判断日と理由

過去版は残すべきだ。主ページの文字を今すぐRoutinatorへ直すだけなら、現在の誤認は減る。しかしAFRINICが2021年の変更をいつ公開資料へ反映したかは分からなくなる。旧行を閉じ、新行を発効させれば、編集が変更記録になる。

検査結果の粒度も揃えてはならない。HTTP 200は到達性、タイトルはアプリ識別、版試験は特定機能の確認、本番適格性は別の判断である。一つの「確認済み」で全てを代用すると、同じ曖昧さが再発する。

ここから先は言えない

AFRINICが退役済みのRIPE NCC Validatorを配布または運用している証拠はない。リンクは壊れておらず、現行の到達先はRoutinatorだ。誤ったソフトを導入した運用者、誤判定されたROAやVRP、影響を受けた経路、セキュリティ事故も確認されていない。

表示上の確認日がないことは、内部確認がなかった証明にもならない。担当者が最近全リンクを点検した可能性はある。問題はその作業の有無ではなく、外部から検証できる受領記録がないことだ。

結論は限定できる。RIPE NCCは旧製品の保守終了を発表し、同じ住所の公開サービスをRoutinatorへ移し、その履歴を残した。AFRINICは一方のページで新しい実装名を示し、もう一方で旧名を残す。資源認証の主張を検証可能にする制度なら、それを読むソフトの名前も推測に委ねるべきではない。

情報源