要約

  • IANA の現在の番号資源ページは、IPv4 および IPv6 割り当てレジストリ（最終更新日、利用可能な CSV、XML、HTML、テキスト形式）、AS 番号範囲、RIR 参照、グローバルポリシー参照、要求手順といった重要な公開証拠を開示している。これは強力な公開記録だが、主に現在の状態を示すレジストリと限られた日付であり、完全な外部監査証跡ではない。
  • RFC 7020 は、IP アドレスと AS 番号の割り当て階層の最上位を管理する IANA の役割を説明し、登録の正確性と一意性を中核的要件としている。これらの要件は、可視化された最終テーブル以上のものを意味する。外部の者が、変更が承認され、適時であり、重複せず、適用されるグローバルポリシーと整合しているかどうかを検証できるだけの履歴を必要とする。
  • 公開された要求手続きは、RIR が IPv6、AS 番号、回収された IPv4 の割り当てのために提供する証拠を特定している。その証拠の多くは適格性を証明するが、公開レジストリは、すべての要求パッケージ、検証ステップ、タイムスタンプ、承認状態、修正、返却、置換、署名者の身元を公開していない。ある程度の機密性は適切だが、信頼のみに依存するのは適切ではない。
  • より良い割り当て監査証跡は、署名付きレジストリスナップショット、暗号化ハッシュ、日付付き変更記録、要求区分参照、変更前後の状態、可逆的な修正記録、RIR の確認受領書を公開するであろう。目的は IANA を政治化することではなく、グローバルな一意性台帳を独立して再構築可能にすることだ。

台帳は監査証跡と同じではない

インターネット番号資源システムは、長らくレジストリの公開可視性に依存してきた。誰でも IANA の IPv4 アドレス空間レジストリを開き、/8 ブロックのテーブル、指定、日付、WHOIS および RDAP 参照、ステータス値、注記を見ることができる。誰でも IPv6 グローバルユニキャストアドレス空間レジストリを開き、割り当てられたプレフィックス、RIR 指定、日付を見ることができる。誰でも自律システム番号レジストリを開き、RIR が管理する範囲を見ることができる。これらのページの公開性は、インターネット調整の静かな成功の一つである。

しかし、現在のテーブルと監査証跡は異なる。テーブルは、レジストリが現在何を示しているかを示す。監査証跡は、第三者が現在の状態に至るまでの過程を再構築することを可能にする。すなわち、いつ変更が要求されたか、誰が要求したか、どの適格性ルールが適用されたか、どの証拠がチェックされたか、以前の状態はどうだったか、何が変わったか、誰が変更を承認したか、公開記録がいつ更新されたか、その後の修正によってエントリが変更されたかどうか、そして、その変更を独立した記録と照らして検証できるかどうか、といった問いに答えるものである。

その違いは重要である。なぜなら、IANA は階層の最上位に位置するからだ。アドレスと AS 番号に関する決定の大半は、RIR レベルで行われる。IANA の直接的なトランザクション件数は、地域レジストリと比較すると少ないかもしれない。しかし、最上位の記録は、地域の権限がそこから派生するプールを確立する。グローバルプールのエントリが曖昧であれば、後続の依存連鎖はすべてその曖昧さを継承する。最上位の割り当て日付、指定、またはステータスが、履歴を可視化することなく変更された場合、下流の利用者は結果を見ることはできても、証明を見ることはできない。

したがって、この記事の論点は狭義である。IANA の現在のレジストリが信頼できないと主張しているわけではない。特定のエントリの背後に隠された紛争が存在すると主張しているわけでもない。主張しているのは、グローバルプールの変更に対する主要な証明方法を、制度的評判に依存すべきではないということである。グローバルに一意な番号を調整するシステムは、事業者が経路、証明書、レジストリデータに対して払うのと同程度の真剣さをもって、外部の者がその履歴を再構築できるようにすべきである。

番号階層の最上位

RFC 7020 は、理想化することなく構造を記述しているため、有益な出発点となる。インターネットレジストリ階層は、IANA のアドレス割り当て機能に根ざしており、この機能は地域インターネットレジストリにサービスを提供する。RIR はその後、ローカルレジストリや他の顧客にサービスを提供する。この文書は、割り当てプール管理、階層的割り当て、登録の正確性といった目標を説明している。登録の正確性の目標は特に重要である。一意性は、IP アドレスと AS 番号が同時に複数の当事者に割り当てられないことを保証する。

同じ RFC は、レジストリの役割も制限している。アドレスが実際にインターネットに広告されるかどうか、またどのように広告されるかは、レジストリシステム外の運用上の考慮事項である。この境界は健全である。IANA はルーティング警察、市場規制当局、あるいは下流のあらゆる紛争の審判者になるべきではない。しかし、この境界は、IANA が何をうまくやらなければならないかを明確にもする。IANA の責務が最上位のレジストリであるならば、最上位レジストリの変更の証拠としての品質は、その責務の中核である。

