32 ビットの制約は技術的であり、割り当て体制は政治的であった

要約

• RFC 791は、IPv4 の送信元アドレスと宛先アドレスをそれぞれ 32 ビットに固定し、当初は通常のユニキャストアドレスを 3 つのクラスで解釈した。地域レジストリ、需要予測、使用率テスト、プロバイダ依存、監査、制裁、不服申し立てについては規定していなかった。
• 名目上の \(2^{32}\) すなわち 4,294,967,296 個の可能な 32 ビット値は、割り当て可能なパブリックホストアドレスの単一のプールではなかった。クラス構造、特殊な値、予約、割り当て保有状況、ルーティング可視性、実際の使用状況によって、異なる分母が生じ、それらを組み合わせることはできない。
• 1993 年から 1996 年にかけて、公開されたガイドラインは結果をもたらすルールを選択した：RFC 1466 における 24 か月予測とクラス B の閾値、RFC 1519 におけるトポロジーベースの集約、RFC 2050 におけるスロースタート割り当て、プロバイダ階層、使用率テスト、監査、アドレス返却、上位レジストリへの不服申し立てである。
• 節約と集約は、特にクラスフルな無駄やルーティングテーブルの増加といった真の工学的危険に対処した。政治的な要素は、不足を捏造したことではなく、どのようにそのコスト、権限、例外、救済策を配分するかについて、実行可能な方法の中から、特定可能な機関が選択した点にある。
• 公開された割り当て記録は成功した出力を示しており、それらを生み出した要求、拒否、修正、遅延、非公式な指導を示してはいない。制度の文書と技術的根拠は、その完全な分配効果よりも、より高い信頼性で再構成できる。

アーキテクチャが境界を設定し、管理がテストを選択した

二つの年代記録が本質的な区別を確立する。

1981 年 9 月、RFC 791 は、送信元アドレスフィールドと宛先アドレスフィールドをそれぞれ 32 ビット幅と規定した。インターネットアドレスを 4 オクテットと定義し、その初期の通常ユニキャスト解釈をクラス A、クラス B、クラス C の形式に分割した。クラス A アドレスは、1 ビットのクラス識別ビット、7 ビットのネットワーク番号ビット、24 ビットのローカルアドレスビットを使用した。クラス B は 2 ビットのクラスビット、14 ビットのネットワーク番号ビット、16 ビットのローカルアドレスビットを、クラス C は 3 ビットのクラスビット、21 ビットのネットワーク番号ビット、8 ビットのローカルアドレスビットを使用した。これらはプロトコルの機能であり、アドレッシングの議論とヘッダ仕様に記述されていた。RFC 791、1981 年 9 月、セクション 2.3 および 3.1、7 ページおよび 11～12 ページ

1993 年 5 月、RFC 1466 は、レジストリが加入者による今後 24 か月間の必要エンドシステムアドレス数の予測に基づいて、連続したクラス C を割り当てるよう推奨した。予測が 256 アドレス未満の場合は 1 つのクラス C ネットワーク番号に、512 未満なら 2 つ、1,024 未満なら 4 つ、というように、16,384 未満の予測に対して最大 64 個の連続クラス C ネットワーク番号を割り当てる。クラス B については、申請者が 32 以上のサブネットかつ4,096 以上のホストを有することを、今後 24 か月をカバーするエンジニアリング計画とともに示すべきであると文書は述べた。RFC 1466、1993 年 5 月、セクション 4.2.1 および 4.3、6～8 ページ

RFC 1466 は情報提供であり、そのステータス通知は、インターネット標準を規定するものではないと明示していた。著者は Elise Gerich であり、アブストラクトには、連邦ネットワーキング評議会のために行動する連邦エンジニアリング計画グループ、大陸間エンジニアリング計画グループの共同議長、そして RIPE からの推薦への一般的な支持が記録されていた。この組み合わせは、制度的支持を得た執筆された推薦の証拠である。これは、すべてのレジストリが直ちにすべての閾値を実施したこと、IETF の標準化アクションがそのポリシーを強制したこと、または影響を受けるすべてのネットワークが同意したことの証拠ではない。RFC 1466、ステータス、アブストラクトおよび謝辞、1 ページおよび 9 ページ

プロトコルとガイドラインは異なる問いに答えた。32 ビットのフィールドは外側の数学的空間を定義した。それは予測期間、割り当て階層、使用率の計算式、地理的地域、監査権限、不服申し立て経路を選択しなかった。ルールは真の制約に対する慎重な対応であったかもしれないが、ヘッダから導き出せるものではなかった。

これがここでの政治的という限定された意味である。それは、技術的・管理的に妥当な複数の取り決めの中から、特定の執筆または実施機関が選択した決定を特定する。その選択によって、権限が移行したり、異なる文書化、遅延、プロバイダ依存、ルーティング、再番号付け、レビューのコストが課されたりしたのである。不足が捏造されたこと、主体が党派心を持っていたこと、あるいは選択が腐敗していたことを意味しない。誰がルールを選択したのか、当時の条件下でどの代替パラメータが選択可能であったのか、そして、その結果としての負担や権限がどこに帰属したのかを問うものである。

一つのアドレス空間が複数の互換性のない分母を生み出した

おなじみの計算は正確である：

\[2^{32}=4,294,967,296 \]

その単位は、32 ビットの送信元または宛先アドレスフィールドごとの名目上のバイナリ値である。これは、割り当て可能なパブリックホスト数、組織数、顧客接続数、レジストリ付与数、経路数、あるいは空間への申請数を数えたものではない。

クラスビットは直ちにその数学的空間を分割した。未加工のクラス A ネットワーク番号フィールドは\(2^7=128\)のビットパターンを含み、クラス B は\(2^{14}=16,384\)、クラス C は\(2^{21}=2,097,152\)を含んだ。管理上の会計は、すべての未加工パターンを通常のネットワーク番号として扱わなかった。代わりに、RFC 1466 の 1992 年 5 月のテーブルは、126 のクラス A、16,383 のクラス B、2,097,151 のクラス C ネットワーク番号を数え上げた。これらの数字は、クラスフルなネットワーク番号の母集団であり、アドレス値や組織数ではない。

