要約

  • APNICの2026年第3四半期ロードマップは、個別の番号資源に関する現在・過去のVRP情報をRExに表示するとしている。一方、公開カードは項目、収集間隔、検証実装、保存範囲をまだ定義していない。
  • 有効な署名ROA、そこから導出されたVRP、あるBGP経路のValid／Invalid／NotFound、そして事業者のローカル方針は別々の証拠である。
  • 各期間には、照会資源と包含関係、prefix・maxLength・origin ASN、観測時刻、データ版、導出手法、取得の完全性、「特定ネットワークの判断や転送結果を示さない」という境界を添えるべきだ。

タイムラインには、書かれていない動詞がある。昨日まで緑、今日から赤なら、見る側は「何かが変更され、世界がその変更を受け取り、ルーターが動作を変えた」と読む。実際に分かるのが二つの時点の観測だけでも、画面は因果の物語を完成させてしまう。

APNICのProduct Roadmapにある新項目は、この問題を公開前に解ける。名称は「Display RPKI VRP information for individual INR in REx」。担当はInformation、対象製品はRExとRPKI、目標時期は2026年第3四半期である。狙いは、RPKI状態情報をコミュニティが入手しやすくし、個別の番号資源に歴史的な文脈を与えることだ。

ロードマップの短いカードに完成仕様を求めるべきではない。取得時点で機械可読データのchangelogは空欄であり、表示項目、観測頻度、利用するバリデータ、トラストアンカー、元オブジェクトの識別子、比較方法、保存年限は書かれていなかった。これはAPNIC内部に設計がない証拠ではない。公衆向けの約束が、どの種類の履歴を意味するかはまだ公開されていない、というだけだ。

しかし、その意味は初版から必要になる。RExの画面は、やがて障害調査の資料、アビューズ対応の添付、資源取引の確認資料、研究用の時系列として使われる。便利な参照画面は、意図したかどうかにかかわらず証拠になる。

同じプレフィックスを持つ四つの記録

RPKIでは同じprefixとASNが複数の段階に現れる。そのため一つの「状態」にまとめたくなるが、それぞれの主語は違う。

ROAは署名オブジェクトである。APNICの説明では、あるASが特定のIPプレフィックスをoriginとして広告する権限を示し、AS番号、prefix、許容する最大prefix長を含む。RFC 9582は、経路広告の検証に使う前に、relying partyが署名オブジェクトとROA固有の検査を済ませるよう求める。必要な検査に失敗したROAは全体が無効になる。

VRPはそこから得られる出力だ。署名ファイルの別名ではない。APNICの技術解説は、relying-partyソフトウェアがRPKIオブジェクトを取得し、暗号的に検証して、ASN、ROA prefix、prefix長、maxLengthの組を抽出する流れを示す。このValidated ROA Payloadは、ある検証過程を通った派生物である。別の検証地点が同時刻に同じ集合を持ったことまでは証明しない。

Valid、Invalid、NotFoundはBGP経路に対する結果である。RFC 6811では、経路prefixがVRPに包含されるか、経路長がmaxLength以内か、origin ASNが一致するかを調べる。一つでも一致すればValid、包含するVRPはあるが一致がなければInvalid、包含するVRPがなければNotFoundだ。経路prefixとoriginがないまま「資源はValid」と言えば、アルゴリズムに必要な主語が消える。

最後に動作を決めるのは事業者だ。RFC 7115は、検証状態を経路制御でどう使うかはローカル方針で定めるとしている。Invalidを破棄する場合も、まず記録だけする場合も、別の属性や例外と組み合わせる場合もある。検証結果そのものに世界共通の命令は入っていない。BGPの制御面から、パケットが実際にたどった経路も証明できない。

したがって、色一つに四つの権限を持たせてはならない。資源保有者は許可を署名できる。relying partyはオブジェクトを検証しVRPを導出できる。観測系やルーターは特定の経路を集合と比較できる。運用者はローカル方針を決める。RExが責任を持って言えるのは、自身の方法が何を観測したかである。

空白は原因ではない

VRPが表示されている期間より、何もない期間の方が誤解を生みやすい。空白を見ると、利用者は保有者がROAを取り下げたと考えがちだ。

実際には、派生VRPが見えない理由は複数ある。意図的な撤回のほか、証明書やオブジェクトの失効、署名・manifest検査の失敗、publication pointからの取得遅延、cache reset、過去データの欠落、再構成手法の変更、あるいは照会した資源と包含VRPの関係を画面が扱っていない可能性がある。追加の根拠がなければ、RExはどれか一つを原因として選べない。

安全な文は「このREx観測では適用可能なVRPを導出しなかった」だ。「保有者はこのprefixの許可を失わせた」ではない。前者はデータ集合と時刻を述べる。後者は行為者、意図、原因を推定する。

狭い表現は調査を妨げない。snapshot ID、手法、直前のタプルがあれば、保有者や運用者はローカル記録と比較できる。曖昧な空白だけなら、調査は画面が生んだ含意をほどくところから始まってしまう。