ICANN の定款は、このミッションの狭さを反映している。それによれば、ICANN の役割は、IP 番号と AS 番号の最上位レベルでの割り当てと割り振りの調整、IETF と RIR からの要求に応じたグローバル番号レジストリの登録サービスと公開アクセスの提供、そして影響を受けるコミュニティによるグローバル番号レジストリポリシーの促進と合意された関連タスクである。これは、あらゆるネットワークに対する一般的な権力ではない。それは登録と調整の機能である。その境界が限定的であるからこそ、限定された機能は正確に監査することが容易であるべきである。

これが、割り当て監査証跡が新たな政策権限の要求ではない理由である。それは、公開記録が既存の権限の重要性に見合うものであるべきだという要求である。IANA がブロックの状態を変更したり、IPv6 プレフィックスを割り当てたり、AS 番号範囲を記録したり、返却を受け付けたり、指名登録者を変更したりする場合、そのイベントはリスクに適した水準で外部から証明可能であるべきである。レジストリが上位にあればあるほど、単に最終的なテーブルが正しいと言うだけでは許容されなくなる。

IANA が現在公開しているもの

現在の公開記録にはいくつかの強みがある。IPv4 アドレス空間レジストリには、最終更新日として 2025-10-10 と記載されている。登録手続きがリストされている。RIR への割り当てはグローバルポリシーに基づいて行われ、その他の割り振りには IETF レビューが必要であると説明されている。IANA が元々すべての IPv4 アドレス空間を直接管理しており、後に一部が特定の目的または地域のために他のレジストリに割り当てられたことが説明されている。RFC 7249 を参照し、CSV、XML、HTML、プレーンテキスト形式を提供している。

IPv6 グローバルユニキャストレジストリも、最終更新日が 2025-10-10 と記載されており、RIR 割り当てにはグローバルポリシー、その他の割り振りには IETF レビューを参照し、割り当て可能なグローバルユニキャスト空間は 2000::/3 ブロックであり、そのブロック内のリストにない空間は将来の割り当てのために IANA によって予約されていると説明している。同様に CSV、XML、HTML、プレーンテキスト形式を提供している。テーブルには、後の割り当てが以前の割り当てを組み込んでいるエントリも含まれており、少なくとも一部の履歴的統合が可視化されている。

AS 番号レジストリは、最終更新日が 2026-06-01 と記載されている。AS 番号はルーティングプロトコルによって使用され、IANA が AS 番号を RIR に割り当て、RIR が RIR ポリシーに基づいてネットワーク事業者にさらに割り当てまたは割り振りを行うことを説明している。5つの RIR をリストし、複数の公開形式を提供している。番号資源ページは、RIR 割り当てデータ、要求手続き、グローバルポリシー、技術文書へのリンクも提供している。

これらは些細な開示ではない。レジストリを利用可能にする。自動化されたチェックをサポートする。研究者や事業者が最上位の指定を RIR データと比較することを可能にする。下流のレジストリを理解するための公開ベースラインを作り出す。利用可能な形式は特に重要である。なぜなら、ダウンロードして比較できるレジストリは、ウェブ上のテーブルのみのレジストリよりも説明責任が果たせるからである。

ギャップは、公開記録が示さないことにある。最終更新日は、その日付までにレジストリが変更または再公開されたことを示す。現在の状態に至る各イベントを示すものではない。日付列は、エントリの割り当て月または日を示すかもしれない。必ずしも、要求の受領、検証、承認、公開、修正、またはその後の変更を示すわけではない。CSV ファイルは、両方を公開保存していれば、2つのバージョンを比較することを可能にする。ファイル自体が完全なバージョン連鎖を提供するわけではない。

枯渇後も IPv4 には履歴が必要

安易な答えは、IANA IPv4 フリープールは枯渇しているため、監査問題は主に過去のものであるというものだ。その答えはあまりに浅い。枯渇は、IPv4 レコードに何が起こったかを知る必要性を終わらせなかった。証拠の性質を変えたに過ぎない。残る疑問は、回収された空間、レガシー指定、ステータスの明確性、返却、特別用途のエントリ、RIR 参照、IANA テーブルと地域レコードの関係に関するものである。

IPv4 回収空間に関する IANA の要求手続きは、その理由を示している。RIR が在庫として /8 の半分未満しか持っていない場合、IANA に通知して、回収 IPv4 プールからすべての RIR への割り当てを開始させるべきである。このページは、これが一回限りのイベントであり、各 RIR からの個別の要求に応じてではなく、スケジュールに基づいて行われ、すべての RIR への割り当てを開始するためには、1つの RIR のみが要求を行う必要があると述べている。この設計は、手続き上の証拠を重要にする。トリガーとなる通知、在庫状況、スケジュール、計算式、割り当て結果はすべて、回収プールイベントの公開の正当性の一部となる。