テーブルはまた、1992 年 5 月時点で、49 のクラス A ネットワーク番号、7,354 のクラス B ネットワーク番号、44,014 のクラス C ネットワーク番号が割り当てられたと記録している。これらは、特定の管理テーブルにおける成功したエントリである。それらは、申請者の数を明らかにせず、どれだけのアドレスが占有され、アナウンスされ、到達可能であり、あるいは要求されたかを測定しない。RFC 1466、セクション 3、表 1、3 ページ

したがって、防御可能な分母監査は、以下の母集団を分離する。

これらの区別は、単なる意味論的な細かさではない。各行は異なる問いに答えている。トップレベル割り当ては、割り当てられた空間がアナウンスされていることを示さずに、一つの管理プールを減少させる。経路は、少数の占有エンドポイントを含む大きなブロックをカバーしうる。複数の経路が一つの割り当てを表すこともある。割り振りは未使用のまま残ることがあり、一方で一つのホストが複数のアドレスやインターフェースを持ちうる。RFC 791 自体が、複数の物理インターフェースと複数の論理インターネットアドレスを持つホストを想定していた。レジストリ台帳とルーティングテーブルは、両方ともプレフィックスを含んでいるというだけの理由で統合することはできない。

当時の通常のホスト識別子の慣例は、さらに別の母集団を生み出した。RFC 1519 は、クラス C ネットワークが、引用された慣例の下で全ゼロと全一のローカル値を除外した後、最大\(2^8-2=254\)の通常ホスト識別子をサポートし、クラス B は最大\(2^{16}-2=65,534\)をサポートすると述べた。これらは一つのネットワーク内の潜在的な通常識別子であり、接続されたホストの数ではない。RFC 1519、提案標準、1993 年 9 月、セクション 1、1～2 ページ

規模のためだけに、接続された 600 台のホストそれぞれに 1 つの識別子が必要だと仮定しよう。クラス B の 65,534 の通常識別子は、記載された要件の\(65,534/600=109.223\)倍を提供し、即時の要件外に\(65,534-600=64,934\)の通常識別子を残す。この計算はクラスフルな粒度を示しており、実際の 600 ホストの申請者が予備を必要としないか、フラットなトポロジーを持っているか、任意のクラスレスブロックを運用できることを証明するものではない。

RFC 1466 は、異なる 600 ホストの例を提示した。600 台のホストが 10 のイーサネットに均等に分割され、トポロジーが共有クラス C ブロックを困難にする場合、加入者は、デフォルトの 2 のべき乗テーブルから逸脱するためのエンジニアリング上の正当化を条件として、イーサネットごとに 1 つずつ、10 のクラス C ネットワーク番号を受け取ることができた。そこでの単位はクラス C ネットワーク番号であり、フリープールから引き出された 600 アドレスではなかった。RFC 1466、セクション 4.3、8 ページ

後の証拠も同様の注意を要する。CAIDA の IPv4 消費研究は、2005 年 9 月 14 日に収集された IANA ファイルと、ARIN、APNIC、LACNIC、RIPE について 2005 年 8 月 31 日に取得された WHOIS スナップショットから構築された。AfriNIC のスナップショットは欠落していた。CAIDA は、共有表現を作成するためにフォーマットの差異を除去し、各 RIR の行を IANA ファイル内のそのレジストリに関連付けられた空間に制限することで、移行や相互参照による重複出現を削減した。移行されたレガシー資料は、別個の「various」セットに統合された。CAIDA、「IPv4 Consumption Rates」、Methodology and Caveats

その数値は、アドレス量を用い、一般に等価な/8量として表現された。それらは、IANA 割り当て、最初の下流レジストリ出現、データ内に見つかった最も具体的な割り振りを区別した。CAIDA は、グラフが割り当てを示すものであり、アナウンスや到達可能性を示すものではないと明示した。また、IANA のクリーンアップにより、正確な履歴日付が利用できない多くのレガシー記録に対して 1993 年 8 月が割り当てられたと説明した。これらは遡及的に埋め込まれた管理日付であり、回復された取引日付ではない。CAIDA、Methodology、Caveats、Figures 1～7

この再構築は、なぜ管理レベルを分離しなければならないかを示すのに有用である。それは、1993 年における申請者の経験を示す同時代の証拠ではない。それは、要求、拒否、修正、経路、アナウンス、到達可能なホスト、占有インターフェース、動機、またはポリシーの因果関係を測定しない。

Richter、Allman、Bush、Paxson による『A Primer on IPv4 Scarcity』はさらに後のものである。この論文は 2014 年 11 月 10 日に提出され、2015 年 2 月 27 日に改訂され、2015 年 4 月に『ACM Computer Communication Review』45(2)に編集寄稿として掲載された。これは貴重なレトロスペクティブな統合であり、技術的、制度的、枯渇期の発展のためのソースリードである。しかし、1981 年～1998 年に行為者が何を知っていたか、当時の申請者がどのようにレジストリを経験したか、メカニズムが展開されたかどうか、あるいは同時代の人々が後の市場や財産のドクトリンを保持していたかどうかを立証することはできない。Richter et al.、「A Primer on IPv4 Scarcity」、出版記録

外側の数学的境界は単一であった。運用上の不足はそうではなかった。それは、クラスフルなネットワーク番号数、予約範囲、レジストリ保有分、割り振り単位、ルータ状態に現れ、それぞれが独自の日付と分母を持っていた。

クラスフルな無駄とルーティング圧力は本物だった

最初の直接的な圧力は粒度から来た。254 を超える通常ホスト識別子を必要とする組織には、300、600、4,000 といった要件に見合った固有のクラスフル割り当て単位がなかった。クラス B はあまりに大きすぎることがあり、クラス C の集合はアドレス量的には近いが管理が難しく、効果的な集約以前にはグローバルルーティングシステムにとってより高価だった。

サブネット化は、既存のクラスフルネットワーク内では役立った。1985 年 8 月の標準化過程仕様である RFC 950 は、ローカルアドレスフィールドをサブネット部分とホスト部分に分割するアドレスマスクを定義した。組織は、内部の各ケーブルを独立したネットワークとしてアドバタイズする代わりに、複数の内部サブネットにわたって一つの外部認識ネットワーク番号を使用できた。しかし、それだけでは、ドメイン間機構が依然としてクラス解釈に依存しているインターネットに対して、レジストリが任意のグローバルに経路制御されるプレフィックス長を発行できるようにはならなかった。RFC 950、1985 年 8 月、セクション 2.1、4～6 ページ

