要約

  • ACSP 2026.4の提出者は、別のOrgへDetailed Reassignmentを行った後、親NET側のAPIキーでは子NETをhandle指定GETできず、受領Orgのキーだけが成功したと報告した。同じ親は、子NETをDELETEでき、正確な開始・終了アドレスを使うmostSpecificNetでは取得できたという。
  • ARINは2026年3月30日、既存ツールによる別の取得方法と今後の開発計画を検討し、当時は権限変更が不要だとして提案を閉じた。回答は報告された各手順を独立に確認しておらず、Closedは実装済みを意味しない。
  • Detailed Reassignmentでは受領Orgが管理権限を持ち、直接登録者はreclaim権限を残す。公開Whois/RDAPと認証済みNET Payloadも同一ではないため、権限の非対称性には最小権限として合理的な根拠がある。
  • 改善策は親に完全なGETやPUTを渡すことではない。安定した対象ID、親子関係、子NETの有無、処理経路、影響範囲、バージョンを返す限定的な削除前プレビューと、経路別の能力表である。

人がARIN Onlineで再割り当てを削除するとき、公式手順は対象ネットワークを探し、Net Handleを選び、取り消せない操作を確認するよう求める。この順序は大切だ。意図、対象、結果を一つの確認画面に束ねている。

APIでは同じ安全性をどう作るのか。ローカル台帳に残るhandleとアドレス範囲が正しいと信じ、DELETE後の応答で初めて現在の対象を知るのであれば、確認の順序が逆になる。

一つの子NETをめぐる報告

ACSP 2026.4は2026年3月3日に提出された。提出者は、自分のNETから別のOrgへDetailed Reassignmentを作成したと説明する。親側のAPIキーで子NETをhandle指定GETすると、権限不足で拒否されたという。受領OrgのAPIキーなら取得できた。

ところが提出者によれば、親側には別の経路があった。子NETをDELETEでき、正確な開始IPと終了IPを渡すmostSpecificNetならNET Payloadを得られ、WhoisではhandleまたはIPから公開情報を見られた。提出者は、削除できるならGETも、削除して作り直せるならPUTも認めるべきだと主張した。

ARINの結論は異なる。3月30日の回答は、既存ツールで情報を取得する別の方法と将来の開発計画を話し合った結果、現時点でAPI権限チェックの変更は不要だと述べた。提出者の同意を得て状態はClosedとなった。

ここから先を推測で埋めてはいけない。公式ページは提出者の報告とARINの回答を証拠化しているが、障害報告でも独立試験でもない。ARINがすべての再現手順を認定したとは書かれていない。誤削除、情報漏えい、停止も示されていない。現在のあらゆるアカウントとNETで同じ挙動が続くとも断定できない。

それでも、この記録は運用契約の設計を検討するのに十分な具体性を持つ。違いは動詞だけでなく、誰が、どの関係に立ち、どの識別経路を使い、どのフィールド集合を求めたかに宿るからだ。

受領者の管理と親の回収を混ぜない

ARINのリソース管理説明は、simple reassignment、Detailed Reassignment、reallocationを分ける。simpleの顧客には直接管理能力がない。Detailedの受領Orgは直接管理権限を持ち、直接登録者はreclaim権限を維持する。逆引きDNSやIRRの一部には共有領域もある。reallocationの受領Orgはさらに下流へ割り当てられる。

この関係設計を先に守る必要がある。親が受領Orgと同じ完全な読み書きを持てば、Detailed Reassignmentが与えた自律性は形骸化する。逆に、親からreclaimを奪えば、上位のアドレス資源に対する責任を果たせない。

データ面でも同じである。NET Payload仕様には、バージョン、コメント、登録日、Orgまたはcustomer handle、ネットワーク範囲、親handle、名称、origin AS、POCリンクなどが含まれ得る。Whois/RDAPはARINレジストリを基にした公開ディレクトリだが、公開表示と認証済みプロビジョニング用payloadが同じフィールドを持つとは限らない。

したがって、DELETEできる者が完全なGETとPUTを当然に持つ、という一本の階段は作れない。reclaimは関係を終了する限定権限であり、日常管理とは別物である。

ただし、限定権限であっても実行前に対象を確かめる必要は残る。

正確な範囲検索は発見ではなく照合である