一般には、イベントが正しく発生したという信頼のみに依存すべきではない。トリガーが有効であったこと、スケジュールが適用されたこと、分配前後のプールの状態が保存されたこと、そして各 RIR の確認応答が最終的なエントリと一致していることを、適切なレベルで確認できるべきである。機密性の高い業務上のやり取りは保護できるが、イベントの証拠は可視化されたままであるべきである。

過去の IPv4 指定は、経済的および法的文脈においても重要である。レガシーブロック、特別目的ブロック、RIR 管理ブロックは、移転のデューデリジェンス、ルーティングセキュリティの決定、融資ファイル、調達レビュー、裁判記録に登場しうる。IANA テーブルは保有者の権利の完全な証明ではないが、どのレジストリが空間に対して責任を負うのかを読み手に伝える連鎖の一部である。エントリが修正または再分類された場合、その修正の履歴が問題になりうる。現在のテーブルだけでは、係争中の連鎖には不十分である。

IPv6 エントリは可視化された日付の価値と限界を示す

IPv6 は、公開テーブルがより大きなプレフィックスとより最近の割り当てアーキテクチャをリストしているため、より整理されて見える。IPv6 グローバルユニキャストページは、2000::/3 空間を特定し、そのブロック内のリストにない空間は IANA によって予約されたままであることを示し、WHOIS および RDAP 参照と共に RIR に割り当てられたプレフィックスをリストしている。一部のエントリには、後の割り当てが以前の割り当てを組み込んでいるという注記が含まれている。これは、現在可視化されているプレフィックスだけが全てではないことを読者に警告するため、価値がある。

しかし、同じ例が限界を示している。後の割り当てが以前の割り当てを組み込んでいる場合、読者は以前の状態、新しい状態、統合がなぜ発生したか、下流のレコードが変更されたかどうか、そしてどの要求またはポリシー条件がその更新を裏付けたかを知る必要がある。注記は役に立つが、再構築可能なイベント履歴の方が優れている。

IPv6 に対する IANA の要求手続きは、追加の空間を求める RIR に対し、利用状況と断片化の要約、または適格性パスに応じた最近の割り当てデータの提供を義務付けている。これは、公開された割り当てエントリが、基礎となる証拠に依拠していることを意味する。一般は、RIR の計画の運用上の詳細すべてを必要とするわけではないが、要求区分、適用された適格性ルール、要求が完全として受け付けられた日付、承認日、行われた割り当て、適用されたグローバルポリシーのバージョンを確認できるべきである。さもなければ、外部の読者は結果を見ることはできても、その経路を完全に検証することはできない。

IPv6 はまた、長い時間軸を持つ。2000::/3 の多くが将来の割り当てのために予約されたままであるという事実は、現在行われる決定が何十年にもわたって将来を形作る可能性があることを意味する。イベントが少なく、論争がない場合には、弱い履歴証跡は害にならないかもしれない。しかし、将来、制度的な紛争が発生し、なぜある割り当てが行われたのか、別の割り当てが遅れたのか、あるいはポリシー基準が RIR 間で一貫して適用されたのかが問われる場合には、コストがかかる。

AS 番号は境界変更を可視化するが不完全である

AS 番号は、アドレスよりも単純に扱われることが多い。なぜなら、それはサイズや地理を持つアドレスブロックではなく、ルーティングシステムの識別子だからである。AS 番号レジストリは依然として最上位の割り当て記録である。どの範囲がどの RIR によって管理されているかを一般に知らせ、参照によって予約済みまたは特別用途の範囲を区別している。RIR はその後、地域ポリシーに基づいてネットワーク事業者に ASN を割り当てまたは割り振る。

AS 番号の要求手続きは、証拠の必要性を示している。最後のブロックの 80% 超を割り当てまたは割り振ったために追加の AS 番号を要求する RIR は、割り当てまたは割り振りのサマリを提供しなければならない。RIR が複数のブロックを要求する場合、6か月の使用状況サマリを提供しなければならない。別のパスは、空き AS 番号が2か月の必要量を下回った場合に適用される。これらは定量的なトリガーである。定量的なトリガーは、証拠、タイムスタンプ、計算が保存されている場合にのみ監査可能である。

公開レジストリは、RIR の番号の背後にあるすべてのネットワーク事業者の要求を公開する必要はない。要求された RIR 要求が、宣言された適格性区分に属していたことを証明するのに十分な最上位の証拠を公開すべきである。それは、要求識別子、区分ラベル、受領日、検証日、安全なレベルで表現されたプールの前後の測定値、割り当てられたブロック、責任事業者による署名といったものを意味しうる。最終的な AS 番号範囲テーブルは、イベントの終わりであり、イベントそのものではない。

弱い証拠の結果は実際的なものとなりうる。RIR が範囲を使い果たしたかどうか、範囲境界が変更されたかどうか、特別目的の予約が尊重されたかどうかについて、後日紛争が生じた場合、事業者が必要とするのは記憶だけではない。引用し、再現し、検証できる履歴が必要である。それが、信頼された制度と信頼された記録の違いである。