第二の圧力は転送テーブルだった。以前のクラス B 付与を 16 の個別にアドバタイズされるクラス C ネットワークで置き換えることは、クラス B ネットワーク番号を節約する一方で、集約が利用できない場合には 16 のルーティングエントリを追加することになった。したがって、アドレス節約とルーティング節約は逆方向を指し得た。

1993 年 9 月に提案標準として公開された RFC 1519 は、三つの問題を説明した：クラス B ネットワーク番号の急速な枯渇、利用可能なソフトウェアやルータの能力を超えるルーティングテーブルの増大、そして 32 ビット空間の最終的な枯渇。その当面の戦略は CIDR だった：より適切なサイズの連続ブロックを発行し、分配をトポロジーに合わせ、プロトコルサポートと接続性が許す場合には集約をアドバタイズすること。RFC 1519、ステータスおよびセクション 1～3、1～9 ページ

その定量的議論には、正確なテーブルと丸められた散文の両方が必要である。

MERIT を出典とする表 I は、1992 年 1 月に 4,526 のアドバタイズ経路、1992 年 12 月に 8,561 を記録した。セクション 3.3.2 では、1 月の NSFNET ルーティングデータベースを「約 4700」エントリと記述し、12 月のテーブルを 8,500 と記述した。歴史的テーブルは 1988 年から 1991 年の間に平均して 10 か月ごとに倍増しており、1992 年 1 月のベースラインから 2 年後には約 30,000 エントリになると予測していた。RFC 1519、表 I およびセクション 3.3.2、7～9 ページ

その予測は、述べられた丸められた入力からは導かれない：

\[4,700\times 2^{24/10}=24,806.75 \]

1 月の表 I の正確な観測値を使用すると：

\[4,526\times 2^{24/10}=23,888.37 \]

どちらの結果も、通常の丸めでは約 30,000 にならない。この記事は、30,000 を RFC 著者による公表された、未調整の予測としてのみ保持できる。出典は、30,000 と丸められた入力結果との間の約 5,193 エントリの差を説明していない。そのギャップを埋めるために異なるベースライン、成長間隔、隠れた調整を捏造することは不適切である。

12 月の比較はより単純である。表 I の観測単位は、1992 年 12 月の 8,561 のアドバタイズ経路だった。セクション 3.3.2 はそれを 8,500 に丸め、以前の曲線によって予測された 9,400 超と比較した。著者らは、より低い観測値が成長の意味のある変化を表しているかどうか判断できないと述べた。これらは MERIT/NSFNET の文脈からの観測と予測であり、すべてのルータのセンサスでも、インターネットが機能しなくなる物理的限界でもなかった。

RFC はまた、以前はクラス B が使用されていたかもしれない場所で、4～16 のクラス C 経路を発行した場合の影響も検討した。それは条件付きで、ルーティングテーブルが 6 か月以内に 10,000 エントリ、1 年以内に 20,000 エントリを超える可能性があると予測した。これらは個別にアドバタイズされるクラス C ネットワークに基づくシナリオ結果であり、観測された結果ではない。集約はまさにそのような増加を防ぐことを意図していた。

工学的論理は強力だった。一つのプロバイダを通じて接続する顧客が、そのプロバイダのブロックの連続サブセットを受け取った場合、プロバイダは一つのより具体的でない経路をアドバタイズできた。10 の独立して経路制御される顧客ブロックは、10 のグローバルに可視なエントリを必要とするかもしれないが、10 のトポロジーに合わせた顧客ブロックは、例外や正しい動作を条件として、一つの集約の背後に置くことができた。正確な節約は、マルチホーミング、ルーティングポリシー、障害、フィルタ、そしてより具体的な経路が依然として伝播されなければならないかどうかに依存した。

移行は自動的ではなかった。1992 年 6 月に情報提供の提案として公開され、後に RFC 1519 によって廃止された RFC 1338 は、新しいアドレス計画とドメイン間ルーティングプロトコルの変更の両方が必要であると警告した。それは、トポロジー指向の割り当ての展開と互換性のあるプロトコルの展開の間の期間に、ルーティングテーブルが非常に急速に増大する可能性があると述べた。RFC 1338、1992 年 6 月、セクション 2.1、4 ページ

BGP-4 は、クラスレスプレフィックスを運搬し経路を集約するための仕様を提供したが、公開ステータスと展開を混同してはならない。RFC 1654 は 1994 年 7 月の標準化過程の BGP-4 仕様だった。RFC 1771 も標準化過程であり、1995 年 3 月にそれを置き換え、IP プレフィックスのサポート、BGP 内でのネットワーククラス概念の除去、経路および AS パス集約について記述した。RFC 1654、1994 年 7 月、ステータスおよびセクション 1～2、1～2 ページ;RFC 1771、1995 年 3 月、ステータスおよびセクション 1～2、1～2 ページ

これらの出版物は、仕様のステータスと文書化された能力を確立する。それらは、特定の日付に何台のルータが BGP-4 を実行していたか、どのネットワークがクラスレス経路を交換していたか、テーブルのどの程度が集約されていたか、あるいは採用が 1998 年までに普遍的であったかを確立しない。名前付きのルーティングスナップショット系列、観測日、母集団、視点なしには、数値的な展開率や「1998 年までに確立された」という主張は正当化されない。

予測ルールは不確実性を割り当てた

RFC 1466 のクラス B ルールは、制度上の選択を最も明確に露呈する。その規定された基準は、32 以上のサブネットかつ4,096 以上のホストを求めた。申請者はまた、クラス C のブロックが不合理である理由を示し、今後 24 か月間の予想ホスト数とサブネット数を提供しなければならなかった。計画がクラス B を正当化しない場合、規定された結果はクラス C のブロックだった。数値基準を満たさなかったがクラス C を使用できない申請者は、エンジニアリング上のケースを作ることができた。文書はこれらの閾値を、プロトコル不変量ではなく、推奨基準と呼んだ。RFC 1466、セクション 4.2.1、6～7 ページ

