要約

  • APNICは「Route management alignment」を2026年第3四半期のRegistry項目とし、移転、割り当て解除、システム変更後に、経路管理、資源保有、Whois、RPKIの整合を自動化するとしている。
  • それぞれは同じ事実ではない。保有記録は誰が管理できるかを示し、IRRのroute objectは方針や意図を表し、ROAはorigin ASを許可し、BGPは実際に観測された広告を伝える。
  • 公開項目は、衝突時の優先順位、トランザクションの境界、部分成功の扱い、通知、ロールバック証跡を説明していない。公開説明の不足は、APNIC内部に設計がないことの証明ではない。
  • 記録の種類ごとに権威を定める優先順位表と、変更前後・理由・失敗段階・最後の安全な状態を残すタスク受領票があれば、意味の異なる記録を無理に同一化せずに手作業を減らせる。

pendingの先にある判断

経路の変更を依頼し、画面にpendingと表示される。しばらくしてalignedに変わる。利用者に見えるのがそれだけなら、処理が終わったことは分かっても、何が起きたかは分からない。Whoisだけが更新されたのか、ROAも発行されたのか。外部の検証キャッシュは新しい状態を見たのか。別の経路で加えられた変更は採用されたのか、上書きされたのか。

APNICの製品ロードマップにある「Route management alignment」は、まさにこの空白を扱う計画である。Registryチームの2026年Q3項目で、製品欄にはARMS、RPKI、Whoisが並ぶ。概要は、経路管理と資源保有、Whois、RPKIの間を自動的に整合すると明記する。移転、割り当て解除、システム変更後の手作業を減らし、誤りを避けることが狙いだ。

これは歓迎すべき仕事である。異なる画面に同じプレフィックスやAS番号を繰り返し入力することに、運用上の価値はない。とりわけ移転時には、手順が多いほど順序の誤りが起きやすい。

しかし、整合とは必ずしも「値を同じにする」ことではない。異なる記録が別の問いに答えている場合、差異は情報である。それを解消するソフトウェアは、どの状態を残し、どの状態を廃止し、どの差異を人に返すかを決める。その判断は製品内部の都合にとどまらず、誰がプレフィックスについて発言できるかを左右する。

取得したロードマップの構造化項目には、年、四半期、担当、製品、概要、提案内容がある。changelogは空欄である。優先順位、複数システムをまたぐトランザクションの終端、部分障害、通知、巻き戻し、NIRや外部IRRの扱いは書かれていない。これだけでAPNICに内部設計がないとは言えない。言えるのは、外部から検証できる約束にまだ含まれていない、ということだ。

四つの記録は四つの質問に答える

資源保有の記録は、レジストリ上の権限を定める。どの組織またはアカウントがアドレス資源やASNを保有し、関連サービスを管理できるかを示す。移転によってこの権限は変わる。ただし、新しい保有者が今日どのASから全プレフィックスを広告すべきかまでは自動的に決めない。

IRRのroute objectは、公開された経路方針を扱う。APNICはIRRを、ネットワーク運用者が経路方針や広告を掲載し、他者がフィルターやルーター設定に利用する分散データベース群と説明している。RFC 2725では、route objectの作成にアドレスプレフィックスとorigin AS双方の権限確認が必要になる。また、マルチホームにより同じプレフィックスに複数のorigin ASが存在し得ること、より具体的なプレフィックスが重なること、プロバイダー変更やリナンバリングの猶予期間があることも想定している。

つまり、複数のoriginがあるからといって直ちに矛盾ではない。待機系の経路や移行中の方針かもしれない。単一の値を正解とする自動処理は、冗長性を誤って削除し得る。

RPKIのROAは、さらに限定された問いに答える。RFC 9582では、アドレス空間の保有者が、特定のプレフィックスを広告するoriginとして一つのASを許可する署名済みオブジェクトである。複数のASを許可するなら複数のROAが必要になる。ROAは許可を示すが、いま経路が存在すること、到達可能であること、特定ルーターが採用することを保証しない。

BGPは観測された経路を伝える。RFC 6483は、受信したプレフィックスとorigin ASを有効なROAと照合し、Valid、Invalid、Unknownを導く手順を示す。その結果を選路にどう用いるかは、各ネットワークのローカルポリシーに残される。レジストリが許可を発行しても、世界中のルーターを直接制御するわけではない。