要求証拠は通信の中に消えるべきではない

IANA の公開番号資源要求手続きは、RIR が何を提供しなければならないかについて、異例なほど明確である。IPv4 回収プールのトリガー条件、IPv6 割り当て要求、AS 番号割り当て要求、指名登録者の変更を特定している。関連する要求メールボックスまで明示し、指名登録者の変更が登録更新前に確認または拒否されるために、現在の登録者と新しい登録者に連絡が行われると述べている。

これらは、割り当て決定が恣意的ではないことを示すのに十分である。それらはしきい値、サマリ、テンプレート、確認に結びついている。しかし、公開記録は、要求からレジストリ更新までの完全なイベント証跡を公開していない。公開受領タイムスタンプ、検証状態、承認署名、証拠のダイジェスト、公開タイムスタンプ、要求が拒否、取下げ、修正、または置換された場合の公開注記を表示していない。

その欠如の一部は擁護可能である。RIR の要求には、非公開の計画詳細が含まれる可能性がある。指名登録者の変更には、個人データやセキュリティ慣行を公開すべきではない連絡先検証が含まれる可能性がある。セキュリティ上機密の通信は、単に好奇心を満たすために公開されるべきではない。ポイントは、すべてを公開することではない。機密の詳細を保護しつつ、決定の公開証拠を公開することである。

シンプルな設計は、証拠と証明を分離する。プライベートな証拠パッケージは当事者と共に残る。公開証明記録は、要求区分、ポリシーバージョン、検証結果、変更前後のレジストリ状態、公開時刻、プライベート証拠パッケージへの暗号学的コミットメントを述べる。後日、重大な異議申立てが生じた場合、権限のあるレビューアは、事後的な主張を世界に信頼させることなく、プライベートな証拠を公開コミットメントと比較することができる。

これは、他の記録システムでは常識である。公的な土地登記簿は、裏付けとなるすべての文書を完全に公開しないかもしれないが、証書番号、日付、以前の状態を保存する。証券保管振替機関は、すべての顧客ファイルを表示しないかもしれないが、決済イベントは記録を残す。インターネット番号資源は、これらの分野を正確に模倣する必要はない。それらには同じアイデアが必要である。検証可能な履歴によって裏付けられた公開の最終性である。

最終更新日は粗すぎる

IANA レジストリページの「最終更新」行は、そのページがどの程度最新であるかを読者に伝えるため、有用である。しかし、ページレベルであり、イベントレベルではないため、十分ではない。レジストリは、小さな変更、フォーマット修正、参照更新、ステータス変更、または割り当てのために再公開される可能性がある。単一の日付では、どのイベントが発生したかが分からない。また、公開キャプチャの間に複数のイベントが発生したかどうかも分からない。

現在の外部からの再構築は、比較に大きく依存している。研究者が昨日の CSV と今日の CSV を保存していれば、その差分が変更を明らかにする。誰も以前のファイルを保存していなければ、一般はウェブアーカイブ、プライベートミラー、または制度的記憶に頼ることになる。これは回避可能な弱点である。権威あるレジストリ事業者は、バージョン履歴を公開すべきであり、偶然のキャプチャから一般にそれを組み立てさせるべきではない。

イベントレベルの日付は、いくつかの重要な瞬間を区別するのにも役立つ。要求受領は、要求が完全であることと同じではない。完全は承認と同じではない。承認は公開テーブルが更新されたことと同じではない。公開テーブルが更新されたことは、すべての下流の RIR 参照が整合したことと同じではない。紛争が遅延に関するものであれば、各瞬間が重要である。紛争が正確性に関するものであれば、変更前後の状態が重要である。紛争が権限に関するものであれば、署名者の身元とポリシーバージョンが重要である。

一般は、圧倒的なイベントフィードを必要としない。最上位の番号資源イベントは比較的少ない。そのため、より良い監査証跡はより現実的であり、より非現実的ではない。少数の重要なイベントは、負担のかかる公開レイヤーを作成することなく、注意深く文書化することができる。イベントの希少性は、正確性のための議論である。

2011年の枯渇の教訓

2011年の IANA IPv4 フリープールの枯渇は、しばしばセレモニーと希少性のマイルストーンとして記憶されている。それはまた、監査の教訓として記憶されるべきである。5つの RIR への IPv4 /8 ブロックの最終割り当ては、世界的に可視化され、ポリシー主導で、制度的に重要であった。それは IANA を、通常のフレッシュな IPv4 割り当てから、回収された空間、移転、地域的希少性、下流市場の世界へと移行させた。

そのような種類のイベントにとって、公開証拠は重要である。問題は、誰が最後のブロックを受け取ったかだけではない。どのポリシーが分配を規定したか、イベント直前のプール状態はどうだったか、イベントがいつ実行されたか、最終エントリがどのように記録されたか、後の読者がその移行を再構築できる証拠は何か、である。耐久性のある証拠がテーブルと報道記事だけであるならば、その記録は、そのイベントが当然受けるに値するものよりも弱い。