直接の技術的目的は、クラス B ネットワーク番号の節約だった。当時の慣例の下では、一つのクラス B は 65,534 の通常ホスト識別子を露出した。その単位をはるかに小さな要件のネットワークに付与することは、その容量の大部分を遊ばせる可能性があった。サブネット計画は、申請者が単にその利便性を好むのではなく、クラス B が収容できるトポロジーを必要としているかどうかをテストした。

RFC 1466 は負担を認識していた。それは、クラス B 割り当ての制限により、一部の組織が複数のクラス C ネットワーク番号を使用するために追加のリソースを費やす必要が生じ得ると述べた。文書はそのコストを不幸ではあるが節約を追求するために必要であると見なした。これはコスト帰属の異常に直接的な証拠である。執筆された推奨は節約ルールを選択し、影響を受ける申請者による追加のエンジニアリング支出を結果として特定した。RFC 1466、セクション 4.2、6 ページ

にもかかわらず、24 か月の期間は一つのパラメータだった。情報提供の RFC はなぜ予測が必要かを文書化したが、24 か月が総アドレス浪費、処理コスト、遅延、または予測誤差を一意に最小化することを示さなかった。12、18、36 か月のテストは、直接の当時の提案が作成されない限り、分析者が構築したバリエーションとなる。このようなバリエーションは、同じ申請者が異なる期間にわたって同じカテゴリのエンジニアリング証拠を提出できるため、管理上考えられる。その実際のパフォーマンスは未知のままである。より短い期間は楽観的な成長への露出を減らすが申請の繰り返しを増やし、より長い期間は取引頻度を減らし得るが予測誤差が大きくなるというコストを伴う。

クラスレス割り当ては、1993 年までにはより技術的に根拠のある代替案だったが、制限内でのみだった。RFC 1338 は 1992 年 6 月に連続プロバイダブロックを提案しており、RFC 1519 は 1993 年 9 月に CIDR の割り当てと集約戦略を規定した。それら自身の警告は必要な前提を示している。レジストリは適切な境界で割り当てを行い、プロバイダはトポロジーに合わせたブロックを維持し、ドメイン間プロトコルとルータは任意のネットワークとマスクのペアをサポートしなければならなかった。これらの条件が十分に実装される前に、より細かいブロックを発行することは、経路を減らすどころか増やす可能性があった。

RFC 2050 は 1996 年 11 月に予測設計をシフトさせた。それは ISP 割り当てをエンド企業割り振りから分離した。セクション 2.1 は、新規 ISP は当面の要件に基づき最小限の割り当てを受け取ると述べた。その後の割り当ては、ISP が使用率の検証を提供した後に増加でき、追加の空間は約 3 か月分の下流割り振りをサポートすることを意図していた。予測される顧客基盤はほとんど影響しないと言われ、実証された要件が支配した。RFC 2050、BCP 12、1996 年 11 月、セクション 2.1、4～5 ページ

有名な 25％と 50％の数字は別の場所に属していた。それらは、エンド企業のための割り振りフレームワーク内のセクション 3.1 に現れた。即時使用率 25％、1 年以内に 50％の使用率である。セクション 3.6 は、分子をネットワークに接続されたホスト数、分母をそのネットワーク上の可能な総ホスト数と定義した。したがって、1 年基準は、接続されたホストがその期間内にネットワークの可能なホスト母集団の少なくとも 50％に達することが期待されることを意味した。それは、アドレスに対する顧客数、割り当てサイズに対する割り振りアドレス数、アドレスに対するインターフェース数、あるいは ISP 割り当てに対する下流割り振り数の比率ではなかった。RFC 2050、セクション 3.1 および 3.6、7 および 9 ページ

この区別は制度分析を変える。エンド企業は、提案されたネットワーク上の可能なホストに対する接続ホストの使用率テストに直面した。ISP は、スロースタート、検証された下流使用、約 3 か月分の追加割り振りをカバーすることを意図した補給量に直面した。それらを組み合わせることは、架空の共通指標を生み出すだろう。

両方の設計は、どこかに予測の不確実性を置いた。より大きな当初付与は、需要が実現しなかった場合に共通プールを露出させた。より小さな当初付与は、レジストリの応答性と、申請者が繰り返し成長を文書化する能力の重要性を高めた。RFC は、選択されたルールとその明示された目的を確立する。処理時間の分布、当初要求額、修正履歴、ある申請者クラスが組織的により多くの遅延を被ったかどうかの証拠は提供しない。

階層はトポロジーを依存に変換した

RFC 1466 は、クラス C 形式の番号空間の一部を大きな地理的ブロックに分割し、主要な割り当て責任を資格を有する地域レジストリに委譲することを提案した。それは、分割を「主に管理的分割」であり、分散登録を支援することを意図していると説明した。それはそのレベルで一つの地域レジストリを好み、組織が認識され適切なリソースを持つことを期待し、IANA および中央インターネットレジストリのガイドラインへのコミットメントを要求した。中央レジストリは、必要に応じて加入者にサービスを提供するために利用可能だったが、加入者を地域団体に紹介することもできた。RFC 1466、セクション 2、3 および 4.3、2～4 および 7 ページ

周囲の計画は、分散管理と潜在的な集約を結びつけた。地理的ブロックは中央の作業負荷を減らし、地理とトポロジーが一致する場所では粗いサマリーをサポートできるかもしれない。どちらの関係も保証されなかった。大陸は IPv4 ヘッダにエンコードされておらず、物理的またはプロバイダのトポロジーは必ずしも地域境界に従わなかった。

単一の認識された地域レジストリの選択は、ローカル割り当て、証拠、例外に関する解釈権限を集中させた。重複するレジストリを持つ共有データベース、あるいは申請者が中央と地域の意思決定者の間で一般的に選択できることは、ここで使用されたソースには文書化された当時の提案ではなく、分析上の代替案となるだろう。その実現可能性は、タイムリーなデータベース調整、信頼できる一意性チェック、共通の割り当てルール、競合する付与を防ぐ方法を想定するだろう。これらの前提は 1993 年において管理的に要求が厳しかった。代替案は権限の所在を明らかにするのに有用であり、重複するレジストリがより良いパフォーマンスを発揮したであろうと主張するためのものではない。

