要約

  • IRR Auto-ManagerはROAの作成時にIRR経路オブジェクトを生成または関連付けられる一方、両方を後から独立して削除・保持できる設計になっている。
  • ACSP 2026.9はIRR側にもROAと同等の操作履歴を求めた。二つの履歴がそろっても、共通の操作IDと前後状態がなければ、一つの意図を復元する作業は推測に残る。
  • 記録横断の操作レシートなら、ROAの認可とRPSLの宣言を区別したまま、選択、対応関係、結果、訂正を検証可能にできる。

ARINが解いたのは、目立たないが実務的な問題である。ROAを作る作業とIRR経路オブジェクトを登録する作業が別々なら、同じ起点ASとプレフィックスを二度入力し、二度更新しなければならない。片方を忘れれば、二つの記録は静かにずれていく。IRR Auto-Managerは、ROAを作る流れの中で対応するrouteまたはroute6オブジェクトを作り、関連付ける。

この機能の評価は、利点から始めるべきだ。自動化は重複作業を減らすが、利用者の選択を奪わない。Org ID単位で無効にでき、全体設定が有効でも個々のROA作成時にIRRオブジェクトの生成を断れる。既に一致する非管理オブジェクトがあれば、自動管理オブジェクトで置き換えるか、そのまま残すかを選べる。既存ROAについてはSync Upが不足するオブジェクトを作成し、あるいは存在するオブジェクトを関連付ける。

出口も確保されている。IRRオブジェクトは、リンク状態にかかわらずROAへ影響を与えずに削除できる。ROAを削除する際は、関連する自動管理オブジェクトを一緒に消すか、非管理状態で残すかを選ぶ。一つのROAに複数のプレフィックスが含まれれば、プレフィックスごとにIRRオブジェクトが作られる。関連付けは永続的な一対一拘束ではない。

そもそも二つの記録は同義ではない。ROAは署名された経路起点の認可であり、より具体的な広告をどこまで認めるかを示すmaxLengthを持ち得る。IRR経路オブジェクトは、RPSLでプレフィックスと起点ASを宣言する。Auto-ManagerはmaxLengthを複数のIRRオブジェクトへ機械的に展開せず、プレフィックス項目を使う。これは欠落ではなく、認可と宣言の境界を保つ設計判断である。

APIにもこの区別が表れている。ROA作成時のroaSpec:autoLinkは、各リソースを適切なIRRオブジェクトへ関連付け、必要なら作成するかどうかを制御する。応答のautoLinkedは、その結果を知らせる情報である。他方、IRR REST APIはIRRオブジェクトを独立して操作する。自動化された一つの流れに入っても、データモデルまで一つになったわけではない。

つまり、現行設計には強い擁護が成り立つ。ARINは限定された調整を自動化し、拒否と離脱を認め、二種類の記録の意味を保った。次に問うべきは、こうした選択を説明する証拠が、操作と同じ範囲を覆っているかである。

ROA変更履歴が既に示すもの

ARINの文書によれば、Origin AS/Prefix Pair Change Logは、組織の過去365日間の新規および変更されたROAを表示する。100件を超えればページ分割される。列には時刻、AddedまたはRemovedという操作、Web User、API User、ARIN Systemという発生元、起点AS、プレフィックス、最大長、Changed Byが並ぶ。完全なCSVはチケットで申請でき、ARINは二営業日以内に確認・回答し、その後90日間ダウンロード可能にすると説明している。

これは現状一覧より一段深い証拠である。いつ、どのAS・プレフィックス対が追加または削除され、そのきっかけがウェブ、API、システムのどれだったかを分けられる。文書がいう「変更」は、削除された対と追加された対として表現できる。公開の操作値に別のModifiedがあるかのように書く必要はない。

これに相当する可視のIRR操作履歴は、確認した公開文書では説明されていない。2026年5月11日、Randal KohutekはACSP 2026.9を提出し、IRRオブジェクトにもROAと同等の操作ログを追加するよう求めた。提案の表現は慎重で、IRRシステムには同様のログが「ないように見える」と述べている。ARIN内部にデータベース履歴やセキュリティログがない、と断定したのではない。