これは、2011年が疑わしいからではない。2011年が基礎的だからである。基礎的なイベントは、例外的に十分に文書化されるべきである。それらは、後の政策、金融、訴訟、制度の正統性にとっての参照点となる。将来、回収プールイベント、割り当て修正、レジストリ変更が議論を呼ぶものとなった場合、一般は主要な移行時に設定された基準を振り返るであろう。儀礼的な記録は、監査可能なイベント連鎖の代替とはならない。

同じ理由が、将来の IPv6 および AS 番号のマイルストーンにも当てはまる。IPv6 の供給ははるかに大きいが、割り当てルールは依然として、いつ、どのくらいのサイズのブロックが地域レジストリに移動するかを決定する。AS 番号の枯渇圧力は異なるが、要求のしきい値と範囲境界は依然として重要である。システムが今日静かに機能しているという事実は、ストレスイベントの前ではなく、後に記録を強化するために利用されるべきである。

外部から再構築可能な割り当てが含むべきもの

外部から再構築可能な割り当ては、すべてのプライベートなメッセージを公開する必要はない。十分な情報を持つ外部の者が、承認された状態を再構築するために十分な公開データを必要とする。記録はイベント識別子から始めるべきである。リソースタイプを述べるべきである：IPv4 回収プール、IPv6 グローバルユニキャスト、AS 番号範囲、登録者名変更、修正、返却、予約。適用されるポリシーまたはレビューパス、および有効時のバージョンを述べるべきである。

記録は、要求が受領された日時、それが完全となった日時、承認の日時を示すべきである。要求した RIR または権限のある当事者を特定すべきである。以前のレジストリ状態と新しいレジストリ状態を示すべきである。ステータス変更があれば記録すべきである。しきい値割り当て、スケジュールされた回収プール分配、修正、返却空間、IETF レビュー割り振り、指名登録者確認などといった、公開理由区分を含めるべきである。

その上で、記録は証明を含むべきである。最低限、IANA は署名付きレジストリスナップショットと、ダウンロード可能な各形式のハッシュを公開することができる。変更前後の行を含む変更ログを公開することができる。機密資料を公開することなく、要求証拠パッケージへのハッシュコミットメントを含めることができる。RIR の確認受領書を含めることができる。ナビゲートしやすいアーカイブに、過去のスナップショットを保存することができる。

最終的なレジストリテーブルは、関連するイベント記録にリンクバックすべきである。IPv6 プレフィックスや AS 番号範囲を見ている読者は、日付列から推測する必要がないようにすべきである。イベント履歴をクリックして、そのエントリがどのように作成または変更されたかを見ることができるべきである。これが、権限を述べるレジストリと、それを証明するレジストリの違いである。

署名それ自体は治療薬ではない

暗号署名は役に立つが、問題全体を解決するものではない。署名された悪い記録は依然として悪い。署名された現在のテーブルは、そのテーブルが署名者によって発行されたことを証明するが、割り当てが適格で、適時で、正しく分類されたことを証明するものではない。署名は、より豊かなイベント記録に付加されなければならない。

署名の正しい役割は、完全性と否認防止である。特定のスナップショットが特定の時点で存在したこと、それが改ざんされていないこと、レジストリに責任を持つ事業者がそれを発行したことを証明すべきである。ハッシュは、ダウンロードされた CSV、XML、HTML、テキスト形式を比較し、それらが同じ状態を表していることを確認することを可能にすべきである。タイムスタンプは、後からの再構築が静かにイベントの順序を変更するのを防ぐべきである。

しかし、人によるガバナンスの事実は依然として重要である。どのポリシーが適用されたか？ どの RIR が割り当てを要求したか？ どの証拠のしきい値が満たされたか？ エントリは事務的な誤りのために修正されたのか、それとも以前の割り当てが覆されたのか？ あるイベントが以前のイベントを取って代わったのか？ 署名は、署名された資料がそれらを含んでいなければ、これらの質問に答えることはできない。

これが、監査証跡がセキュリティの飾りとしてではなく、証拠記録として設計されるべき理由である。それは、事業者、裁判所、監査人、レジストリスタッフ、研究者、影響を受けるコミュニティによって理解可能であるべきである。その証明は、人間の決定を可視化し、技術的な封印の背後に隠すべきではない。

RIR リンクは連鎖の一部でなければならない

IANA は階層の最上位に過ぎない。割り当ては、受領側の RIR がそれを記録し管理することで、運用上の意味を持つようになる。したがって、再構築可能な最上位の証跡は、IANA イベントを RIR の確認応答および下流の公開参照にリンクすべきである。目的は、IANA にすべての RIR 割り振りの責任を負わせることではない。引き継ぎが発生し、2つの公開記録が境界で一致していることを示すことである。