RFC 1519 は階層をプロバイダトポロジーへと動かした。それは、すべてではないにしてもほとんどのネットワーク番号をサービスプロバイダを通じて分配することを推奨した。その工学的根拠は直接的だった。プロバイダのブロックから取られたアドレスは、プロバイダの集約で表現できる一方、独立して配置されたブロックはしばしばより具体的な経路を必要とした。文書はまた、分散割り当てが中央番号機関の官僚的負担を軽減すると主張した。RFC 1519、セクション 2.2 および 3、5～8 ページ

RFC 2050 は、IANA、地域インターネットレジストリ、ローカルインターネットレジストリの 3 層レジストリシステムを記述した。ISP フレームワーク内では、デフォルトルーティングなしで複数の場所で経路を交換する ISP は、その地域レジストリから直接空間を求めることができた。他の ISP は上流プロバイダから空間を要求するよう指示された。直接の地域アクセスは、マルチホーミングまたは大規模な中立交換点への接続と関連付けられ、RFC はそれを 4 つ以上の無関係な ISP を接続するものと定義した。RFC 2050、セクション 1.1 および 2.1、3～4 ページ

同じセクションは、プロバイダが顧客の割り振りを接続期間中のローンとして扱うことを奨励した。顧客がプロバイダを変更する際、古いアドレスの返却と新しいプロバイダの空間への再番号付けが推奨され、再利用前の十分な移行期間が設けられた。これは、スイッチングコストの結果を伴うルーティング戦略だった。プロバイダ由来の空間は集約の機会を改善し、顧客のアドレスの継続性はプロバイダ関係に依存するようになった。

コストは既に認識されていた。1996 年 2 月のインターネットアーキテクチャ委員会による情報提供声明である RFC 1900 は、プロバイダ変更後に再番号付けに失敗した組織は、限定的な接続性、結果として生じるルーティングオーバーヘッドをサポートするための追加コスト、あるいはその両方に直面し得ると述べた。そのタイトル『Renumbering Needs Work（再番号付けには作業が必要）』は、この技術の状態を捉えていた。それは変更を容易にするメカニズムの開発と展開を求めたが、再番号付けが安価または日常的になったとは報告しなかった。RFC 1900、1996 年 2 月、セクション 1、2～3 ページ

指名された意思決定者と実装者は、RFC の著者、IANA およびレジストリ当局、地域およびローカルレジストリ、空間を割り当てたプロバイダ、経路を受け入れたりフィルタリングしたりしたトランジットネットワークだった。当時の実現可能な代替案は、無制限のポータブルアドレッシングではなかった。それは異なるバランスだった。より多くの直接割り当ては、一部の顧客の再番号付け依存を減らすが、信頼できる集約や経路受諾調整がなければ、グローバルに可視なプレフィックスを追加しうる。生き残った記録はトレードの方向性を証明する。どれだけの顧客が再番号付けしたか、どれだけが古い経路を保持したか、彼らがいくら支払ったか、あるいはプロバイダが返却をどれほど一貫して強制したかは定量化しない。

監査権限は文面上存在したが、その実践は未測定のままである

第三の制度的選択は、検証と結果に関するものだった。

RFC 1466 は、中央インターネットレジストリが委譲された地域割り当てから会計およびエンジニアリング計画を受け取り、それらの計画をガイドラインとの一貫性について監査することを許可した。クラス C サイジング基準の例外はケースバイケースで決定されることになっていた。文書は、例外登録簿、標準回答期間、公表された立証責任、または独立したレビュアーを提供しなかった。RFC 1466、セクション 4.2.2 および 4.3、7～8 ページ

RFC 2050 は、より広範な証拠の集合を記述した。レジストリは、サブネットマスク、ホスト数、トポロジー、ルーティング計画、展開スケジュール、以前の割り振り、裏付けを要求できた。共通の親の下にある部門や子会社が保有する以前の空間は、企業レベルで考慮され得た。要求はケースバイケースで処理され、ルーティング効率が関連する考慮事項の一つだった。RFC 2050、セクション 3.2～3.5、8～9 ページ

セクション 4 は、すべてのアドレス要求は地域レジストリが適切と見なすあらゆる手段による監査と検証の対象となると述べた。割り振りが虚偽の情報に基づいていることが判明した場合、レジストリは要求を無効とし、割り当てられたアドレスをフリープールに戻すことができた。セクション 3.1 は別途、アドレスは適格基準が満たされ続ける間は有効であり、必要性がもはや存在しなくなった場合には無効化権限を留保すると述べた。セクション 2.1 の返却推奨は、接続が終了した場合のプロバイダ由来の顧客アドレスに適用された。これらは関連するが異なる権限だった。虚偽情報の無効化、継続的必要性のレビュー、プロバイダ変更時の返却である。RFC 2050、セクション 2.1、3.1 および 4、4～5、7 および 10 ページ

文書はまた、階層的レビューも提供した。セクション 6 は、割り当てレジストリに不満を持つ組織が親レジストリに不服申し立てすることを許可した。関連文書が利用可能にされることになり、さらなる申し立てはチェーンを上って IANA に至ることができた。各レジストリはその不服申し立てプロセスを文書化することが期待された。レビュアーは同じレジストリ階層内に留まり、RFC は外部の審判所を創設しなかった。RFC 2050、セクション 6、11 ページ

これらの規定は執行とレビューを許可した。それらは実践を示さない。監査がどれほど頻繁に行われたか、どのような方法が使用されたか、申請者が通知や改善機会を受け取ったか、予測誤差が虚偽表示とどのように区別されたか、アドレスがどれほど頻繁に返却されたか、あるいは申し立てが結果を変えたかどうかを立証する引用ファイルはない。文書は、レジストリ間または個々のケース間の一貫性を示すことはできない。

1996 年の技術の下で、いくつかの手続き上のバリエーションが考えられる。それらはパケット形式ではなく管理を変えるからである：例外に対する書面による理由、定義された監査プロトコル、通知と改善期間、匿名化された統計、または元の決定連鎖の外の担当者によるレビュー。それらは、日付付きの提案が作成されない限り、分析者が構築したパラメータである。それらは、スタッフ、記録保持、機密管理、合意された権限を必要とするだろう。それらのコストと効果は RFC だけからは推定できない。

したがって、制度的選択は現実的だが限定的だった。RFC 2050 は、地域レジストリに検証に関する裁量と表明された結果を与え、レビューを親連鎖に置いた。その設計は虚偽の請求を抑止し、アドレス記録を保存できた。それはまた、事実調査、例外、執行権限を集中させた。権限が存在したという証拠は強力である。その発動と分配的効果についての証拠は存在しない。