「現在」はキャッシュごとに違う

RFC 8210は、ルーターにデータを渡すRPKI cacheを、公開された世界のRPKIデータを定期的に取得してまとめたコピーとして扱う。serial numberはcacheの論理的な版を表す。refresh、retry、expireの各intervalは、次の照会、失敗後の再試行、古いデータの利用期限を決める。増分履歴を渡せないとき、cacheはresetと全件再取得を要求できる。

さらに、分散したcacheは厳密には同期できないとRFCは認める。RExがある時刻に見た集合と、シンガポールの事業者が同じ秒に持つ集合が一致しないことはあり得る。短い差だけで、どちらかの失敗や不正を意味しない。観測場所と時刻が結果の構成要素だという意味である。

APNIC Blogに掲載されたrelying-party同期の研究は、publication、intermediate cache、enforcementの三層を分ける。不完全または古い公開データが誤った検証結果につながり得ると指摘し、自分たちの測定では何を「十分に新しい」とするかを定義する。形容詞を測定条件に変える、良い手順だ。

RExの履歴にも、期間のfrom/toとは別にobserved-at、timezone、dataset releaseが必要である。バリデータ、関連設定、過去データの再構成、比較規則を変えた場合はmethod boundaryを残すべきだ。測定器の変化を、測られた許可の変化に見せないためである。

観測地点を明記しても、内部サーバーの配置や資格情報を公開する必要はない。「このRExデータは、記載した方法でこの時刻に得られ、取得の完全性はこの範囲だった」という公的な主語があればよい。

個別資源の検索にも包含関係がある

利用者が/24を入力したとき、何を期待するかは一つではない。prefixが完全一致するVRPだけか。/24までをmaxLengthで許す上位の/16も含むのか。その範囲にあるmore-specificな許可も見るのか。どれも有用だが、答える問いが異なる。

RFC 6811の判定はprefixの包含と長さに依存し、maxLengthがmore-specificの一致範囲を決める。色だけを出してexactかcoveringかを隠せば、判定理由そのものが失われる。

画面はquery relationshipを先に示すべきだ。exact、covering、more-specific、または定義済みのaggregate viewである。複数VRPが適用できるなら集合を残す。履歴で集合が変わったなら、どのタプルが追加、削除、変更されたかを示す。同じ件数でもorigin ASNの交代、maxLengthの縮小、重複許可の整理があり得るからだ。

小さな来歴欄で十分である

必要なのは第二の巨大ダッシュボードではない。現在値と各履歴区間に、次の十項目を添えればよい。

  1. 入力された番号資源と、表示prefixとのexact／covering／more-specific／aggregateの関係。
  2. 表示対象が署名ROA、派生VRP、または明示された経路の検証結果のどれか。
  3. prefix、maxLength、origin ASNからなる完全なVRPタプル。
  4. 期間の開始・終了と、timezone付きの実観測時刻。開いた期間は最新観測時点でのみcurrentとする。
  5. 後から参照できるREx datasetまたはsnapshotの識別子。
  6. 比較に影響するときの導出手法、バリデータ、バージョン。
  7. 対象trust anchorと、取得が完全だったかを示す限定的な注記。
  8. method changeまたはarchive gapの印。データ欠落をVRP不在に見せない。
  9. 適用中の定義と次の観測へのリンク。
  10. 特定事業者のcache、ローカル方針、選択経路、実パケット経路は示さないという明記。

この欄はprivate key、会員資格情報、未公表インシデント、内部収集トポロジーを求めない。公開された主張を再現可能にするだけだ。

RExが証明できる範囲

この設計なら、RExは強く限定された事実を述べられる。識別可能なsnapshotで、記載の手法がこのVRP集合を導出した。タプルは複数回の観測に残った。あるタプルが消え、別のタプルが現れた。収集欠落や手法変更により直接比較できない期間がある。第三者はsnapshotから件数を再現できる。

一方、最初の空白だけで保有者がその時刻に意図的に撤回したとは証明できない。全relying partyが同時に更新したとも言えない。経路prefixとoriginなしに特定経路をInvalidと判定できない。事業者がその経路を破棄したこと、ハイジャック、停止、トラフィック変化が起きたことも分からない。

APNICのROA・ROV測定記事は、観測地点を失う危険を具体的に示す。上流ISPがInvalidを落とせば、その下に単一接続するネットワークは、自らROVを実施しているように見える場合がある。到達できないという観測は本物でも、行為者の推定が違う。RExも同じ慎重さを持つべきだ。

良い履歴はincident reportの代わりではなく、安定した一人の証人になる。調査者はREx snapshotをBGP観測、ローカルバリデータ、ルーターログ、保有者の説明、データ面測定と結合する。研究者は色から原因を作らず、観測系列として扱う。会員は再現可能な行を根拠に異議を示せる。

APNICが約束したのはアクセスと歴史的文脈だ。インターネット全体の最終判決ではない。だからこそ、来歴欄は注意書きではなく、この機能の中心になる。

情報源