IANA テーブルには、多くのエントリに対して WHOIS および RDAP 参照が既に含まれている。それは貴重である。より強力な監査証跡は、引き継ぎイベントを記録するであろう：IANA が最上位エントリを割り当てまたは更新し、RIR が受領を確認し、RIR 公開サービスがその範囲を反映し、既知の遅延や修正があれば注記される。後に記録が分岐した場合、境界イベントは読者にどこから始めるべきかを伝える。

これは障害シナリオにおいて重要である。RIR がガバナンス上のストレス、訴訟、制裁圧力、技術的停止、継続性リスクに直面した場合、事業者は地域サービスが機能不全の間に、リソースの最上位の起源を証明する必要があるかもしれない。署名された IANA イベント連鎖は、RIR に取って代わるものではない。それは、継続性、移行、エスクロー、受託者アクション、または一時的なサービス取り決めのための安定したアンカーを提供する。

それは通常の金融においても重要である。IPv4 移転のデューデリジェンス、融資ファイル、リースレビュー、クラウドの Bring-Your-Own-Address チェック、公共部門調達はすべて、リソースのレジストリ経路がクリーンかどうかを問う可能性がある。IANA の最上位記録は通常、一つの層に過ぎないが、弱い第一層は、それ以降のすべての安心証明書を弱体化させる。監査可能な IANA 証跡は、不確実性に対して支払われる割増金を減らすであろう。

修正は割り当てと同様に重要である

割り当てイベントは、リソースを地域プールに移動させるため、注目を集める。修正はより静かであり、時に一層重要である。修正は、日付、ステータス、指定、連絡先参照、RDAP エンドポイント、注記、または以前のエントリ関係を調整する可能性がある。修正の中には、無害なフォーマット修復であるものもある。他の修正は、第三者が権限、継続性、レガシーステータス、または利用可能なレビューパスをどのように理解するかに影響を与えうる。

公開レジストリは、修正の種類を区別すべきである。綴りの修復は、ステータス変更と同じではない。新しい RDAP エンドポイントは、責任レジストリの変更と同じではない。以前の割り当てを組み込んだ注記は、新規割り当てと同じではない。すべての修正が新しい最終テーブルとしてのみ現れるならば、読者は変更が実体を変えたのか、それとも見せ方を変えたのかを判断できない。

修正の透明性は、レジストリ事業者をも保護する。誤りが発見され修正された場合、最善の回答は沈黙ではない。それは、古い値、新しい値、理由区分、日付を伴った可視化された修正イベントである。その記録は、レジストリが、その誤りが決して存在しなかったかのように装うことなく、誤りを修復できることを示す。それはまた、下流の利用者が自身の記録を正確に更新することを可能にする。グローバルな調整機能において、静かな修正は元の誤りよりも多くの疑念を生み出す可能性がある。

返却も同じ扱いを必要とする。ブロックまたは範囲がプールに返却された場合、そのイベントは、誰が返却したか、どのルールに基づいてか、レジストリ状態がいつ変更されたか、返却されたリソースが回収プールまたは予約状態に入ったか、後のどのイベントが再びそれを移動させたかを示すべきである。返却されたリソースは、レピュテーション、経路履歴、ジオロケーション記憶、商業的期待を伴う可能性がある。最上位の記録は、返却されたプレフィックスに履歴がないことを暗示すべきではない。

これは IPv4 にとって特に重要である。希少性は、回収または再分類されたすべてのブロックに経済的な重みを与える。返却されたブロックは、後にグローバルポリシーの下で割り当てられるかもしれない。買い手、貸し手、公共機関、ネットワーク事業者は、そのブロックの経路がクリーンかどうかを問うかもしれない。答えは、古いウェブキャプチャの再構築に依存すべきではない。権威あるイベント証跡から可視化されるべきである。

公開形式は同一の証明を運ぶべきである

IANA が CSV、XML、HTML、テキスト形式を提供していることは、大きな強みである。異なる利用者は異なる形式を必要とする。研究者は CSV を好むかもしれず、ツールは XML を好むかもしれず、人間の読者は HTML を使い、事業者はテキストをアーカイブするかもしれない。証明レイヤーは、これらの形式を同じ権威ある状態の異なる表現として扱うべきである。

つまり、各公開バージョンは、ダイジェストセットを運ぶか、または伴うべきである。一般は、CSV、XML、テキストのダウンロードがすべて同じレジストリバージョンを表していることを検証できるべきである。後にフォーマット上の理由で一つの形式が再生成された場合、そのイベント記録はレジストリ状態が変更されたかどうかを述べるべきである。これにより、公開データシステムにありがちな曖昧さを回避する：ファイルが変わったのは、レコードが変わったからか、それとも見せ方が変わったからか？