RIPE の記録は付与ファイルほどには証明しない

RIPE のエピソードは、委譲された運用の証拠を提供するが、完全な割り当て決定ではない。

RIPE NCC の第 1 四半期報告書の付録 A として登場した RIPE-062『RIPE NCC Internet Numbers Registration Procedures』バージョン 0.5（1992 年 7 月日付）は、RIPE NCC が 1992 年 5 月 1 日以降、欧州インターネットネットワーク番号の委譲されたレジストリとして活動してきたと述べた。その手続きは、個々の組織に直接ではなく、サービスプロバイダや国内または地域の調整機関に番号を提供するというものだった。サービスプロバイダはクラス B ネットワーク番号を一度に一つ要求することが許可され、組織の規模、既存ネットワーク、予想される成長、クラス C ブロックを使用できないことの正当化を要求した。RIPE-062、バージョン 0.5、1992 年 7 月、25 ページ以降

後に RFC 1466 のセクション 3 は、二つのより狭い事実を記録した。RIPE NCC は、RFC の提案の採用前に、193.0.0 から 193.255.255 までのクラス C ネットワーク番号区間を既に受領しており、RFC 1466 のガイドラインの下でその区間内で割り当てを行うことに合意していた。RFC 1466、セクション 3、3 ページ

その区間は\(2^{16}=65,536\)の/24サイズのクラス C ネットワーク番号を含む。後の CIDR 区間 193.0.0.0/8 として表現すると、\(2^{32-8}=16,777,216\)の名目上のアドレス値をカバーする。最初の数字はクラス C ネットワーク番号単位を数え、二番目は区間によってカバーされるバイナリ値を数える。どちらも、接続されたホスト、下流付与、アナウンス、使用状況、あるいは RIPE NCC が要求した量を測定しない。

生き残った記録は、基礎となる要求、正式な付与文書、決定覚書、検討された代替ブロックサイズ、交渉された条件、あるいは正確な付与日を提供しない。RIPE-062 は委譲された手続きを証明する。RFC 1466 は、193.*ブロックの事前の保有と新しいガイドラインの使用への合意を証明する。分散管理と潜在的な集約は、周囲の政策計画の目的だった。それらがこの特定の付与の文書化された動機または交渉された条件であると主張することはできない。

記録はまた、委譲に関する不服申し立てやレビューファイルを含んでいない。それは、委譲が 1992 年までに運用されていたというレジストリレベルの所見を支持する。拒否、不平等な扱い、遅延、閾値の帰着についての申請者レベルの結論を支持することはできない。

技術的対応は段階的に到着した

この期間は、配給に代わる完全に形成された単一の代替手段を提供しなかった。それは、異なるステータス、前提条件、コスト転嫁を伴う部分的な対応を提供した。

プライベート空間は、仕様と代替の違いを例示する。1996 年 2 月の BCP 5 である RFC 1918 は、プライベートインターネット用に三つのブロックを予約した。それは、企業に対して、どのホストが外部ネットワーク層接続性を必要としないかを決定することを要求した。ホストをプライベートとパブリックのステータス間で移動させることは、その IP アドレス、関連する DNS エントリ、そのアドレスを参照する他のホスト上の設定ファイルを変更することを伴った。プライベートルーティング情報は企業境界を越えて伝播されるべきではなく、プライベート DNS 参照は封じ込めを必要とした。RFC 1918、1996 年 2 月、セクション 2～5、3～7 ページ

NAT は 1994 年 5 月までに概念以上のものだったが、証明された普遍的な解決策ではなかった。RFC 1631 は情報提供であり、予備設計を記述した。セクション 3 は、データ内に IP アドレスを運ぶアプリケーションは、トランスレータがその内容を認識して書き換えない限り失敗し得ると説明した。暗号化はそれを不可能にし得た。セクション 4 は、KA9Q ソフトウェアと Cray Communications ルータにおける実験的実装を特定し、Telnet と FTP でテストされ、プロトタイプは論文の明示された制限内でのみ透過性を実証したと述べた。RFC 1631、1994 年 5 月、セクション 3 および 4、6～9 ページ

IPv6 はアーキテクチャ上の分母を変えた。1995 年 12 月に標準化過程仕様として公開された RFC 1883 は、IP アドレスサイズを 32 ビットから 128 ビットに増加させた。それは公開時にインストールされた IPv4 ホスト、ルータ、アプリケーション、運用手順を置き換えなかった。1996 年に IPv4 要求を扱うレジストリにとって、IPv6 は指定された後継であり、当面の IPv4 割り当て問題が消滅したことの証拠ではなかった。RFC 1883、1995 年 12 月、ステータスおよびセクション 1、1 および 3 ページ

再利用にも段階があった。RFC 2050 は、接続終了後のプロバイダ由来アドレスの返却を推奨し、特定の状況での無効化を許可した。それは、回収されたブロックのデータセットを含まず、運用ネットワークがどれほど容易にそれらを放棄できるかを確立しなかった。再利用は許可されたメカニズムであり、測定された供給応答ではなかった。

ハードウェアの改善は条件付きの可能性に留まった。RFC 2050 は、アドレッシング制約がルータ技術、割り振り慣行、アーキテクチャ上の歴史を反映していると述べた。文書は、その著者、レビュー中の IETF ワーキンググループ、IESG による、これらの制限を克服する他の現在展開可能な技術は存在しないという結論を報告しつつ、後にルータがより大規模でより動的なテーブルを扱えるようになったり、他の手段で集約が可能になった場合にはレビューを許可した。それは同時代の技術に関する制度的評価であり、すべてのルータのベンチマークではなく、付随する予測、監査、不服申し立てパラメータが制度的に唯一であることの証明ではない。RFC 2050、導入部、2 ページ

RFC 2050 はポリシー支持なしに実践を表現した

制度的役割が重要である。なぜなら「IETF が決定した」と言うことは、いくつかの異なる行為を崩壊させるからである。

RFC 2050 は 1996 年 11 月に BCP 12 として公開され、Kim Hubbard、Mark Kosters、David Conrad、Daniel Karrenberg、Jon Postel によって執筆された。そのアブストラクトは、当時地域レジストリによって使用されていたポリシーを記述し、IANA が開発したガイドラインを実装したものであり、ルールは改訂の可能性に服すると述べた。RFC 2050、タイトルページ、アブストラクト、導入部、1～2 ページ