時間も揃わない。同RFCは、RPKIオブジェクトと経路の伝播時間が異なることを指摘する。新しいROAが公開されても全キャッシュが同時に受け取るわけではない。BGP広告が先に観測されても、恒久的な無許可を意味しない。短い差異は安全な切り替えの途中である可能性がある。

保有、route object、ROA、BGPは、権限、方針、許可、挙動の証拠である。互いに関係するが、複製ではない。

2017年の設計は衝突を消さずに見せた

APNICの2017年版Route Management Guideには、現在の計画を考える手掛かりがある。古い文書なので、2026年の機能仕様として読むべきではない。価値があるのは、MyAPNIC内の管理状態とWhois上の公開オブジェクトを、当時すでに分けて扱っていた点だ。

ガイドでは、MyAPNICの「route」はWhoisに実際のroute objectを作るためのテンプレートである。両者は別々に存在できる。MyAPNIC側にrouteがあってもWhois objectがない場合も、その逆もある。Whois objectがRoute Management以外の経路で変更されても、テンプレートは黙って追随しない。画面はconflictを示し、利用者は外部変更を受け入れるか、Whois objectをテンプレートの状態へ戻すかを選ぶ。

この仕組みは差異を障害ではなく判断材料として保存した。別の正当なmaintainerが緊急修正した可能性も、古い情報が残った可能性もある。どちらかを自動的に消す前に、「別経路で変更があった」という事実が見える。

同じガイドは、複数オブジェクトの同期にpending状態があること、権限を持つ利用者がオプションで一致するROAを作成できることも説明する。管理対象のサブルートを無効化し、ROAも有効だった場合には、そのROAを同時に削除する例もある。単一画面の裏側に、別々の状態、権限、非同期処理、任意の結合があった。

新しい計画がこの仕組みをそのまま使うとは限らない。ただし、古い設計が残した問いは有効である。外部から来た変更を採用するのか、管理された意図を優先するのか。自動化するなら、その選択の理由を古い画面以上に明確にする必要がある。

transactionally where possibleの外側

APNICが2024年に発表したRegistry APIは、現在に近い実行モデルを示す。委任情報を取得し、Whois、逆引きDNS、ROA、route objectを管理できる。BGP広告を追加する際に、ROAとroute objectを自動作成する例も挙げられている。

重要なのは限定表現だ。抽象的な経路管理や逆引きDNSでは複数変更を一つのbatchとして提出でき、そのbatchは「transactionally where possible」に効力を持つ。更新は非同期のtask objectで管理され、依頼後にリンクを受け取り、状態を照会し、完了時に結果の詳細を見る。

可能な範囲でのトランザクションは、世界規模の原子的変更を意味しない。同じデータベース内の書き込みは一緒にcommitできるかもしれない。だがRPKI repositoryへの公開、独立validatorの取得、他RIRでの登録、外部IRRの変更、下流ネットワークのフィルター更新は、それぞれ異なる管理域と時計を持つ。

そのため、新しい整合機能には「可能でない範囲」を示す責任がある。Whois更新だけが成功し、予定されたROA作成が失敗したなら、task全体をFailedとするだけでは運用できない。再送時に成功済み処理を重複させない条件、最後の安全な状態、補償処理、隔離された対象を示す必要がある。

これは現行APIの障害を確認した主張ではない。2024年の説明が、batch、限定的トランザクション、非同期task、結果という公開概念をすでに採用していることが重要だ。整合機能の受領票も、その延長で説明できる。

移転では権限の変更と経路の変更が分かれる

APNICの現行Transfer Conditionsは、外向きinter-RIR transferで、対象資源に関連するsub-assignment、route object、domain objectがAPNIC Whois Databaseから削除されると定める。完了後、移転元はIPアドレスとASNへの権利を失い、資源は受取人に登録される。

引用した条項が述べるのはWhois関連オブジェクトであり、ROAの処理は記載されていない。そこからROAも必ず削除されると推定してはならない。この沈黙は、むしろ新機能が順序を説明すべき理由になる。

保有変更は、誰が管理できるかを変える。移転元Whoisの削除は、元レジストリの公開面を整理する。受取人が選ぶorigin ASと、それを許可するROAは別の意思決定である。実際の切り替えは、公開、キャッシュ、フィルター、BGPの時間にも依存する。