バージョン識別子が役立つであろう。最終更新日のみに依存する代わりに、各レジストリは単調増加するバージョンを持つことができる。各イベントは、以前のバージョンと新しいバージョンを特定する。スナップショットは保存される。利用者は、ダウンロードしたファイルで耐久性のあるイベントアイデンティティを持たないものではなく、「IPv6 グローバルユニキャストレジストリ バージョン X」として引用することができる。裁判所、監査人、事業者は、よりクリーンな参照を持つことになる。

同じ証明が、注記や参照についても利用可能であるべきである。RFC 参照が変更されたり、グローバルポリシーリンクが更新されたり、RIR の RDAP URL が変更されたりしても、それは割り当てイベントではないかもしれない。それでも、それは公開レジストリの一部である。バージョン管理された注記履歴は、参照のメンテナンスがリソースの移動と混同されるのを防ぐであろう。

ウェブアーカイブはガバナンスシステムではない

実際には、研究者はしばしば、保存されたファイル、ミラー、公開ウェブアーカイブを通じてレジストリの履歴を再構築する。これらのツールは有用だが、グローバルな識別子台帳の主要な監査メカニズムであるべきではない。それらは設計上不完全である。それらは第三者が選んだ間隔でキャプチャする。短期間の状態を見逃すことがある。プレゼンテーション変更後はキャプチャするが、データ変更後はキャプチャしないかもしれず、その逆もありうる。ブロックされたり、遅延したり、利用不能になる可能性がある。

権威あるレジストリは、その記憶を偶然に委ねるべきではない。一般が、先月レジストリが何と言っていたかを知るためにプライベートミラーに依存するならば、そのレジストリは証拠の生産が不十分である。紛争が、ウェブアーカイブが正しい瞬間をキャプチャしたかどうかに依存するならば、公開記録はあまりに弱い。グローバルな調整機能は、意図的で、耐久性があり、引用しやすい方法で、自身の履歴を保存すべきである。

これは、独立したアーカイブに対する批判ではない。独立したアーカイブは、公式の履歴に対する貴重なチェックである。それらは、公開記録が存在したことを証明し、後の編集を暴き、制度的失敗の後に資料を保存することができる。しかし、それらの価値が最大となるのは、公式のバージョン連鎖と比較できる場合である。公式記録は、レジストリが何を公開することを意図したかを述べるべきである。独立したキャプチャは、その後、公開が行われ、後に書き換えられなかったことを検証することができる。

この違いは微妙だが重要である。公式のイベント証跡がなければ、外部のアーカイブが主要な証拠となる。公式のイベント証跡があれば、外部のアーカイブは裏付けとなる。成熟したシステムは、依存ではなく裏付けを望むべきである。

監査証跡は制度的政治を減らす

「監査証跡」と聞いて、政治的監視の要求を想定する人もいる。番号資源においては、その逆が真実である。より強力な証拠記録は、事実を絞り込むため、政治を減らすことができる。記録が、ポリシーバージョン、要求区分、タイムスタンプ、以前の状態、新しい状態、責任当事者を明確に示せば、より少ない紛争が制度的評判を通じて争われる必要がなくなる。

これは、制度がストレス下にある場合に特に重要である。RIR が法廷で争われたり、異常なガバナンス圧力の下に置かれたり、制裁の影響を受けたり、構成員から批判されたりした場合、あらゆる曖昧な記録が政治的なシンボルになりうる。クリーンな IANA イベント証跡は、すべての側に共有されたベースラインを提供する。それは地域紛争を決定しない。それは、最上位の記録が何をし、何をしなかったかを示す。

同じことは、将来の競争やポータビリティの提案にも当てはまる。レジストリサービスがよりポータブルになったり、新たなサービスプロバイダーがパトロネージではなく証拠によって認知を求めたりする場合、グローバル台帳は重複割り当てとサービス移行を区別しなければならない。その区別には履歴が必要である。現在の状態テーブルは、ある範囲があるレジストリによって管理されていることを示せる。それ自体では、移行を安全にした通知、確認応答、状態遷移のシーケンスを証明することはできない。イベント証跡ならば可能である。

監査証跡はまた、IANA と PTI を保護する。決定が問われたとき、事業者は一般的な信頼に頼る代わりに、公開イベント記録を指し示すことができる。記録が証明すればするほど、事業者が主張しなければならないことは少なくなる。それは、狭い技術的調整の役割にとって健全な姿勢である。

裁判所、監査人、事業者は異なる質問をする

裁判所は、特定のエントリが特定の日付に存在したかどうかを問うかもしれない。監査人は、レジストリ変更が承認されたコントロールに従ったかどうかを問うかもしれない。事業者は、プレフィックスの責任レジストリがルーティングセキュリティ、逆引き DNS、または abuse 連絡先の依存にとって十分に明確かどうかを問うかもしれない。貸し手は、リソースの連鎖が、誓約または担保分析を裏付けるのに十分にクリーンかどうかを問うかもしれない。公共部門の買い手は、サプライヤのアドレッシング計画が安定したレジストリ証拠に基づいているかどうかを問うかもしれない。