Reg-RWSのメソッド一覧では、handle指定GET、正確な範囲を指定するmostSpecificNet、handle指定DELETE、handle指定PUTが別々に定義される。前二者はNET Payloadを返し、DELETEはTicketed Request Payloadを返す。PUTはNET Payloadを入力して変更後の状態を返す。

handleは登録オブジェクトの安定したIDである。一方、開始・終了アドレスは、呼び出し側がすでに正しく把握していなければならない属性だ。Whois/RDAPはまた別の公開発見面である。同じNETに到達しても、入力の前提と開示の意味は違う。

ACSP 2023.13は、正確な範囲を求めるmostSpecificNetが一般的なブートストラップにならない理由を示す。ネットワーク内の任意IPから対象を見つけるのではなく、開始と終了を知っている必要がある。ローカル在庫が正しいときには照合に使えるが、在庫が古いときには古い前提をもう一度提示するだけになり得る。

代替ツールがあることと、自動化可能な前提条件があることは同じではない。人間はポータルで検索し直せる。バッチ処理は、選択時と実行時の間に対象が変わっていないことを機械的に証明しなければならない。

DELETEの重さは子NETで変わる

ARINの説明では、DELETEはreassignmentまたはreallocationにだけ適用される。対象の下に別のNETがなければ自動処理され、削除されたネットワークの情報を含む応答が返ることがある。下位に再割り当て・再配分があればticketとなり、成功するまでアドレス空間を別の顧客へ出してはならない。

つまり、同じDELETEでも子構造によって時間と手順が変わる。自動処理かticketかは、再利用判断にも直結する。操作する側は、この差を送信前に知る必要がある。

NETの変更手順は、正確性のために現在のNETをGETしてから変更するよう勧める。これは古い状態に基づく更新を避ける原則だ。完全なGETを見せるべきでないreclaim主体にも、同じ鮮度をより少ないフィールドで保証する方法が要る。

削除前プレビューという最小単位

親側に必要なのは受領Orgの全payloadではない。次の情報に限定したプレビューで足りる。

  1. 安定したNET handleと正規化されたアドレス範囲
  2. オブジェクト種別と直接の親子関係
  3. 非公開連絡先を含まない受領者種別
  4. 子NETの有無
  5. 自動処理かticketかという予測
  6. DNS、IRR、経路登録に関する影響の要約
  7. 通知先と監査証跡の扱い
  8. 短時間だけ有効なバージョントークン

DELETEはこのトークンを要求する。範囲、階層、重要な依存状態が変わっていれば失敗させ、再プレビューを求める。親が得るのは観測可能性であり、受領Orgの編集権限ではない。

さらに公開の能力表を、

主体の役割 × 関係 × NET種別 × 識別経路 × 動詞 × フィールド集合 × 前提条件 × 結果

の単位で版管理すべきである。simple、Detailed、reallocationを混ぜず、直接の子とさらに下の子を分け、handle・範囲・公開検索を別セルにする。完全payload、公開情報、reclaim用の限定表示も分ける。意図的な非対称には理由と発効日を付ける。

こうすれば、差はすべて欠陥だという誤解も、意図した差なら説明不要だという油断も避けられる。運用者はデプロイ前に契約テストを作り、受領Orgは管理payload、直接登録者はreclaimプレビュー、simpleの顧客は管理権限なし、という期待を確認できる。

Closedは仕様書ではない

既存ツールで必要を満たせる、今後の開発との関係で優先しない、というARINの判断は成立する。すべての提案を即座にAPI変更へ変える義務はない。

しかしClosedは提案ワークフローの状態にすぎない。報告の全面確認、修正の投入、または将来にわたる問題の不存在を証明しない。「現時点では不要」という表現は、むしろ現在の境界を正確に残している。

意図された規則が「親はDetailed Reassignmentをreclaimできるが、受領者の完全なNET Payloadをhandleでは読めない」なら、そのまま能力表に書けばよい。範囲検索やARIN Onlineが正式な事前確認なら、必要な在庫と確認できる範囲を示すべきだ。

アクセス制御の品質は、拒否の多さでは測れない。拒否が理解でき、許可された重大操作が事前に検証できるかで測るべきだ。受領者の自律性と親の安全なreclaimは両立する。その間に必要なのは大きな扉ではなく、小さく権威ある覗き窓である。