クラスフル IPv4 と管理上の希少性の誕生

概要

300 の通常ホストアドレスを必要とするネットワークは、1 つのクラス C ネットワークの実用的な容量である 254 を 46 アドレス超過していた。次のネイティブクラスは 65,534 の通常ホストアドレスを提供し、2 つのクラス C は 508 を提供するが、追加の経路とより多くの調整というコストを伴う可能性があった。したがって、クラスフルな構造は、割り当てをホスト需要の単純な読み取りではなく、異なるコスト間の選択とした。
同時期の 3 つのスナップショットは、クラス C ネットワークが割り当てられたネットワーク番号単位数で支配的である一方、クラス A 割り当てが表されるアドレス容量で支配的であることを示している。1983 年 1 月、31 のクラス A 割り当てが公表された合計の数値アドレス値の 99.648%を占め、1,042 のクラス C は 0.051%を占めた。
残存する資料は、初期の申請、拒否、決定のマッチしたサンプルを提供していない。したがって、一般的な先行者効果、不平等な申請者アクセス、特定の初期クラス決定に使用された基準を確立することはできない。より狭い結論として、後の基準が明示される前に永続的な割り当てが行われていたならば、それはもっともらしい経路依存的な選択肢の優位性を生み出しうるということが支持される。
アドレス空間の不足、ルーティング状態の増大、個々の申請者のサイジング問題、限られた管理上の注意は、それぞれ別々の制約であった。それらは異なる時期に現れ、しばしば異なる割り当て選択を指し示した。
複数のクラス C、サブネット化、連続ブロック、地域委任は当時の実現可能な代替案であったが、それぞれがルーティング、ハードウェア、調整、または管理上のコストを課した。公正な反実仮想は、1980 年代を通じてクラスレスルーティングが利用可能であったと仮定することはできない。

300 の通常ホストを想定するネットワーク計画者は、正確な不連続性に遭遇した。1 つのクラス C ネットワークは、その 8 ビットのローカルアドレスフィールドに 256 の可能な値を含んでいた。後日明確化された、オールゼロおよびオールワンのホスト値に関する制限の下では、254 の通常ホストアドレスを提供した。したがって、要件は 1 つのクラス C を 46 アドレス超過しており、2 つではなかった。数値 2 は、256 の数値と 254 の通常ホストアドレスの差を表しており、300 ホスト計画に対する不足分を表しているわけではない。

2 つのクラス C ネットワークは、508 の通常ホストアドレスで当面の要件を満たすことができた。しかし、それらは依然として 2 つのクラスフルネットワークであり、外部から見えるルーティングエントリが 2 つ、登録が 2 つ、追加のローカルな調整が必要になる可能性があった。次のネイティブクラスであるクラス B は、65,536 の数値ローカルアドレス値、すなわち 65,534 の通常ホストアドレスを提供した。これはクラス C の実用的なホスト容量の約 258.008 倍であり、記載された 300 ホスト要件の 218 倍以上であった。

プロトコルは中間のクラスを含んでいなかった。アドレス値の節約がルーティング状態の節約よりも重要かどうか、組織のハードウェアが安全にサブネット化できるかどうか、2 つの小さなネットワークが混乱なく調整できるかどうか、どれだけの成長を見込むべきかは、ビットパターンの外で解決されなければならなかった。

これが、技術的な粒度が管理上の希少性へと転化した時点である。希少性は、残りのプールが枯渇に近づいたときにだけ始まったわけではない。それは、申請者の必要が利用可能な単位間の広いギャップに落ち込み、管理者が割り当てシステムがどのコストを受け入れるかを決定しなければならなかったときにも現れた。

幾何学が決定境界を作り出した

1981 年 9 月に発行されたRFC 791は、インターネットアドレスを 4 オクテット、すなわち 32 ビットと定義した。その上位ビットは 3 つの通常アドレス形式の 1 つを選択し、それによってネットワーク番号とローカルアドレスの分割を固定した。

当時のクラス	上位ビットパターン	パターン後のネットワーク番号ビット	ローカルアドレスビット	1 ネットワークあたりの数値アドレス数	後日明確化されたルール下での通常ホストアドレス数	現代の表記
Class A	`0`	7	24	16,777,216	16,777,214	/8
Class B	`10`	14	16	65,536	65,534	/16
Class C	`110`	21	8	256	254	/24

スラッシュ表記は、固定されたクラス境界の現代的な変換としてのみ含まれている。1981 年の管理者が任意のプレフィックス長を割り当てることができた証拠として後付けで解釈すべきではない。クラス B は連続的なメニュー上の 1 点ではなかった。その先頭ビットは、クラスフル実装に対して最初の 2 オクテットをネットワーク部分として扱うよう指示した。クラス C は 3 オクテットの後に境界を固定した。システムは、その中間にグローバルにルーティング可能な割り当てをネイティブに提供しなかった。

1 つのクラスから次のクラスへの数値容量比は正確に 256 であった。クラス A は(2^{24})のローカルアドレス値を含み、クラス B は(2^{16})、クラス C は(2^8)を含んでいた。通常のオールゼロおよびオールワンのホスト値を除外すると、実用的な比率はわずかに大きくなる：

(16,777,214 / 65,534 = 256.007782) クラス A あたりのクラス B 容量。
(65,534 / 254 = 258.007874) クラス B あたりのクラス C 容量。

これらの除外は時期を特定する必要がある。RFC 791 はクラス幾何学を確立したが、現代的な使用可能ホスト表を公開しなかった。1985 年に発行されたRFC 950は、サブネット化とブロードキャストの文脈で、ゼロおよびオールワンのフィールドの特別な意味を説明した。RFC 1122は 1989 年に、ホスト、ネットワーク、サブネットの各フィールドは、定義された特別な場合を除き、オールゼロまたはオールワンの値を取ることができないと述べた。

割り当てを比較するには、数値の合計値が最も仮定に依存しない尺度である：ネットワークあたり(2^{24})、(2^{16})、または(2^8)。後日明確化されたルールの下で申請者の通常ホスト容量問題を再構築するには、よく知られたマイナス 2 の数字が適切である。これらの 2 つの尺度を混同すると、300 ホストの例が示すように、誤解を招く主張を生み出す。