ARINは5月19日に、この機能がIRR操作を追跡する顧客に役立つと同意した。提案を将来開発のためのルーティングセキュリティ・ロードマップへ加え、内部の優先順位付けと実装計画へ回し、提案をクローズした。八日で必要性を認め、担当プロセスを明らかにした点は評価できる。ただし、ロードマップへの登録は実装完了でも、リリース日や最終仕様の約束でもない。

同じ列を二組そろえても、同じ意図は証明できない

将来、IRR側に時刻、発生元、利用者、操作を備えた履歴ができれば、可視性の非対称は縮まる。それでも運用者は二つの時系列を眺め、どの行とどの行が同じ選択から生まれたかを判断しなければならない。

ROA作成時、既存の非管理オブジェクトが見つかる場合がある。置き換えることも、触れずに残すこともできる。複数プレフィックスなら、一つのROAから複数オブジェクトが生じる。後日、IRRオブジェクトだけが削除されるかもしれない。ROA削除時には、IRRオブジェクトも消す場合と、非管理として残す場合がある。Sync Upは新規作成と既存オブジェクトの関連付けの両方を行い得る。

時刻の近さは検索の手掛かりであって、因果関係の証明ではない。同じ秒の二行が別々の要求から生まれる可能性もある。時間が離れた二行が、一つの確認作業を含む操作に属する可能性もある。オブジェクトが現在存在しないという事実だけでは、どの削除選択が行われたかは分からない。IRRオブジェクトが残っていても、それが意図的な保持か偶発的な残存かは分からない。

現在二つの値が一致している場合も、系譜が明らかとは限らない。一度独立して削除されたIRRオブジェクトがSync Upで再作成されれば、最終画面は再び整合して見える。状態比較は「今」を示す。操作履歴は「なぜ今そうなっているか」を示す。両方が必要であり、どちらかで代用できない。

既知の障害がなくても、この違いは実務に効く。ROAはRPKI起点検証の署名済み入力になり得る。IRRデータはルーティングポリシー・フィルターの生成や確認に使われ得る。どちらも、実際にBGPで何が広告され、ルーターが何を受け入れたかを証明しない。それでも両者が違うとき、技術者は明示的な拒否、既存オブジェクトの維持、独立削除、一対多対応、部分失敗、後の訂正を区別しなければならない。

必要なのは、全組織の活動を公開する巨大な監視ログではない。認可された組織が利用でき、公開されたスキーマで解釈できる、範囲を絞った操作レシートである。

データベースではなく操作に付くレシート

レシートの起点は、個人情報を含まない不透明な操作IDと時刻でよい。ARIN Online、RPKI API、IRR API、Sync Up、ARIN Systemのどこから始まったかを示し、個人名を無条件に公開せず、行為者の区分と認可組織を記録する。意図も構造化する。ROAの作成・変更・削除、IRRオブジェクトの作成・関連付け、非管理オブジェクトの置換、IRRだけの削除、非管理としての保持、再同期などである。

続いて前後状態を結ぶ。ROA側ではハンドル、起点AS、プレフィックス、maxLength。IRR側ではrouteまたはroute6キー、プレフィックス、起点、管理状態、リンク状態。一つのROAが複数プレフィックスを含むなら、対応数を示す。既存オブジェクトが再利用、置換、無変更のどれだったかも、最終一覧から推測させず結果として残す。

削除と保持は別の選択欄にすべきだ。「ROAと関連オブジェクトを削除する」と「ROAを削除し、オブジェクトを非管理で残す」は同じ結果ではない。不在だけを証拠にしてはならない。片側だけ成功した場合は、全体を単純な成功または失敗と表示せず、各側の結果と期待終状態に到達したかを示す。訂正は古いレシートを黙って上書きせず、どれを置き換えたかを指す。

全フィールドを世界へ公開する理由はない。API鍵、永続的な個人名、他組織の履歴は公開透明性の対象ではない。ARINは内部のセキュリティ記録に詳細を保ち、認可された資源保有者へ構造化レシートを渡し、外部にはスキーマ、保持期間、出力規則、版の変更を示せばよい。検証可能性と無制限公開は別物である。

Auto-Managerには、制度設計として既に良い抑制がある。調整するが統合しない。自動化するが拒否と出口を残す。ACSP 2026.9が示す次の一歩は、IRR側に同じ列を加えるだけではない。二つの変化が一つの操作だったのか、独立した選択だったのかを、時刻の推測ではなく共通IDで説明できるようにすることである。

出典