IESG ノートは、支持よりも意図的に狭かった。文書を現時点での最善の実践として承認するにあたり、IESG は、そのポリシーが現在のレジストリ実践を正確に表現していると信じると述べた。それは、そのポリシーへの支持や推奨を明示的に差し控え、さらなるワーキンググループの議論に照らして再検討を予定した。記述的正確性の承認、テキストの執筆、レジストリガイドラインの開発、レジストリによる実装、ワーキンググループからの助言は、別個の制度的役割だった。

RFC は、節約、経路制御可能性、登録を三つの目標として提示した。また、それらの目標間の、そしてエンドユーザやプロバイダの利益との間の対立も認識した。節約は、供給を実証された需要に密接に一致させることを好んだ。経路制御可能性は、階層的でトポロジーに敏感な分配を好んだ。登録は、割り振りの正確な記録を好んだ。一つの目的に最適化された付与は、他の目的に対してはパフォーマンスが悪くなる可能性があった。小規模な直接割り当てはアドレス量を節約できるが経路を追加し得る。プロバイダブロックはよく集約できるが再番号付けを課し得る。広範な検証は記録を改善できるが取引コストを増加させ得る。

この認識は、恣意的な官僚制の単純化された説明に対する最も強力な内部反証である。著者らは多目的の工学的問題を認識し、慎重な判断を求めた。記録は、その問題を真剣に受け止めることを支持する。それは、すべての閾値や制度的救済策をヘッダの必然的な帰結に変えるものではない。

最も強力な工学的防御は監査を生き残る

公正な判断は、不可逆的な過剰割り当ての危険から始まる。アドレスがいったんルータ設定、DNS、アクセスルール、アプリケーション設定、顧客システム、文書化に入り込むと、回復はコストのかかるものになった。楽観的な大規模付与は、予測が失敗した後にきれいに戻るとは想定できなかった。より小さな当初割り当ては、その露出を制限した。

スロースタートは情報の非対称性に対処した。新しいプロバイダはレジストリよりも自社の事業計画をよく知っていたが、どちらの側も将来の顧客需要を観測できなかった。RFC 2050 のプロセスは、当面の要件、検証された下流割り振り、繰り返しの申請を使用して、予測の不確実性の一部を観測された管理履歴で置き換えた。それはプールを節約し、登録の正確性を改善し得た。

クラスレス割り当ては、深刻なサイズミスマッチを修正した。254 と 65,534 の通常識別子の間の選択は、中規模ネットワークにはひどく不適切だった。連続プレフィックスは、ネイティブのクラス B よりもニーズに近く近似でき、無関係なクラス C の任意の集合を避けることができた。

集約は、別の共有リソースに対処した。1992 年 1 月と 12 月の経路観測は、RFC の未調整の 2 年予測にもかかわらず、具体的な MERIT ソースのテーブルにおける急速な増大を示した。プロバイダ集約は、デフォルトフリールータが運ぶ宛先の数を減らすことができた。利益はトポロジー、ソフトウェア、協力に依存したが、技術的に実質的だった。

プロバイダ階層は、その集約ロジックから従った。顧客がプロバイダのブロックから取得したアドレスを使用する場合、インターネットの残りの部分はしばしばプロバイダ集約に依存できた。ポータブル空間は一つのプロバイダへの依存を減らすが、別個のグローバル経路を必要とし得た。その経路に関連する状態を負担するのは、顧客とレジストリだけでなく、より広いネットワークだった。

文書化もまた、節約以上の目的に資した。割り振り記録は、連絡可能性、逆引き DNS、重複付与の回避、下流使用の検証を支援した。追加容量を要求する申請者は、レジストリが持たない情報を所有していた。したがって、あらゆる手続き上の詳細が議論の余地があろうとも、何らかのレビューは合理的だった。

例外権限は、数値ルールがその工学的目的を損なうのを防ぎ得た。マルチホーミング、異常なトポロジー、機器の制限、大規模な直接要件は、デフォルトブロックを不適切にするかもしれない。ケースバイケースの扱いは、単一のホストパーセンテージでは捕捉できない状況にレジストリが対応することを可能にした。

これらの考察は、節約、集約、登録、スロースタート、慎重な判断に対する深刻な工学的ケースを確立する。無条件の大規模付与のフラットなシステムは、乏しいクラスフル単位をより速く消費し得た。独立して経路制御される小規模付与のフラットなシステムは、デフォルトフリーテーブルを拡大し得た。ルールのないシステムは、重複割り当てや同等の必要性評価をより困難にしたであろう。

防御は制度的唯一性を確立しない。それは、24 か月が最適な予測期間であること、RFC 2050 の ISP 補給期間がレジストリと申請者の合計コストを最小化すること、一つの地域レジストリが唯一の実行可能な構造であること、または階層的不服申し立てが部分的に独立したレビューより優れていることを示さない。工学的証拠は目標と一部のメカニズムを支持する。完全な設計をランク付けするには、申請者、ルーティング、人員、結果のデータが必要だろう。

制約された 1996 年の比較は権限の所在を示し、結果を示さない

有用な反実仮想は、RFC 2050 が公開された 1996 年 11 月に設定できる。IPv4 の 32 ビットフィールド、当時のインストールされたクラスレス対応およびクラスフルな残存物、当時利用可能な BGP-4 仕様、限られたルータリソース、不確実な需要、コストのかかる再番号付け、即時の普遍的な IPv6 変換の不在を一定に保つ。引用された仕様は採用を測定しないため、普遍的な BGP-4、NAT、またはプライベートアドレスの展開を仮定しない。

文書化されたベースラインから始める：プロバイダ指向の割り当て、新規 ISP に対するスロースタート、約 3 か月分の割り振りをカバーすることを意図した追加容量、エンド企業の使用率テスト、ケースバイケースの例外、レジストリ監査権限、親レジストリへの不服申し立て。

ここで、三つの制度的パラメータを分析的に変更する。