また、上位ビットパターンは 32 ビット空間全体を不均等に分割した。0で始まるアドレスは全ビット列の半分を占めた。10パターンは 4 分の 1 を占めた。110パターンは 8 分の 1 を占めた。残りの上位パターンは、マルチキャストや実験を含む他の目的のために予約または開発された。したがって、少数のクラス A ネットワーク番号が数値アドレス空間の巨大な部分を制御し、はるかに多くのクラス C ネットワーク番号の在庫はより小さな割合を占めた。

ネットワーク番号単位と表される容量のこの区別は基本的である。レジストリは、数千のクラス C エントリと数十のクラス A エントリしか含まない可能性があり、ワークロードとしてはクラス C が支配的に見える。同じレジストリを数値アドレス値で測定すると、圧倒的にクラス A に集中している可能性がある。どちらの分母も本質的に間違っているわけではない。それらは異なる問いに答えている。

ネットワーク番号のカウントは、登録され、外部から見える場合にルーティングされなければならなかったクラスフル単位の数に近似する。表される容量は、リストされた割り当て内にどれだけのアドレス値があるかを測定する。どちらも申請者数ではない。どちらもアクティブなホスト、利用率、ルーティング可視性、組織的所有権、経済的価値を測定するものではない。

したがって、クラスフルアーキテクチャは、同時に 2 つの粗さを生み出した。申請者にとって中間的な容量が少なすぎたこと、そして、見かけ上の分布が観察者の分析単位に大きく依存するようにしたことである。管理上の判断は最初の境界で入り込んだ。歴史的な判断は 2 番目の境界で誤りうる。

ルーティングがより大きな単位を運用上魅力的にした

クラス B とクラス C のギャップは、ルーターが任意の隣接ネットワークを解釈を変えずに集約できれば、それほど重大ではなかっただろう。その期間の大半において、それはできなかった。

初期のアーキテクチャは、インターネットをクラスフルネットワークの階層として扱った。ゲートウェイはネットワーク部分に基づいてルーティングし、受信者にローカルアドレスフィールドの解釈を任せることができた。この配置は、1 つのネットワーク番号が 1 つの物理ネットワークまたは 1 つの組織に合理的に対応する場合には経済的であった。大学、企業、公共ネットワークが建物、LAN、ポイントツーポイント接続、内部ゲートウェイを蓄積するにつれて、維持が困難になった。

RFC 950 は、複数の LAN を持つ組織に対して 3 つの大まかな選択肢を説明した。すべてのケーブルに別個のインターネットネットワーク番号を取得する、いくつかの LAN を 1 つの透過的なネットワークに見せかける、あるいは、単一の割り当てられたネットワークをサブネットに分割する、というものである。

第 1 の選択肢は、シンプルなホスト実装を維持したが、ローカルな複雑さをグローバルルーティングシステムにエクスポートした。RFC 950 は、すべてのローカルネットワークをグローバルに伝播させると、ルーティング情報のためのスペースがほとんどないゲートウェイを含めて、ルーティングテーブルサイズの爆発を引き起こすと警告した。透過的なブリッジングは、追加のインターネットネットワーク番号を回避したが、独自のスケーリングと障害ドメインの制限をもたらした。サブネット化は、1 つの外部クラスフルネットワークに複数の内部ネットワークを含めることを可能にし、より高性能なローカル実装を犠牲にしてグローバルルーティングエントリを節約した。

サブネットの算術は、クラス B が成長するキャンパスにとって魅力的になった理由を示している。16 ビットのローカルフィールドのうち 6 ビットがサブネットに使用された場合、生の幾何学では 64 のサブネットパターンと各サブネット内に 1,024 のホストパターンが生成された。オールゼロとオールワンのサブネットパターンを除外する当時の慣習の下では、62 の通常サブネットが残った。通常のホスト除外を適用すると、サブネットあたり 1,022 のホスト値が残った。その積は次の通りである：

[62 \times 1,022 = 63,364]

その組織は、1 つの外部クラス B 番号の背後で数十の内部ネットワークを運用することができた。この配置は、小規模なキャンパスが当初必要とするよりもはるかに多くのアドレス値を使用したが、外部から見えるネットワーク番号を節約し、内部の成長のための余地を残した。

サブネット化はコストゼロではなかった。ホストとゲートウェイはマスクを理解する必要があった。ローカルフィールド内の既存の割り当ては、新たに選択されたサブネット境界と競合する可能性があった。ソフトウェアは、固定されたクラス境界以上のものを使用して、宛先がローカルかゲートウェイを必要とするかを判断しなければならなかった。

1989 年の運用ガイドRFC 1118は、互換性の問題を直接説明した。利用可能なソフトウェアの多く、特に 4.2BSD は、追加ソフトウェアなしではサブネット化されたアドレスを処理できなかったが、4.3BSD はリリース時点でサブネット化をサポートしていた。他のシステムは様々であった。ネットワークのサブネット化された部分の内部では、リーフとして機能できるがゲートウェイとして機能できないものもあった。

また、RFC 1118 はルーティングコストに具体的な規模を与えた。一部の重要なノードは、約 700 ネットワーク分の情報しか保存・交換できないと述べた。キャンパスには、個別のネットワーク番号を 2 つ以上アナウンスしないよう助言した。その制限を超えると予想されるサイトは、サブネット化を検討するよう指示された。

したがって、割り当て者のジレンマは単に「大きなブロックか小さなブロックか」ではなかった。それは、異なる場所で消費されるリソース間の選択であった：

クラス B は有限のアドレスプールの大部分を消費したが、外部ルーティングエントリを節約できた。
複数のクラス C は数値アドレス値を節約したが、経路とローカルな調整作業を追加する可能性があった。
サブネット化は外部状態を節約したが、互換性のある機器と運用能力を必要とした。
決定を延期することは、申請者がすぐに当初の割り当てを超えた場合、将来の再番号付けの労力も管理上の注意も節約しなかった。

ルーティング状態の増大により、このトレードオフはますます緊急なものとなった。RFC 1338は、Merit のシリーズを再現し、1988 年 7 月に 173、1989 年 7 月に 603、1992 年 2 月に 4,775 のアドバタイズされた経路を示した。1988 年 7 月から 1992 年 2 月までの完全な比較は次の通りである：

[4,775 / 173 = 27.601]