これらの質問は関連しているが同一ではない。現在の IANA テーブルはこれらすべてを助けるが、完全には答えない。裁判所は時点固有の証拠を必要とする。監査人はコントロール証拠を必要とする。事業者は境界の明確性を必要とする。貸し手は瑕疵履歴を必要とする。公共の買い手は継続性の証明を必要とする。豊かなイベント証跡は、いずれか一つをシステムの中心にすることなく、これらすべてのオーディエンスに役立つ。

その利益は累積的である。最上位のイベント証跡が存在すれば、RIR は自身の記録の中でそれを指し示すことができる。事業者はデューデリジェンスファイルでそれを引用できる。研究者は、最上位の割り当てイベントを下流の登録行動から分離するためにそれを使える。政策レビューアは、特定の要求区分がどの程度の頻度で発生するかを見ることができる。将来の説明責任レビューは、スタッフに手動で履歴を再構築させることなく、修正率や公開タイミングを計測できる。

その結果は、より利用可能な公開記録である。より大きな官僚機構でも、政治化された割り当てデスクでも、機密要求ファイルの公開でもない。単に、自身の履歴の検証を許すレジストリである。

運用上の過負荷を伴わない説明責任

一つの懸念は、より豊かな監査証跡が、まさにそのシンプルさゆえに信頼されてきたサービスを遅くする可能性があるということだ。そのリスクは真剣に受け止めるべきである。IANA は、すべての公開に対して重い承認儀礼を強いられるべきではない。設計は、最上位イベントの規模と頻度に合わせるべきである。直接の最上位番号資源割り当ては比較的限られているため、より強力な記録は、通常の公開行為の一部として生成することができる。

最も効率的な経路は、自動化とレビューの組み合わせである。承認された変更が承認されると、レジストリ公開システムは、変更前後の記録を作成し、ダウンロード可能な形式をハッシュし、イベントをタイムスタンプし、ポリシー参照を付加し、過去のスナップショットを保存することができる。スタッフは毎回長いナラティブを書く必要はない。彼らはイベントタイプと理由コードを検証するであろう。機密の裏付け資料は、そのハッシュコミットメントが記録されている間、保護されたままとなる。

第二の懸念は、公開証明が新たな攻撃面を作り出す可能性があるということだ。答えは選択的開示である。一般は、資格証明書、プライベートな連絡先詳細、セキュリティ管理策、機密要求文書を必要としない。一般が必要とするのは、権限と状態変更の公開事実である。うまく設計された証明記録は、安全なイベント事実を保護された証拠から分離するため、後からの暫定的な開示よりも少ないプライベート情報を明らかにすることができる。

第三の懸念は、あまりに高い精度が、無害なタイミングの違いをめぐる訴訟を招く可能性があることだ。それはありうるが、不透明性はより悪い。重要な記録がタイムスタンプを欠く場合、紛争はより広範でより投機的になる。正確な監査証跡は紛争を絞り込む。それは、何がいつ起こったかを当事者に伝える。遅延が無害だったとしても、記録はそれをも示すことができる。

情報源の限界と保守的な主張

この記事のためにレビューされた情報源は、レジストリシステムの構造、公開 IANA レジストリページ、要求手続き、最終更新日、グローバルポリシー参照を示している。それらは、すべての割り当ての隠された履歴を提供するものではない。特定の現在のエントリが誤りであることを立証するものでもない。IANA が証拠を失ったことや、いずれかの RIR が不適切な割り当てを受けたことを証明するものでもない。批判は、検証可能性についてであり、既知の不正行為の主張ではない。

公開情報源もまた、すべてのプライベートな要求、適格性計算、確認、修正を明らかにするものではない。その不在は、適切な機密保護、通常の運用慣行、あるいは単にレジストリのために選択された公開形式を反映している可能性がある。したがって、この記事は、非公開の要求、拒否率、修正件数、公開までの時間に関する正確な統計を避けている。公開記録が正確な最終更新日や明示された手続きを提供している場合には、それらが使用されている。公開記録が分母を提供していない場合には、分母は創作されていない。

情報源の限界は、中心的な論点を強化する。外部の者が公開資料からイベント連鎖を再構築できない場合、システムは、すべてがうまくいっていると信頼するよう外部の者に求めることで答えるべきではない。より良いイベント連鎖を公開することで答えるべきである。

結論

IANA の番号資源レジストリは、公開されており、構造化され、グローバルに認識されているため、貴重である。公開された現在の状態は再構築可能な履歴と同じではないため、不十分である。より強固な基準はシンプルである：すべてのグローバルプールの変更は、何が変わったか、いつ変わったか、なぜ承認されたか、変更前後の状態をどのように検証できるかを示す公開証明記録を残すべきである。

その基準は、IANA を政治的権威に変えることはない。それは正反対のことをする。狭い役割を証明可能にすることで、IANA の役割を狭く保つであろう。グローバルな一意性台帳は、証明を公開できる場合に、評判に依存すべきではない。

レビューされた情報源