同じorigin ASを継続する移転なら、保有者が変わっても経路意図は同じかもしれない。新ASへ移るなら、到達性を守るため新しい許可を先に準備する場合がある。別RIRへの移転では、移転元の削除と移転先の可視化が同時でない場合も考えられる。いずれも設計を試す仮説であり、APNICで実測した事故ではない。

「まず全て削除」は不要なInvalidやNotFoundの時間を作り得る。「古い状態を維持」は失効した権限を長引かせる。「観測中のBGPをROAへコピー」は挙動を許可に変えてしまう。安全な順序は、移転の種類と明示された意図によって変わる。

自動処理が区別すべき三つの不一致

一つ目は正当な複数originである。IRRにもRPKIにも複数originを表現する方法がある。要素数が違うだけで同期エラーにしてはいけない。権限と範囲を確認し、意図された冗長性を保存する必要がある。

二つ目は伝播中の時間差だ。内部データがcommitted、公開面にpublished、外部からobservedとなるまで、状態は段階的に進む。どの段階も同じsyncedではない。待機中の差異を永続矛盾と誤認すると、不要な再実行や取り消しが起きる。

三つ目は別の正当な経路からの変更である。maintainerがWhoisを直接修正したとき、その変更はテンプレートより新しい意思かもしれない。常にテンプレートを勝たせれば緊急修正を消す。常に外部変更を取り込めば管理計画が意味を失う。誰がどの権限で変更し、ROAにも影響するのかを判断しなければならない。

ロードマップは割り当て解除も対象にするが、公開項目に詳細はない。権限終了が撤回を必要とする場合でも、通知、猶予、異議申立て、NIR管理資源の扱いは一語から決められない。外部IRRのオブジェクトもAPNICが直接commitできる対象ではない。

source of truthではなくauthority by question

一つのsource of truthを選べば設計が簡単になるように見える。しかし、ここで必要なのは問いごとのauthorityである。保有記録は行為者の資格に関する権威。認証された依頼は運用意図の証拠。IRRは公開方針。ROAはorigin許可。BGPは観測。いずれか一つを万能にすると、別の意味を誤って生成する。

APNICが公開すべき優先順位表は大きくなくてよい。移転、割り当て解除、Whois直接編集、経路テンプレート変更、ROA変更、システム移行を行に置く。列には、開始できる役割、前提、変更対象、許容される差異、自動処理、レビュー条件、異議申立て期間を置く。

トランザクション列も必要だ。どの書き込みが一緒にcommitされ、どれが後から公開され、どこから他組織に依存するのか。部分完了時に何を隔離し、誰へ通知し、いつ安全に再試行できるのか。alignedの定義を値の一致から、ルールに沿った状態遷移へ変える。

特に、旧権限の終了と新しい経路意図の作成を分離すべきだ。移転により元アカウントの変更権限を止めても、受取人のorigin ASをAPNICが推測する理由にはならない。BGP観測は警告を起こせても、ROA作成命令にはならない。

巻き戻しても消えない受領票

重要な整合taskは、version付きの受領票を返すべきである。event ID、task ID、trigger、時刻、依頼者の権限確認に使った保有snapshotを記録する。経路テンプレート、Whois route object、ROAは、それぞれ変更前と変更後を分けて示す。各変更には記録別の優先ルールとreason codeを付ける。

受領票はトランザクション境界を描く。同時commitされた書き込み、公開待ちの処理、APNICの権限外にあるシステムを区別する。部分失敗なら、成功段階、失敗段階、最後の安全な状態、再試行条件、quarantineとcompensating actionを残す。

可視性の時刻も分ける。Whoisで検索可能になった時刻、RPKIに公開された時刻、独立validatorが観測した時刻を示す。BGPは補助的な観測として加えられるが、命令でも到達性保証でもない。

inter-RIR、NIR、割り当て解除、外部IRRはscope flagにする。通知先の役割、受領確認、レビュー、override、サービス責任者を記録し、個人の認証情報や秘密鍵は出さない。rollbackは元のtaskを消さず、新しい結果を履歴へ追加する。

これは本稿の提案であり、APNICが発表済みの機能ではない。全内部ログの公開も求めていない。必要なのは、意図した差異、未完了の同期、正当に完了した変更を利用者が区別できる最低限の証拠である。

APNICが手作業を減らすことには価値がある。ただし、整ったデータは正しい判断の証明にはならない。機械が衝突の勝者を選ぶ前に、その競技規則と結果を読める形にするべきだ。

出典