これは 43 か月で 27.601 倍の増加であった。より短い 1989 年 7 月から 1992 年 2 月までの比較は次の通りである：

[4,775 / 603 = 7.919]

これは 31 か月で 7.919 倍の増加であった。これらは異なる比較であり、組み合わせるべきではない。

RFC 1338 は、クラス B の代わりに 4〜16 のクラス C を割り当てることは、クラス B の枯渇を遅らせる可能性があるが、ドメイン間ルーティングプロトコルが任意のネットワークとマスクの集約を表現できない限り、ルーティングテーブルの成長を悪化させると論じた。したがって、提案された解決策は、新しい登録ルール以上のものに依存していた。ルーターとプロトコルは、古いクラス境界に適合しない情報を運ばなければならなかった。

今や 300 ホストの申請者は、もはや些細な算数の練習問題のようには見えない。2 つのクラス C は十分な当面の容量を提供したが、2 つの経路を必要とする可能性があった。1 つのクラス B は、65,536 の数値を予約しながら、外部表現を 1 つのネットワークに削減した。アーキテクチャが不連続性を作り出した。ルーティングと機器が相対的なコストを決定した。管理システムは不完全な選択肢を選ばなければならなかった。

初期の決定インターフェースは不完全なままである

RFC 791 はクラスの意味を説明したが、誰がそれを受け取るべきかを指定しなかった。その判断は、変化する制度と手続きのセットを通じて行われた。

1981 年 9 月、RFC 790は割り当て済みネットワーク番号を公開し、割り当ての要求を南カリフォルニア大学情報科学研究所の Jon Postel に送るよう指示した。レジストリは割り当て済み、予約済み、未割り当ての番号を示したが、クラス A、B、C を選択するための完全な一般的テストを公開しなかった。

1983 年 1 月までに、RFC 820はより精巧なポリシー環境を文書化した。割り当てを研究開発、防衛、商用に分類した。その付録は、1982 年 9 月に Defense Data Network プログラムオフィスと DARPA の間で合意された推奨事項を要約した。研究コミュニティに対して、推奨事項はネットワーク識別子の付与を、申請者が標準ゲートウェイソフトウェアを取得しているか、External Gateway Protocol 要件を満たすゲートウェイを実装している証拠に結びつけた。

その基準は適格性と運用準備態勢に関するものであり、完全なサイジングルールを提供するものではなかった。関連するネットワーク環境に参加する準備ができている申請者と、適切なゲートウェイ能力のない申請者を区別することはできたが、500 ホストを計画する資格のある組織が 2 つのクラス C を受け取るべきか、1 つのクラス B を受け取るべきかを管理者に指示するものではなかった。

また、RFC 820 は、意図された責任分担と実際の運用との間に実施上のギャップがあることを記録した。提案された分担は完全には実施されておらず、Postel が番号割り当ての調整役を続けた。正式な役割記述と日常的な取り扱いはまだ収束途上にあった。

制度的なアレンジはその 10 年間で変化した。Computer History Museum のGuide to the SRI ARC/NIC Recordsは、Assigned Numbers 管理とグローバル IP アドレス割り当てが USC-ISI から SRI NIC 契約に移管された時期を 1987 年としている。この検索手段は、要求記録を含む可能性のある通信や命名・アドレッシング資料を特定しているが、個々のクラス決定の背後にある理由を明らかにするものではない。

RFC 1118 は、1989 年に申請者向け手続きの公開説明を提供した。接続を予定しているネットワークは、[email protected]にメッセージを送り、接続アドレステンプレートを要求し、記入して返送するよう指示された。割り当てられたアドレスは、電子メールまたは郵便で返送される。このガイドは、残っているクラス A 番号はほとんどなく、実質的にはほとんどの申請者がクラス B とクラス C の間で選択しなければならないと付け加えた。

これにより、書式があり、返送経路があり、結果があったことが確認される。完成した書式を再現しておらず、特定のケースでどのフィールドが選択されたクラスを決定したかを示していない。手続きの説明は、要求-決定のデータセットではない。

University of Bristol に送られた現存する確認書も同様に限定的である。同大学は、1991 年 3 月 8 日付けで137.222.0.0（クラス B ネットワーク）をBRISTOL-NETに割り当てるメッセージを再現している。そこにはクラス、番号、技術連絡先、日付が特定されている。また、ホストテーブル登録、ブロードキャストアドレッシング、アドレス解決について受信者に助言している。

この確認書には、Bristol が提出した申請書、ホスト予測、サブネット計画、検討された代替案、ホストマスターからの質問、クラス B を選択した理由は含まれていない。それは結果を証明するものであり、管理者の決定ルールを証明するものではない。対応する要求と審議のない、1 つの応答である。

したがって、ここに集められた直接的な証拠は、完全な初期の要求-応答または要求-決定のペアを再構築するものではない。初期の管理者が実際に見たものについての主張は、仮説のままでなければならない。もっともらしい管理者は、予想されるホスト数、トポロジー、ゲートウェイ、ソフトウェア、接続性を考慮したかもしれない。これらの事項は運用上関連があり、公開ガイダンスにも現れていたからである。現存する資料は、それらすべてが特定の初期決定において提出されたり、重み付けされたりしたことを示してはいない。

完成した割り当て表は特に魅力的な証拠であるため、この区別は重要である。それらは承認後に記録されたものを示している。要求されたクラス、最初に提示されたサイズ、申請者の予測、拒否、縮小、遅延、提出されなかったニーズは示していない。完成した表から決定インターフェースを推論することは、結果を動機へと変えてしまうだろう。

1990 年 8 月、RFC 1174は制度上の役割をより正式に記述した。USC-ISI の IANA 機能は、数値識別子の割り当てと割り当てに関する中央権限を保持し、その責任の一部を委任する裁量権限も保持した。ネットワークおよび自律システム識別子の責任は、SRI International が DDN-NIC で運営する Internet Registry に委ねられていた。この文書は、国際的に承認された組織にブロックを委任しつつ、中央の IANA と Internet Registry 機能を維持することを推奨した。

これらの役割は混同すべきではない。IANA 機能、Internet Registry、NIC サービス、Internet Activities Board は、関連はあるが別個の立場を占めていた。IAB は勧告を発行した。IANA 機能は割り当てと委任の権限を有していた。Internet Registry は記録を収集・維持し、番号割り当てを処理した。申請者は通常、ホストマスターと返送された番号を通じてシステムに遭遇した。