第一のバリエーションは補給間隔を変更する。ISP は約 3 か月ではなく 6 か月分を受け取ることができる。これは文書化された歴史的提案ではない。親レジストリがパケット形式を変更せずにより大きな連続ブロックをサイズ決定でき、プロバイダの予測が十分に信頼できるという仮定の下でのみ、管理上もっともらしい。可能性のある権限効果は、より少ないレジストリ取引と迅速な補給への依存度の低下である。可能性のある節約リスクは、成長が失敗した場合のより多くの未使用容量である。要求履歴、予測誤差、割り振りデータなしには、どちらの大きさも推定できない。

第二のバリエーションは、3 か月のスロースタートを保持するが、割り当て帯域と標準的な証拠スケジュールを事前に公開する。これも分析者が構築したものである。レジストリが、顧客の機密資料を保護しつつ公的なルールを維持するための人員と記録システムを持っていることを想定する。それは文書化に関する不確実性を減らし、類似のケースの比較を容易にし得るが、公開された閾値の周りでの戦略的な提示を招き、異常なネットワークに対する柔軟性を減少させるかもしれない。

第三のバリエーションは、技術的階層を保持するがレビューを変更する。当初割り当てと監査決定はレジストリに留まる。元の決定に責任のないパネルが書面による例外と無効化をレビューする。1996 年にそのようなパネルが提案されたことを示す直接のソースはない。バリエーションは、レジストリシステムがレビュアーを任命し、保護手段の下で機密証拠を共有し、追加のプロセスに資金を提供できる場合にのみ、管理上考えられる。それはアドレスビットを追加したり経路集約を変更したりすることなく、一部のレビュー権限を再配置する。

より広範な直接割り当てのバリエーションも説明できるが、その前提はより重い。より小規模なシングルホーム組織は、直接の地域ブロックを受け取り、合意された最小のグローバルに受け入れられるプレフィックスを条件として、プロバイダ変更時にそれを保持できる。その最小値、経路受諾合意、管理能力はすべて分析上のパラメータであり、回復された歴史的ルールではない。この設計は顧客の再番号付けを減らすかもしれないが、独立して可視な経路を増加させるかもしれない。引用された記録は、トランジットプロバイダがそれらの経路を受け入れたであろうこと、または当時のルータが結果として生じるテーブルを吸収できたことを証明しない。

比較は、コストと裁量がどこに位置するかを明らかにする。短い補給は、失敗した予測へのプールの露出を制限する一方で、より多くの取引とタイミングリスクを ISP に課す。より大きな当初付与は、その帰着の一部を逆転させる。公開された帯域は、裁量とルールの可視性をトレードする。別個のレビュアーは、一部の救済権限を元の決定連鎖の外に移動させる。より広範なポータビリティは、継続性を顧客へ、ルーティング状態コストをより広いネットワークへ移転させる。

それは、どのバリエーションが大規模に実現可能だったか、それぞれがどれだけのアドレスを消費するか、どれだけの経路を生成するか、あるいはどれが厚生を改善するかを示すことはできない。較正には、申請者の要求、付与された量と拒否された量、処理時間、予測誤差、プロバイダルーティングポリシー、ルータ容量、人員コスト、再番号付けの結果、監査ファイル、比較可能な使用状況観測が必要となるだろう。これらの入力は存在しない。

したがって、証拠に基づく所見はより狭い。RFC 2050 は、それ自体がその設計の制度的唯一性を実証したわけではない。それは、当時のレジストリ実践を文書化し、同時代の技術的判断を述べ、競合する目標を調整することを意図したルールを記述した。分析上のバリエーションは、それらのルールに埋め込まれた決定を特定する。それらは優れたパフォーマンスを証明しない。

四つの結論、異なる信頼水準を伴う

アーキテクチャ上の事実が最も強力である。RFC 791 は各 IPv4 の送信元および宛先フィールドを 32 ビットに固定した。結果は、フィールドあたり\(2^{32}\)の名目上の値であり、無制限の名前空間でも、4,294,967,296 の割り当て可能なパブリックホストでもない。

クラスフルおよびルーティングの帰結も十分に支持されている。通常のクラス C とクラス B のホスト容量の間の大きなギャップは、中規模の付与を非効率にした。複数のクラス C はクラス B ネットワーク番号を節約できるが、経路を追加した。RFC 1519 の MERIT テーブルは、1992 年 1 月に 4,526 のアドバタイズ経路、1992 年 12 月に 8,561 を文書化した。その約 30,000 の 2 年予測は、述べられた倍増式から再現できないが、経路増大とクラスフル粒度に関する根底にある懸念は、その計算上の誤りだけに依存していたわけではない。

管理上の選択は特定可能である。Gerich の情報提供 RFC は、24 か月予測、閾値、地理的分割、監査、ケース固有の例外を推奨した。CIDR の著者は、割り当てをプロバイダトポロジーとクラスレス集約に結びつけた。Hubbard、Kosters、Conrad、Karrenberg、Postel は、BCP 12 のスロースタート、階層、接続ホスト使用率テスト、監査権限、無効化、返却、階層的不服申し立てを文書化した。IANA、地域およびローカルレジストリ、プロバイダ、トランジットネットワークは、異なる実装役割を占めた。IESG は RFC 2050 を現在の実践の正確な表現として受け入れたが、ポリシーへの支持は差し控えた。

完全な結果は未解決のままである。割り当て記録は要求の分母を含んでいない。引用されたソースは、すべての拒否、削減、撤回、非公式の指導、遅延、監査による改善、返却、例外、不服申し立ての結果を明らかにしていない。後のレジストリデータは、継承され遡及的に埋め込まれた日付を含んでいる。引用された当時のデータセットは、普遍的な BGP-4 展開、完全なアドレス占有、比較可能な申請者負担、あるいは節約への単一の閾値の因果的貢献を測定するものはない。

見出しはこれらの区別を支えることができる。有限のフィールドは技術的だった。クラスフル割り当てとルータ状態は現実の工学的圧力を生み出した。配給体制は、特定可能な機関が、一つの完全な管理構成を規定しなかった制約の下で、予測期間、割り当てレベル、階層、証拠テスト、例外権限、救済策を選択したという、限定された証拠に基づく意味において政治的だった。

技術的必要性は集団的行動を正当化した。しかし、それ自体が、誰が必要性を定義し、機密証拠を保持し、例外を認め、結果を課し、最終的な不服申し立てを決定するかを決定したわけではなかった。