RFC 1174 は、裁量と委任が 1990 年までに認識された制度的概念であったことを証明している。特定の 1983 年や 1991 年のケースで裁量がどのように行使されたかを証明するものではない。

申請者を捏造せずに分布を測定する

再現可能な測定は、同時期の公開されたスナップショットから構築できるが、その観測単位は狭く保たれなければならない。

ここで使用される単位は、引用されたソースによってカウントされた 1 つのクラスフルネットワーク番号単位である。それは組織、申請者、ルーティングされるプレフィックス、ホスト、現在の保有者、移転、経済的取引ではない。もしソースが、ある範囲に 1,024 のクラス C ネットワークを 1 つの名前に関連付けている場合、測定は 1,024 のクラスフル単位を数える。その範囲が 1,024 の受益者を表していると偽ることはない。

3 つの公開されたスナップショットが有用な比較点を提供する：

RFC 820 の 1983 年 1 月時点の割り当てられたクラス A、B、C ネットワーク番号の合計。
RFC 1166（1990 年 7 月発行）と、インターネットおよび独立使用のために割り当てられたネットワークの合計。
RFC 1466（1993 年 5 月発行）と、「ネットワーク番号統計（1992 年 5 月）」というラベルの付いた表。

予約済みおよび未割り当ての範囲、自律システム番号、マルチキャスト空間、実験クラスは除外されている。表される数値は、各ソースのカウントに(2^{24})、(2^{16})、または(2^8)を乗じて計算される。この計算では、受信者がローカルフィールドを異なる方法で構造化できるため、また、各クラスフル割り当てが包含する数値容量を測定することが目的であるため、ホスト、サブネット、ブロードキャストの予約は差し引かない。

1983 年 1 月の場合：

[(31 \times 16,777,216) + (24 \times 65,536) + (1,042 \times 256) = 521,933,312]

1990 年 7 月の場合：

[(34 \times 16,777,216) + (2,533 \times 65,536) + (16,214 \times 256) = 740,578,816]

1992 年 5 月統計の場合：

[(49 \times 16,777,216) + (7,354 \times 65,536) + (44,014 \times 256) = 1,315,302,912]

スナップショットとソース定義	クラス A ネットワーク数	クラス B ネットワーク数	クラス C ネットワーク数	クラスフルユニット合計	表される数値アドレス値	A の割合	B の割合	C の割合
1983 年 1 月、RFC 820 の割り当て合計	31	24	1,042	1,097	521,933,312	99.648%	0.301%	0.051%
1990 年 7 月、RFC 1166 のインターネットおよび独立割り当て	34	2,533	16,214	18,781	740,578,816	77.024%	22.415%	0.560%
RFC 1466 で再現された 1992 年 5 月統計	49	7,354	44,014	51,417	1,315,302,912	62.501%	36.642%	0.857%

クラス C ネットワークは、選択された 3 つのスナップショットすべてにおいて、ネットワーク番号単位数で支配的であった。それらは表される容量では支配的ではなかった。1983 年 1 月、31 のクラス A 割り当てが公表された合計の数値アドレス値の 99.648%を包含していた。1,042 のクラス C 単位は 0.051%を包含していた。

最初の行には重要な集中が含まれている。RFC 820 は、192.1.xxxから192.4.xxxまでの範囲を「BBN ローカルネットワーク」に関連付けた。それぞれの完全な第 2 オクテット値は 256 のクラス C ネットワーク番号をカバーしていた。したがって、4 つのそのような値は次の数をカバーした：

[4 \times 256 = 1,024]

これらの 1,024 単位は、1983 年 1 月の合計におけるクラス C カウントの 98.272553%を占めていた。それらの結合された数値容量は次の通りである：

[1,024 \times 256 = 262,144]

これは、生の数値容量で 4 つのクラス B ネットワークに等しかった：

[4 \times 65,536 = 262,144]

この範囲は、ネットワーク単位数を受益者数として読み取ることができない理由を示している。また、選択されたクラスが集約された数値容量の機械的な関数ではなかったことも示している。1 つの著名な組織が、単一の粗いブロックとしてではなく、小さなクラスフル単位の大規模な集合として現れる可能性がある。

公開された表は理由を述べていない。BBN ネットワークが別々にルーティングされていたのか、テストに使用されていたのか、異なるローカル環境のために予約されていたのか、あるいは他の技術計画の下で組織されていたのかを示していない。反実仮想で 4 つのクラス B に置き換えると、生の容量は保存されるが、トポロジー、実験、ルーティング動作、意図された管理構造は必ずしも保存されない。したがって、この範囲は、単純な 1 組織/1 クラスという読み方に対する反証であり、元の管理者の推論の証拠ではない。

また、RFC 820 には明らかな公開上の不規則性が含まれている。いくつかの防衛関連のクラス C の行では数値が繰り返されているが、合計は別個の単位として数えられている。他の場所では、一時的な番号、名前が変更されたネットワーク、移行エントリが現れている。したがって、ソース自身の合計は、目に見える行の単純なカウントよりも集計測定にとって安全である。それらはソースの定義に依存し続ける。

1990 年のスナップショットは異なる分母を導入する。RFC 1166 は、ARPA-Internet および DDN-Internet に割り当てられた 4,210 のネットワークと、インターネットおよび独立使用に割り当てられた 18,781 を別々に報告した。接続されたサブセットには 29 のクラス A、1,209 のクラス B、2,972 のクラス C が含まれていた。より広い割り当て合計には 34 のクラス A、2,533 のクラス B、16,214 のクラス C が含まれていた。

より広い合計は、独立したネットワークを含む、割り当てまたは配分された使用に置かれたグローバルに一意なクラスフル容量を測定するのに適切である。接続されたサブセットは、指定されたインターネット環境内のネットワークのカウントにより近い。どちらの合計も申請者数ではない。どちらも、却下または修正された要求の数を明らかにしない。

1992 年のソースは、スナップショットを誤って精密な連続系列に押し込むことに対して警告している。RFC 1338 は、DDN-NIC のnetwork-contacts.txtファイルの分析により、1992 年 2 月 25 日に 46 の割り当てられたクラス A と 5,467 の割り当てられたクラス B 番号が見つかったと報告した。RFC 1466 はその後、1992 年 5 月の合計として 49 と 7,354 を再現した。また、これら文書は異なるクラス B プールの分母を使用していた：RFC 1338 では 16,256、RFC 1466 では 16,383。

この差異全体を 3 か月間の割り当て急増と解釈するのは安全ではない。ファイル、フィルター、予約範囲の扱い、あるいは「割り当て済み」の意味が異なっていた可能性がある。日付付きの基礎ファイルとその変換ルールなしでは、この不一致は 2 つの合計だけから解決することはできない。当時の著者たちは急速な成長を明確に認識していたが、その認識が異なる測定値を交換可能にするわけではない。

受信者名は欠落した分母を修復しない

地理を割り当てることは、クラスカウントを掛け合わせるよりも困難である。初期のレジストリは、すべてのネットワークの横に標準的な国フィールドを提供していなかった。場所や機関を明示的に特定する名前もあれば、プロジェクト、実験システム、契約者、多国籍ネットワークを記述するものもあった。連絡先アドレスは、ネットワークが運用されていたすべての国を特定せずに、管理が行われた場所を特定することができた。

RFC 1166 のクラス A エントリには、英国の RSRE、カナダの CAN-INET、東京大学の連絡先を持つ JAPAN-A など、明らかに米国以外のケースが含まれていた。以前のレジストリには、University College London や大西洋横断パケット/衛星ネットワークが含まれていた。これは、大規模クラスの割り当てが専ら米国的であったという主張を否定するのに十分である。信頼できる国の割合を生成するには十分ではない。

大西洋横断衛星ネットワークは、単一の国への割り当てに抵抗する。企業は複数の法域で事業を行う可能性がある。プロジェクト名は、その元の機関の場所よりも長く存続する可能性がある。後のレジストリ記録は、合併、移管、再編、連絡先の変更を反映している可能性がある。現在の地理は、文書化された連鎖なしに元の受信者の地理として遡及的に投影することはできない。

また、名前は観測単位を変える。複数のエントリが 1 つの組織に属する場合もあれば、1 つのエントリが複数の組織や運用サイトをサポートする場合もある。BBN のクラス C 範囲は、1 つの名前の下に多数のネットワーク番号単位がある最も明確な例である。後の Merit によるネットワーク 35 の複数の自律システムにわたる使用は、逆の問題を示している：1 つのクラスフルネットワークが分散ルーティング配置に参加する可能性がある。

不成功の需要の不在はより深刻である。公開されたレジストリは、主に完了した割り当てを示している。申請者の全人口を開示していない。欠落している観測には以下が含まれる可能性がある：

追加情報のために差し戻された要求；
当初求められたよりも小さいクラスで許可された要求；
遅延または放棄された申請；
プロバイダーや他のレジストリに誘導された組織；
プライベートまたは非一意の番号付けを使用したネットワーク；
関連する手続きを知らなかった組織；
ゲートウェイ、接続性、機器の要件によって妨げられた申請者；
元の書式がもはや残っていない成功した受信者。

この分母なしでは、スナップショットは承認率、遅延、不平等なアクセス、申請者レベルの先行者利益を測定できない。技術的に類似した申請者が異なるクラスを受け取ったかどうかを示すことはできない。ある組織のエンジニアリング能力が成功をより可能性の高いものにしたことを立証することはできない。

データは、粗さ、集中、クラスフル単位の分布の変化を立証することができる。初期の永続的な割り当てが後の選択肢を維持する可能性があるメカニズムを特定できる。マッチした要求と結果なしに、そのメカニズムを測定された社会的効果に変換することはできない。

この限界は結論の文言を変える。「初期の受信者はより良いアクセスを持っていた」という主張には、比較可能な申請者に関する証拠が必要である。「管理者は有能な既存組織を優遇した」という主張には、決定と代替案に関する証拠が必要である。防御可能な主張は条件的である：もし組織が、より厳格な公開基準が確立される前に大規模な割り当てを受け取り、展開していたならば、再番号付けのコストにより、後の申請者が同じ条件で受け取ることができないかもしれない選択肢セットを保持することが可能になる。

これはもっともらしい経路依存性である。定量化された先行者配当ではない。

圧力が蓄積するにつれて公的基準が出現した

不完全な初期インターフェースを、すべての基準の不在と混同すべきではない。記録は、いくつかの初期の適格性ルールと、はるかに明示的な後の割り当てガイダンスを示している。

RFC 820 の研究基準は、番号割り当てをゲートウェイの準備態勢に結びつけた。また、実験ネットワークが運用可能になった場合の継続性を推奨した：再番号付けが困難を引き起こす場合、ネットワークは管理カテゴリーが変更される間もその識別子を保持できるとした。これは、展開がスイッチングコストを生み出すという明示的な認識であった。管理者が将来の市場価値を予期していたことを示すものではない。運用上、継続性がすでに重要であったことを示している。

1990 年までに、RFC 1174 は希少性という言葉を直接使用した。急速な成長と国際化により、さらなる委任が時宜にかなったものとなり、クラス A および B の識別子は、慎重な割り当てを必要とするますます希少な資源として記述された。この文書は、容量の懸念と管理上の懸念を結びつけた。グローバルな申請者人口は、まだ主に米国の機関に集中している機能に依存しており、ネットワークと記録の数は増加していた。

提案された対応は、中央権限の即時放棄ではなく、管理された分配であった。Internet Registry は、委任された権限が存在しない場合の主要なレジストリおよびデフォルトであり続ける。承認された組織はブロックと委任された責任を受け取ることができる。集約された登録データのコピーは配布されるが、更新は中央で維持される。

1992 年 10 月に発行されたRFC 1366は、方向性をより具体的なルールに変えた。候補となる地域レジストリは、それぞれの地理的領域で認識され、安定しており、適切なリソースを備え、共通の IANA および Internet Registry ガイドラインにコミットしていることが期待された。中央機能はクラス B 空間の責任を保持し、地域レジストリが評価を支援した。

クラス B について、RFC 1366 は 2 つの基準を述べた：32 以上のサブネットと 4,096 以上のホストを文書化したサブネット化計画である。クラス C のブロックが技術的に不適切な場合、ケースバイケースの検討を許可した。クラス C については、必要に応じたビット単位の連続ブロックと 24 か月の予測を提案した。

これらの基準はいくつかの要因を公にしつつ、判断の余地を残した。「32 以上のサブネット」は提案されたトポロジーに依存した。「4,096 以上のホスト」は、何をホストと数えるか、その数が現在の展開を表すのか、信頼できる成長を表すのかに依存した。技術的な不適切性は、自動的な計算ではなく説明を必要とした。

1992 年 8 月 1 日に発行された標準的な期間ソースRIPE-048は、発展途上の欧州のインターフェースを示している。RIPE NCC が欧州の組織からの要求を処理し、申請者は通常、IP サービスプロバイダーまたは RIPE NCC を通じて提供された資料を返送すると述べた。割り当てをプロバイダー関係や将来の外部接続性に結びつけた。

RIPE-048 は、クラス A および B 番号は希少であり、期待されるネットワークサイズと構造の観点からの正当化が必要であると述べた。クラス A 要求は詳細な技術的正当化と、数か月かかる可能性のあるグローバルレビューを必要とした。ネットワークがそのように設計できる場合、クラス B の代わりに合理的なクラス C のセットを使用するよう助言し、これがルーティングテーブルの制約によって動機づけられた以前の助言を覆すものであると明示した。

この文書は別の 1 ページのクラス B 情報シートに言及しているが、調査された RIPE-048 のテキストはそのシートを再現していない。したがって、予測ホスト、サブネット、使用率のフィールドの詳細なリストを RIPE-048 自体に帰属させるのは不適切である。直接的なサポートはより狭い：期待されるサイズと構造、プロバイダーまたは接続性の文脈、クラス C 適合性、クラス A の詳細な正当化、長期にわたるグローバルレビューの可能性。

1993 年 5 月に発行された RFC 1466 は、詳細なフィールドを直接提供している。クラス B 申請者は、32 以上のサブネットと 4,096 以上のホストを文書化することが期待された。エンジニアリング計画は、クラス C のブロックが不合理である理由を説明し、24 か月以内に期待されるホスト数とその期間内のサブネットあたりのホスト数を含める必要があった。計画は機密扱いとされ、申請が正当化されているかどうかを判断するために使用される。テストに不合格の申請者はクラス C ブロックを受け取り、例外も可能であった。

クラス C について、RFC 1466 は加入者の 24 か月予測に基づく連続割り当てラダーを確立した：

予測要件	デフォルト割り当て
256 アドレス未満	1 クラス C
512 未満	2 連続クラス C
1,024 未満	4 連続クラス C
2,048 未満	8 連続クラス C
4,096 未満	16 連続クラス C
8,192 未満	32 連続クラス C
16,384 未満	64 連続クラス C

これらの閾値は、冒頭の例で使用された 254 ホストの実用容量ではなく、アドレス要件を使用した。この区別は文書自身の割り当てラダーを反映しており、異なる慣習に黙って「修正」されるべきではない。

ポリシーはトポロジーのための調整を許可した。600 ホストを 10 の Ethernet に均等に分散している組織は、エンジニアリング計画で逸脱をサポートする場合、LAN ごとに 1 つずつ、10 のクラス C を受け取ることができた。また、レジストリは、クラス C ネットワークのサブネット化に失敗すると過剰なスペースを消費する場合、説明を要求することができた。

したがって、後期の決定インターフェースは初期のものよりも可視的であった。申請者は、ホスト総数、サブネット計画、24 か月の期間、クラス C 適合性が重要であることを知っていた。また、例外とレジストリの判断が残っていることも知っていた。変化は裁量から無裁量へではなく、薄い公的基準から構造化された裁量へであった。

境界事例が教訓物語を妨げる

集計測定は、その限界が無視されるならば、いくつかの単純化された物語を支持しうる。名前が挙げられた事例は、文書化されていない動機を明らかにするふりをせずに、それらの物語を弱めるので価値がある。

BBN の範囲は、著名な既存組織が常に 1 つの粗いクラスを受け取ったという命題に挑戦する。1983 年 1 月、「BBN ローカルネットワーク」はソースの合計における 1,042 のクラス C 単位のうち 1,024 を占めていた。4 つのクラス B は同じ生の数値容量を 4 つのクラスフル単位で提供できたであろう。しかし、レジストリは細かいクラスを大量に表示した。

これは、管理者が BBN に対して細かい粒度の割り当てを好んだことを証明するものではない。当初の論拠は存在しない。この範囲は、テスト、別個のローカルネットワーク、実験、または内部管理目的をサポートしていた可能性がある。そのメンバーがすべて独立したグローバル経路として現れたわけではないかもしれない。防御可能な発見は、機関の著名性が機械的に 1 つの大規模クラス割り当てにマッピングされたわけではないということだけである。

Bristol は別の主張に挑戦する。欧州の大学が、ルーティングの成長が明らかになり、詳細な 1992-1993 年の基準が発表される前の 1991 年 3 月 8 日にクラス B を受け取った。この確認は、中規模のレガシークラスが非米国の大学に対して閉ざされていたという絶対的な命題を否定する。

これは平等な扱いを立証するものではない。申請書は欠落しており、不成功の大学のマッチしたグループも存在しない。この事例は、そのような結果が生じたことを証明するが、どのくらいの頻度で、なぜ生じたかは証明しない。

Merit のネットワーク 35 は運用上の境界事例を提供する。RFC 1166 はネットワーク 35 をクラス A 割り当ての中にリストした。1993 年 7 月に発行されたRFC 1482は、NSFNET T3 バックボーン上で設定され、最大 6 つの自律システムからルーティングアナウンスが期待される可能性があることを示した。

その 1993 年の設定は、当初の割り当ての論拠を確立するものではない。単一のクラスフルネットワーク番号が、かなりのルーティング環境にわたって集約のような運用上の役割を後に果たすことができることを示している。アクティブなホスト数のみに基づく遡及的な利用率テストは、そのルーティング機能を省略してしまうだろう。

これらの事例は、テーゼを制約するものであり、証明するものではない。大規模な割り当ては必ずしも非合理的ではなかった。小さなネットワークの集合は、周辺的な申請者に限定されていなかった。非米国の大学は、クラス B からカテゴリカルに除外されていなかった。大規模なネットワーク番号は、ある瞬間に見えるホスト数を超えたルーティング上の役割を持つことができた。

ここでの反証は、普遍的な主張を取り除くことによって機能する。欠落した決定ファイルを提供するものではない。BBN、Bristol、Merit は、単純化された説明に対する境界事例として扱われるべきであり、管理者の当初の推論への窓としてではない。

4 つの圧力が異なる時計で現れた

希少性という言葉は、制約された資源が何であるかが明示されない限り、説明する以上に曖昧にしうる。

有限なアドレス空間の希少性は、境界のある 32 ビット空間、より直接的にはクラス A およびクラス B ネットワーク番号の限られた在庫に関係していた。クラス A は(2^{24})の数値ローカルアドレス値を包含し、当時のテーブルで認識されている約 126 の通常ネットワーク番号スロットのうちの 1 つを消費した。RFC 1466 は、そのポリシー定義の下では約 11 のクラス A 番号のみが未割り当てまたは未予約であると報告し、クラス A 空間の上半分を無期限に予約した。

ルーティング状態の希少性は、メモリ、処理、プロトコル更新、運用安定性に関係していた。数値アドレス空間の大部分が未割り当てのままでも、深刻化する可能性があった。個別に見える各クラス C は、ルーターのテーブルに宛先を追加する可能性がある。RFC 1118 のノードが約 700 ネットワークに制限されるという警告や、RFC 1338 のルーティングシリーズは、1 つのサブネット化されたクラス B が複数の小さなネットワークよりも運用上安価に見える理由を示している。

申請者レベルのニーズはまた異なっていた。300 ホストの組織は、IPv4 プール全体が豊富であるとは経験しなかった。利用可能な 1 つのクラスは通常ホストアドレスが 46 不足しており、次のクラスは必要よりもはるかに大きかった。2 つのクラス C は容量を解決したが、ルーティングと調整のコストをもたらす可能性があった。申請者の希少性は、適切に適合する割り当て単位の欠如であった。

管理上の注意は、書式を受け取り、質問をし、計画を評価し、記録を調整し、委任を調整し、決定を返す能力に関係していた。RFC 1174 は、さらなる委任を急速な成長と国際化に結びつけた。RFC 1466 は、需要が 2 年以内に大幅に増加し、割り当てにはより体系的なアプローチが必要であると述べた。RIPE-048 は、クラス A 要求のグローバルレビューに数か月かかる可能性があると警告した。

これらの圧力は一緒に動かなかった。理論的には数百万のクラス C ネットワーク番号が利用可能なままであっても、ルーティングテーブルは急速に成長する可能性があった。小さな申請者は、全体的な数値的枯渇が遠くにあっても、厳しいクラス境界に遭遇する可能性があった。中央レジストリは、個々の書式が簡単でも、増大するワークロードに直面する可能性があった。クラス B 番号を節約するように設計されたポリシーは、意図的に申請者により多くの機器またはルーティングコストを課す可能性があった。

この分離はまた、因果関係の近道を防ぐ。有限の 32 ビット空間の存在が特定の管理レジームを決定づけたわけではない。クラス設計が利用可能な単位を決定した。ルーティング制約がそれらの相対的な運用コストを変えた。管理機関が権限をどのように分配し、例外を評価するかを決定した。申請者は不完全な予測を提出し、どの要求を行うかを選択した。

希少性は 1 つの出来事ではなかった。それは不一致な制約のセットであった。

実現可能な代替案はすべてコストを伴った

当時の反実仮想は、当時利用可能なプロトコル、機器、制度で合理的に何ができたかを問うべきである。1981 年の管理者が、現代的な任意のプレフィックスをレジストリに書き込むことで問題を解決できたと仮定すべきではない。

1,000 の通常ホストを想定する組織を考えてみよう。4 つのクラス C は：

[4 \times 254 = 1,016]

の通常ホストアドレスを提供した。1 つのクラス B は 65,534 を提供した。アドレス節約の観点では、4 つのクラス C は劇的に優れていた。クラスフルルーティングシステムでは、それらは 4 つの外部から見えるネットワークエントリを必要とする可能性があった。RFC 1118 の、キャンパスが個別のネットワーク番号を 2 つ以上アナウンスしないよう助言したことは、1989 年までにそのコストを重要なものにした。

最初の実現可能な代替案は、複数のクラス C を割り当て、追加のネットワーク番号を受け入れることだった。これは新しいアドレス形式を必要としなかった。数値容量を節約し、サブネット化しない機器にも対応できた。そのコストには、追加の登録、設定、潜在的にグローバルな経路が含まれた。将来の成長は、別の要求または再番号付けを引き起こす可能性があった。

第 2 の代替案は、1 つのクラス B を割り当て、内部サブネット化を要求することだった。これは外部ルーティング状態を節約し、組織にかなりの成長余地を与えた。そのコストは、数値アドレス値のはるかに大きな予約と、サブネット対応ホストとゲートウェイへの依存であった。4.2BSD、4.3BSD、その他の実装が混在する期間では、互換性は管理上の虚構ではなく運用上の懸念であった。

第 3 の選択肢は、後の集約に備えて連続したクラス C を割り当てることだった。連続性は、ルーティングプロトコルとルーターが任意のネットワークとマスクの情報をサポートすれば、複数のネットワークを 1 つのプレフィックスとして表現する可能性を保持するのに役立った。そのようなサポートの前は、クラスフルシステムは依然としてコンポーネントを個々のクラス C ネットワークとして解釈した。連続性だけでルーティングエントリが消えるわけではなかった。

RFC 1338 はこの依存性を明示した。その提案された割り当て計画は、中規模組織に適切なサイズのクラス C ブロックを与えることができるが、ルーティングの利益はドメイン間プロトコルが任意のネットワーク+マスクの宛先を表現できることを必要とした。マルチホーム組織は依然としてより特定の広告を必要とする可能性があった。展開にはソフトウェアの変更、運用調整、NIC、IANA、サービスプロバイダー間の合意が必要だった。

より早期のサブネット化も実現可能な対応だったが、割り当てられたクラス内の内部トポロジーを解決した。付与されるクラスのサイズを縮小するものではなかった。サブネット化されたクラス B は依然として 65,536 の数値を 1 つの割り当ての下に置いた。無関係な組織の間でクラス A を分割するには、共有ルーティングと管理レイヤー、または元の 2 レベルアーキテクチャが提供しなかったクラスレス外部サポートが必要だっただろう。

透過的なブリッジングは、いくつかの LAN を 1 つのネットワークに見せかけることができるが、複雑さをより大きなリンク層ドメインに移した。障害、パフォーマンス、調整のコストを排除するものではなかった。ルーテッドサブネットの普遍的な代替ではなかった。

地域またはプロバイダーベースの委任は、アドレス形式を変えずに管理上の注意を分散させることができた。クラス C 番号のブロックを申請者により近い組織に委任することができた。これは通信経路を短縮し、現地語サービスを改善し、日常的なレビューを中央レジストリから移すことができた。

委任もコストを生み出した。中央と地域の機関は、一貫した記録、共通の基準、信頼できる更新手続きを必要とした。誰が、どの地域機関が正当性、資源、中立性を有するかを決定しなければならなかった。RFC 1366 と RFC 1466 は、委任が単なる郵便作業ではなく重要な権限を移転するため、これらの資格にかなりの注意を払った。

別の可能性は、より頻繁な再番号付けまたは回収を要求することだった。それは未使用容量を回復できたかもしれないが、ホスト、ゲートウェイ、アクセス制御、文書化、通信相手ネットワーク、運用スタッフにコストを課しただろう。RFC 820 の継続性の推奨は、再番号付けの困難がすでに認識されていたことを示している。それらのコストを無視するルールは、オペレーターに混乱をエクスポートすることでアドレス値を節約するだろう。

したがって、各代替案は希少性を異なる方法で価格付けした：

複数のクラス C はアドレス値を節約したが、経路と管理トランザクションを消費する可能性があった。
サブネット化されたクラス B は外部状態を節約したが、粗いアドレス単位を消費し、互換性のある機器を必要とした。
連続したクラス C は将来の集約オプションを保持したが、即時のクラスレスルーティングを提供しなかった。
地域委任はレビューを分散させたが、調整、正当性、記録の一貫性を必要とした。
再番号付けは運用の継続性を犠牲にして容量を回復した。

観察されたシステムは、技術的に可能な唯一のシステムではなかった。同時に最小化できないコストへの 1 つの対応であった。

何が変わり、何が持続し、何が推論できないか

証拠は因果関係の分割された割り当てを支持する。

クラスフル設計が不連続性を生み出した。32 ビットアドレスは他の方法で分割することもできたが、展開されたアーキテクチャは固定された A、B、C の境界を提供した。254 通常ホストをわずかに超える要件に対して、控えめな増加を提供するネイティブクラスは存在しなかった。それはプロトコルの特性だった。

ルーティングとハードウェアが不連続性を経済的および運用的に重要なものにした。複数のクラス C はアドレス値を節約しつつ、ネットワーク番号とルーティングの負担を増大させた。サブネット化されたクラス B は外部状態を節約しつつ、適切なソフトウェアを必要とし、はるかに大きな割り当てを消費した。これらは当時のエンジニアに見えていた制約だった。

管理ポリシーがシステムの対応を決定した。初期の公開資料には適格性とゲートウェイ準備態勢の基準が含まれていたが、完全なクラス選択インターフェースを再構築していない。1990 年から 1993 年までに、公的記録は希少性、委任、ホストとサブネットの閾値、24 か月予測、エンジニアリング計画、例外を明示的に議論した。判断は消滅することなく、より構造化された。

申請者レベルの結果は依然として決定不全である。利用可能なスナップショットは、完全な要求、拒否、代替案、利用率記録、決定説明を欠いている。技術的に有能な申請者が一般的に優れたアクセスを享受したことや、管理者が組織的に既存組織を優遇したことを立証できない。また、大規模な初期割り当てがすべてのケースで正当化されたことも立証できない。

スナップショットは、もっともらしい経路依存性のメカニズムを示している。受信者が割り当てを展開すると、再番号付けはコストを課した。RFC 820 は、実験ネットワークが運用可能になった場合に番号を保持する理由として困難を明示的に認識した。したがって、大規模な初期割り当ては、同等の新規割り当ての基準が厳しくなった後も維持されうる。

その利益は、測定された配当ではなくオプションとして記述されるべきである。受信者は内部的に拡張し、クラスフルな宛先を提示し続け、再番号付けをより少なくし、後の取得が困難になった容量を保持することができた。特定の受信者がそれらのオプションを使用したか、それらに値したか、後の重要性を予期したかは別の経験的問いである。

現代の証拠は、初期の動機を解決せずに持続性を確認する。報告された IPv4 移転の 2017 年の研究は、レガシー空間がその報告された移転サンプルにおけるアドレス空間の 63.82%を占めることを発見した。同じ研究は、後の記録が慎重に解釈されなければならない理由を示した：ルーティングの変更は、販売ではなく、プロバイダーの変更、再割り当て、組織再編、複雑なアドレス管理を反映しうる。

その結果は狭いチェックとしてのみ関連する。レジストリ時代以前の割り当てが、後の再分配に実質的に関与するのに十分長く持続したことを示している。1983 年にクラスが選択された理由、元の申請者が正確な予測を提供したか、割り当てが公正であったか、初期の管理者が何を意図したかは示していない。

現在の金銭的価値は、初期の決定からさらに離れている。レガシーブロック内のすべてのアドレスに現在の価格を適用すると、ルーティングされていない空間、ポリシー制限、取引コスト、断片化、運用上の依存関係、登録と管理の区別が無視されるだろう。より重要なことに、後の希少性を当時の動機に置き換えることになる。

したがって、歴史的な結論は境界があるが結果的である。クラスフル IPv4 は、技術的な粒度を管理上の決定境界に変換した。ルーティング制限は時としてより大きな単位を防御可能にした。機器制限は時としてサブネット化をコスト高にした。初期の申請者と管理者は、完成したレジストリからはもはや再構築できない予測で操作した。後のポリシーはバランスの基準をより明示的にし、作業を地域およびプロバイダーベースの機関にシフトさせた。

管理上の希少性は 254 と 65,534 の間のギャップで生まれたが、そのギャップが 1 つの答えを決定づけたからではない。利用可能なすべての答えが異なる当事者やシステムにコストを課し、誰かがどのコストを受け入れるかを決定しなければならなかったために、それは生まれた。

クラスフルアドレス時代と管理上の希少性の誕生

概要