Die Ära der klassenbasierten Adressierung und die Geburt der administrativen Knappheit

Zusammenfassung

• Ein Netzwerk, das 300 normale Host-Adressen benötigte, überschritt die praktische Kapazität eines Klasse‑C‑Netzwerks von 254 um 46 Adressen. Die nächste native Klasse bot 65.534 normale Host-Adressen, während zwei Klasse‑C‑Netzwerke 508 boten – möglicherweise auf Kosten einer zusätzlichen Route und mehr Koordinationsaufwands. Die klassenbasierte Geometrie machte die Zuteilung daher zu einer Wahl zwischen ungleichen Kosten und nicht zu einem einfachen Ablesen des Host-Bedarfs.
• Drei zeitgenössische Momentaufnahmen zeigen, dass die Anzahl der zugewiesenen Netzwerknummer-Einheiten von Klasse‑C‑Netzwerken dominiert wurde, während die repräsentierte Adresskapazität von Klasse‑A‑Zuweisungen dominiert wurde. Im Januar 1983 repräsentierten 31 Klasse‑A‑Zuweisungen 99,648 Prozent der von den veröffentlichten Gesamtzahlen abgedeckten numerischen Adresswerte; 1.042 Klasse‑C‑Netzwerke repräsentierten 0,051 Prozent.
• Das erhaltene Material bietet keine abgeglichene Stichprobe früher Anträge, Ablehnungen und Entscheidungen. Es kann keinen allgemeinen First-Mover-Effekt, ungleichen Zugang für Antragsteller oder die bei einer bestimmten frühen Klassenentscheidung verwendeten Kriterien belegen. Es stützt eine engere Schlussfolgerung: Dauerhafte Zuteilungen, die vor der Explizierung späterer Kriterien vorgenommen wurden, könnten einen plausiblen pfadabhängigen Optionsvorteil schaffen.
• Adressraumknappheit, das Wachstum des Routing-Status, das Dimensionierungsproblem eines einzelnen Antragstellers und begrenzte administrative Aufmerksamkeit waren separate Beschränkungen. Sie traten zu unterschiedlichen Zeiten auf und wiesen oft auf unterschiedliche Zuteilungsentscheidungen hin.
• Mehrere Klasse‑C‑Netzwerke, Subnetting, zusammenhängende Blöcke und regionale Delegation waren praktikable Alternativen der Zeit, aber jede verursachte Routing‑, Hardware‑, Koordinations‑ oder Verwaltungskosten. Ein faires kontrafaktisches Szenario kann nicht annehmen, dass klassenloses Routing während der gesamten 1980er Jahre verfügbar war.

Ein Netzwerkplaner, der mit 300 normalen Hosts rechnete, stieß auf eine präzise Diskontinuität. Ein Klasse‑C‑Netzwerk enthielt 256 mögliche Werte in seinem 8‑Bit‑Feld für die lokale Adresse. Unter den später präzisierten Beschränkungen für Host-Werte, die nur aus Nullen (all-zero) oder nur aus Einsen (all-one) bestehen, stellte es 254 normale Host-Adressen bereit. Der Bedarf lag somit 46 Adressen über einem Klasse‑C‑Netzwerk, nicht zwei. Die Zahl zwei beschreibt die Differenz zwischen 256 numerischen Werten und 254 normalen Host-Adressen; sie beschreibt nicht den Fehlbetrag gegenüber einem Plan mit 300 Hosts.

Zwei Klasse‑C‑Netzwerke konnten den unmittelbaren Bedarf mit 508 normalen Host-Adressen decken. Dennoch blieben es zwei klassenbasierte Netzwerke, die potenziell zwei extern sichtbare Routing-Einträge, zwei Registrierungen und zusätzliche lokale Koordination erforderten. Die nächste native Klasse, Klasse B, stellte 65.536 numerische Werte für die lokale Adresse bzw. 65.534 normale Host-Adressen bereit. Das war etwa das 258,008‑fache der praktischen Host-Kapazität eines Klasse‑C‑Netzwerks und mehr als das 218‑fache des genannten Bedarfs von 300 Hosts.

Das Protokoll enthielt keine Zwischenklasse. Es entschied nicht, ob die Schonung von Adresswerten wichtiger war als die Schonung des Routing-Status, ob die Hardware der Organisation sicheres Subnetting betreiben konnte, ob zwei kleinere Netzwerke ohne Störung koordiniert werden konnten oder wie viel Wachstum berücksichtigt werden sollte. Diese Fragen mussten außerhalb des Bitmusters gelöst werden.

An diesem Punkt wurde technische Granularität zu administrativer Knappheit. Knappheit begann nicht erst, als sich der verbleibende Pool der Erschöpfung näherte. Sie trat auch immer dann auf, wenn der Bedarf eines Antragstellers in die weite Lücke zwischen den verfügbaren Einheiten fiel und ein Administrator entscheiden musste, welche Kosten das Zuteilungssystem tragen würde.

Die Geometrie schuf eine Entscheidungsgrenze

RFC 791, der im September 1981 veröffentlicht wurde, definierte eine Internet-Adresse als vier Oktette oder 32 Bits. Seine höchstwertigen Bits wählten eines von drei normalen Adressformaten aus und legten damit die Aufteilung zwischen der Netzwerknummer und der lokalen Adresse fest.

Die Slash-Notation ist nur als moderne Übersetzung der festen Klassengrenzen enthalten. Sie sollte nicht rückwirkend als Beleg dafür gelesen werden, dass ein Administrator 1981 eine beliebige Präfixlänge zuweisen konnte. Ein Klasse‑B‑Netzwerk war kein Punkt in einem kontinuierlichen Menü. Seine führenden Bits wiesen klassenbasierte Implementierungen an, die ersten beiden Oktette als Netzwerkteil zu behandeln. Ein Klasse‑C‑Netzwerk legte die Grenze nach drei Oktetten fest. Das System bot nativ keine global routbare Zuteilung auf halbem Wege dazwischen an.

Das numerische Kapazitätsverhältnis von einer Klasse zur nächsten betrug exakt 256. Ein Klasse‑A‑Netzwerk enthielt (2^{24}) lokale Adresswerte, ein Klasse‑B‑Netzwerk (2^{16}) und ein Klasse‑C‑Netzwerk (2^8). Nach Ausschluss der normalen Werte, die nur aus Nullen oder nur aus Einsen bestehen, waren die praktischen Verhältnisse geringfügig größer:

• (16.777.214 / 65.534 = 256.007782) Klasse‑B‑Netze pro Klasse‑A‑Netz.
• (65.534 / 254 = 258.007874) Klasse‑C‑Netze pro Klasse‑B‑Netz.

Diese Ausschlüsse müssen historisch eingeordnet werden. RFC 791 legte die Klassengeometrie fest, veröffentlichte jedoch keine moderne Tabelle nutzbarer Hosts. Der 1985 herausgegebeneRFC 950erläuterte die besondere Bedeutung von Null- und All-Eins-Feldern im Kontext von Subnetting und Broadcasts.RFC 1122stellte 1989 fest, dass Host‑, Netzwerk- und Subnetzfelder außer in definierten Sonderfällen keine Werte annehmen durften, die nur aus Nullen oder nur aus Einsen bestehen.

Für den Vergleich von Zuteilungen sind die gesamten numerischen Werte das am wenigsten annahmenabhängige Maß: (2^{24}), (2^{16}) oder (2^8) pro Netzwerk. Um das Problem der normalen Host-Kapazität eines Antragstellers unter den später präzisierten Regeln nachzuvollziehen, sind die bekannten Minus‑zwei‑Zahlen angemessen. Werden diese beiden Maße vermischt, führt dies zu irreführenden Aussagen, wie das 300‑Host‑Beispiel zeigt.

Die höchstwertigen Muster teilten zudem den gesamten 32‑Bit‑Raum ungleichmäßig auf. Adressen, die mit0begannen, belegten die Hälfte aller Bitfolgen. Das Muster10belegte ein Viertel. Das Muster110belegte ein Achtel. Die verbleibenden höchstwertigen Muster wurden reserviert oder für andere Zwecke entwickelt, einschließlich Multicast und Experimenten. So kontrollierte eine kleine Anzahl von Klasse‑A‑Netzwerknummern einen enormen Teil des numerischen Adressraums, während das viel größere Inventar an Klasse‑C‑Netzwerknummern einen kleineren Bruchteil einnahm.

Diese Unterscheidung zwischen Netzwerknummer-Einheiten und repräsentierter Kapazität ist grundlegend. Ein Register konnte Tausende von Klasse‑C‑Einträgen und nur wenige Dutzend Klasse‑A‑Einträge enthalten, sodass Klasse C als Arbeitslast zu dominieren schien. Dasselbe Register, gemessen an numerischen Adresswerten, konnte überwältigend in Klasse A konzentriert sein. Kein Nenner ist grundsätzlich falsch. Sie beantworten unterschiedliche Fragen.

Die Anzahl der Netzwerknummern nähert an, wie viele klassenbasierte Einheiten registriert und, sofern extern sichtbar, geroutet werden mussten. Die repräsentierte Kapazität misst, wie viele Adresswerte sich innerhalb der aufgeführten Zuteilungen befanden. Keines von beiden ist eine Anzahl von Antragstellern. Keines misst aktive Hosts, Auslastung, Routing-Sichtbarkeit, organisatorisches Eigentum oder wirtschaftlichen Wert.

Die klassenbasierte Architektur erzeugte daher gleichzeitig zwei Formen von Grobheit. Sie bot zu wenige Zwischenkapazitäten für Antragsteller und machte die scheinbare Verteilung stark von der Analyseeinheit des Betrachters abhängig. Administratives Urteilsvermögen setzte an der ersten Grenze ein. Historisches Urteilsvermögen kann an der zweiten fehlgehen.

Routing machte die größere Einheit betrieblich attraktiv

Die Lücke zwischen Klasse B und Klasse C wäre weniger folgenreich gewesen, wenn Router beliebige angrenzende Netzwerke hätten aggregieren können, ohne deren Interpretation zu ändern. Während eines großen Teils dieser Zeit war dies nicht möglich.

Die ursprüngliche Architektur behandelte das Internet als Hierarchie klassenbasierter Netzwerke. Ein Gateway konnte anhand des Netzwerkteils routen und überließ es dem Empfänger, das lokale Adressfeld zu interpretieren. Diese Anordnung war wirtschaftlich, solange eine Netzwerknummer einigermaßen genau einem physischen Netzwerk oder einer Organisation entsprach. Sie wurde schwieriger aufrechtzuerhalten, als Universitäten, Unternehmen und öffentliche Netzwerke Gebäude, lokale Netzwerke (LANs), Punkt-zu-Punkt-Verbindungen und interne Gateways anhäuften.

RFC 950 beschrieb drei grobe Optionen für eine Organisation mit mehreren LANs: Sie konnte für jedes Kabel eine eigene Internet-Netzwerknummer beantragen. Sie konnte mehrere LANs als ein transparentes Netzwerk erscheinen lassen. Oder sie konnte ein einzelnes zugewiesenes Netzwerk in Subnetze unterteilen.

Die erste Option bewahrte einfache Host-Implementierungen, exportierte aber lokale Komplexität in das globale Routing-System. RFC 950 warnte, dass die globale Verbreitung jedes lokalen Netzwerks zu einer Explosion der Routing-Tabellengröße führen würde, auch auf Gateways mit wenig Speicherplatz für Routing-Informationen. Transparentes Bridging vermied zusätzliche Internet-Netzwerknummern, brachte aber eigene Einschränkungen hinsichtlich Skalierung und Fehlerdomänen mit sich.

Subnetting erlaubte es einem externen klassenbasierten Netzwerk, mehrere interne Netzwerke zu enthalten, wodurch globale Routing-Einträge auf Kosten leistungsfähigerer lokaler Implementierungen eingespart wurden.

Die Subnetz-Arithmetik veranschaulicht, warum Klasse B für einen wachsenden Campus attraktiv wurde. Wenn sechs Bits seines 16‑Bit‑Lokalfeldes für Subnetze verwendet wurden, ergab die reine Geometrie 64 Subnetzmuster und 1.024 Hostmuster pro Subnetz. Nach der damaligen Konvention, die die Nur-Null- und Nur-Eins-Subnetzmuster ausschloss, blieben 62 normale Subnetze übrig. Die Anwendung der normalen Host-Ausschlüsse ließ 1.022 Host-Werte pro Subnetz übrig. Das Produkt war:

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

Diese Organisation konnte Dutzende interner Netzwerke hinter einer externen Klasse‑B‑Nummer betreiben. Die Anordnung nutzte weit mehr Adresswerte, als ein kleiner Campus anfänglich benötigte, sparte aber an extern sichtbaren Netzwerknummern und ließ Raum für internes Wachstum.

Subnetting war nicht kostenlos. Hosts und Gateways mussten Masken verstehen. Bestehende Zuweisungen innerhalb des lokalen Feldes konnten mit einer neu gewählten Subnetzgrenze kollidieren. Software musste entscheiden, ob ein Ziel lokal war oder ein Gateway erforderte, und zwar unter Verwendung von mehr als der festen Klassengrenze.

Der BetriebsleitfadenRFC 1118von 1989 beschrieb das Kompatibilitätsproblem direkt: Viel verfügbare Software, insbesondere 4.2BSD, konnte subnettierte Adressen ohne zusätzliche Software nicht verarbeiten, während 4.3BSD Subnetting in der veröffentlichten Version unterstützte. Andere Systeme variierten. Einige konnten als Endknoten, aber nicht als Gateways in einem subnettierten Teil des Netzwerks fungieren.

RFC 1118 gab zudem den Routing-Kosten eine konkrete Dimension. Es hieß, dass einige wichtige Knoten Informationen nur für etwa 700 Netzwerke speichern und austauschen könnten. Einem Campus wurde geraten, nicht mehr als zwei diskrete Netzwerknummern anzukündigen. Einem Standort, der diese Grenze voraussichtlich überschreiten würde, wurde nahegelegt, Subnetting in Betracht zu ziehen.

Das Dilemma des Zuteilers war daher nicht einfach „großer Block versus kleiner Block“. Es war eine Wahl zwischen Ressourcen, die an unterschiedlichen Stellen verbraucht wurden:

• Ein Klasse‑B‑Netz verbrauchte einen großen Teil des endlichen Adresspools, konnte aber externe Routing-Einträge einsparen.
• Mehrere Klasse‑C‑Netze schonten numerische Adresswerte, konnten aber Routen und lokalen Koordinationsaufwand hinzufügen.
• Subnetting schonte externen Zustand, erforderte aber kompatible Ausrüstung und betriebliche Kompetenz.
• Das Aufschieben der Entscheidung sparte weder zukünftigen Umnummerierungsaufwand noch administrative Aufmerksamkeit, falls der Antragsteller bald über die anfängliche Zuteilung hinauswuchs.

Das Wachstum des Routing-Status machte den Zielkonflikt zunehmend dringlicher.RFC 1338gab eine Merit-Reihe wieder, die 173 angekündigte Routen im Juli 1988, 603 im Juli 1989 und 4.775 im Februar 1992 zeigte. Der vollständige Vergleich von Juli 1988 bis Februar 1992 war:

[4,775 / 173 = 27.601]

Das war eine Zunahme um den Faktor 27,601 über 43 Monate. Der kürzere Vergleich von Juli 1989 bis Februar 1992 war:

[4,775 / 603 = 7.919]

Das war eine Zunahme um den Faktor 7,919 über 31 Monate. Dies sind unterschiedliche Vergleiche und sollten nicht kombiniert werden.

RFC 1338 argumentierte, dass die Zuteilung von vier bis sechzehn Klasse‑C‑Netzen anstelle eines Klasse‑B‑Netzes die Erschöpfung der Klasse‑B‑Adressen verlangsamen, aber das Wachstum der Routing-Tabellen verschlechtern könne, es sei denn, Inter-Domain-Routing-Protokolle könnten beliebige Netzwerk-plus-Maske-Aggregate darstellen. Die vorgeschlagene Abhilfe hing daher von mehr ab als nur von einer neuen Registrierungsregel. Router und Protokolle mussten Informationen übertragen, die nicht in die alten Klassengrenzen passten.

Der Antragsteller mit 300 Hosts erscheint nun weniger wie eine triviale Rechenaufgabe. Zwei Klasse‑C‑Netze boten ausreichende unmittelbare Kapazität, konnten aber zwei Routen erfordern. Ein Klasse‑B‑Netz reduzierte die externe Darstellung auf ein Netzwerk, reservierte jedoch 65.536 numerische Werte. Die Architektur schuf die Diskontinuität. Routing und Ausrüstung bestimmten die relativen Kosten. Das administrative System musste eine unvollkommene Option wählen.

Die frühe Entscheidungsschnittstelle bleibt unvollständig

RFC 791 erklärte, was eine Klasse bedeutete. Er legte nicht fest, wer eine erhalten sollte. Diese Entscheidung durchlief einen sich wandelnden Satz von Institutionen und Verfahren.

Im September 1981 veröffentlichteRFC 790zugewiesene Netzwerknummern und verwies Zuteilungsanträge an Jon Postel am Information Sciences Institute der University of Southern California. Das Register zeigte zugewiesene, reservierte und nicht zugewiesene Nummern, veröffentlichte jedoch keinen vollständigen allgemeinen Test für die Wahl zwischen den Klassen A, B und C.

Bis Januar 1983 dokumentierteRFC 820ein detaillierteres Richtlinienumfeld. Er kennzeichnete Zuteilungen als Forschung und Entwicklung, Verteidigung oder kommerziell. Sein Anhang fasste Empfehlungen zusammen, die zwischen dem Programmbitro des Defense Data Network und DARPA im September 1982 vereinbart worden waren. Für die Forschungsgemeinschaft verknüpften die Empfehlungen die Vergabe von Netzwerkkennungen mit dem Nachweis, dass der Antragsteller Standard-Gateway-Software beschaffte oder ein Gateway implementierte, das den Anforderungen des External Gateway Protocol entsprach.

Dieses Kriterium betraf die Berechtigung und die Betriebsbereitschaft. Es lieferte keine vollständige Dimensionierungsregel. Es konnte einen Antragsteller, der bereit war, an der betreffenden Netzwerkumgebung teilzunehmen, von einem ohne geeignete Gateway-Fähigkeit unterscheiden, sagte einem Administrator jedoch nicht, ob eine qualifizierte Organisation, die 500 Hosts plante, zwei Klasse‑C‑Netze oder ein Klasse‑B‑Netz erhalten sollte.

RFC 820 hielt auch eine Implementierungslücke zwischen der beabsichtigten Aufgabenteilung und dem tatsächlichen Betrieb fest. Die vorgeschlagene Aufteilung war nicht vollständig umgesetzt worden, und Postel blieb der Koordinator für Nummernzuteilungen. Formelle Rollenbeschreibungen und die tägliche Handhabung näherten sich erst noch einander an.

Das institutionelle Gefüge veränderte sich im Laufe des Jahrzehnts. DerGuide to the SRI ARC/NIC Recordsdes Computer History Museum datiert die Übertragung der Verwaltung der Assigned Numbers und der globalen IP-Adressvergabe von USC-ISI an den SRI-NIC-Vertrag auf 1987. Das Findmittel weist Korrespondenz und Namens- und Adressierungsmaterial aus, das Antragsunterlagen enthalten könnte, gibt jedoch selbst keinen Aufschluss über die Gründe für eine einzelne Klassenentscheidung.

RFC 1118 lieferte 1989 eine öffentliche Beschreibung des antragstellerseitigen Verfahrens. Einem potenziellen angeschlossenen Netzwerk wurde mitgeteilt, eine Nachricht an[email protected]zu senden, die Vorlage für die Connected-Address anzufordern, sie auszufüllen und zurückzusenden. Die zugewiesene Adresse würde dann elektronisch oder per Post zurückgesandt. Der Leitfaden fügte hinzu, dass nur noch wenige Klasse‑A‑Nummern übrig seien und dass die meisten Antragsteller praktisch zwischen Klasse B und Klasse C wählen müssten.

Dies belegt, dass es ein Formular, einen Rückkanal und ein Ergebnis gab. Es gibt die ausgefüllten Formulare nicht wieder und zeigt nicht, welche Felder in einem bestimmten Fall die ausgewählte Klasse bestimmten. Eine Verfahrensbeschreibung ist kein Datensatz von Anträgen und Entscheidungen.

Die erhaltene Bestätigung an die University of Bristol ist ähnlich begrenzt. Die Universität gibt eine Nachricht vom 8. März 1991 wieder, die137.222.0.0, ein Klasse‑B‑Netz, anBRISTOL-NETzuweist. Sie nennt Klasse, Nummer, technischen Ansprechpartner und Datum. Sie berät den Empfänger auch zur Host-Tabellen-Registrierung, Broadcast-Adressierung und Adressauflösung.

Die Bestätigung enthält weder den eingereichten Antrag Bristols, noch die Host-Prognose, den Subnetzplan, erwogene Alternativen, vom Hostmaster gestellte Fragen oder Gründe für die Wahl der Klasse B. Sie beweist ein Ergebnis, nicht die Entscheidungsregel des Administrators. Sie ist eine Antwort ohne den zugehörigen Antrag und die dazugehörige Abwägung.

Das hier zusammengestellte direkte Beweismaterial rekonstruiert daher kein vollständiges frühes Antrag-Antwort- oder Antrag-Entscheidungs-Paar. Behauptungen darüber, was ein früher Administrator tatsächlich sah, müssen Hypothesen bleiben. Ein plausibler Administrator könnte die erwarteten Hosts, die Topologie, Gateways, Software und Konnektivität berücksichtigt haben, da diese Aspekte betrieblich relevant waren und in den öffentlichen Leitlinien auftauchten. Das erhaltene Material belegt nicht, dass all dies in einer bestimmten frühen Entscheidung vorgelegt oder gewichtet wurde.

Diese Unterscheidung ist wichtig, weil abgeschlossene Zuteilungstabellen besonders verlockende Beweise sind. Sie zeigen, was nach der Genehmigung aufgezeichnet wurde. Sie zeigen weder die beantragte Klasse, die zuerst angebotene Größe, die Prognose eines Antragstellers, eine Ablehnung, eine Kürzung, eine Verzögerung noch einen nicht eingereichten Bedarf. Die Entscheidungsschnittstelle aus der abgeschlossenen Tabelle abzuleiten, würde Ergebnisse in Motive verwandeln.

Im August 1990 beschriebRFC 1174die institutionellen Rollen formeller. Die IANA-Funktion bei USC-ISI behielt die zentrale Befugnis, numerische Kennungen zuzuteilen und zuzuweisen, sowie die Ermessensbefugnis, Teile dieser Verantwortung zu delegieren. Die Zuständigkeit für Netz- und Autonomous-System-Kennungen war beim Internet Registry angesiedelt, das von SRI International am DDN-NIC betrieben wurde. Das Dokument empfahl, die zentralen IANA- und Internet-Registry-Funktionen beizubehalten und gleichzeitig Blöcke an zugelassene Organisationen international zu delegieren.

Diese Rollen sollten nicht vermischt werden. Die IANA-Funktion, das Internet Registry, der NIC-Dienst und das Internet Activities Board nahmen verwandte, aber unterschiedliche Positionen ein. Das IAB gab Empfehlungen heraus. Die IANA-Funktion besaß die Zuteilungs- und Delegationsbefugnis. Das Internet Registry sammelte und pflegte Aufzeichnungen und bearbeitete Nummernzuteilungen. Der Antragsteller traf normalerweise über einen Hostmaster und eine zurückgesandte Nummer auf das System.

RFC 1174 belegt, dass Ermessen und Delegation bis 1990 anerkannte institutionelle Konzepte waren. Er beweist nicht, wie das Ermessen in einem bestimmten Fall von 1983 oder 1991 ausgeübt wurde.

Die Verteilung messen, ohne Antragsteller zu erfinden

Eine reproduzierbare Messung kann aus zeitgenössischen veröffentlichten Momentaufnahmen konstruiert werden, sofern die Beobachtungseinheit eng bleibt.

Die hier verwendete Einheit ist eine klassenbasierte Netzwerknummer-Einheit, wie sie von der zitierten Quelle gezählt wird. Sie ist weder eine Organisation, ein Antragsteller, ein geroutetes Präfix, ein Host, ein derzeitiger Inhaber, eine Übertragung noch eine wirtschaftliche Transaktion. Wenn eine Quelle einen Bereich, der 1.024 Klasse‑C‑Netze umfasst, mit einem Namen verknüpft, zählt die Messung 1.024 klassenbasierte Einheiten. Sie gibt nicht vor, dass der Bereich 1.024 Begünstigte repräsentiert.

Drei veröffentlichte Momentaufnahmen bieten nützliche Vergleichspunkte:

1. Die Gesamtzahlen von RFC 820 vom Januar 1983 für zugewiesene Klasse‑A‑, ‑B- und ‑C-Netzwerknummern.
2. RFC 1166, veröffentlicht im Juli 1990, und seine Gesamtzahlen für Netzwerke, die für Internet- und unabhängige Nutzungen zugewiesen wurden.
3. RFC 1466, veröffentlicht im Mai 1993, und seine Tabelle mit der Bezeichnung „Network Number Statistics (May 1992).”

Reservierte und nicht zugewiesene Bereiche, Autonomous-System-Nummern, Multicast-Bereiche und experimentelle Klassen sind ausgeschlossen. Die repräsentierten numerischen Werte werden berechnet, indem jede Quellenzählung mit (2^{24}), (2^{16}) oder (2^8) multipliziert wird. Die Berechnung zieht keine Host‑, Subnetz- oder Broadcast-Reservierungen ab, da die Empfänger ihre lokalen Felder unterschiedlich strukturieren konnten und da der Zweck darin besteht, die numerische Kapazität zu messen, die jede klassenbasierte Zuteilung umfasst.

Für Januar 1983: [(31 × 16.777.216) + (24 × 65.536) + (1.042 × 256) = 521.933.312]

Für Juli 1990: [(34 × 16.777.216) + (2.533 × 65.536) + (16.214 × 256) = 740.578.816]

Für die Statistik vom Mai 1992: [(49 × 16.777.216) + (7.354 × 65.536) + (44.014 × 256) = 1.315.302.912]

Klasse‑C‑Netzwerke dominierten in allen drei ausgewählten Momentaufnahmen die Anzahl der Netzwerknummer-Einheiten. Sie dominierten nicht die repräsentierte Kapazität. Im Januar 1983 umfassten 31 Klasse‑A‑Zuweisungen 99,648 Prozent der numerischen Adresswerte in den veröffentlichten Gesamtzahlen. Die 1.042 Klasse‑C‑Einheiten umfassten 0,051 Prozent.

Die erste Zeile enthält eine wichtige Konzentration. RFC 820 verband den Bereich von192.1.xxxbis192.4.xxxmit „BBN local networks“. Jeder vollständige Wert des zweiten Oktetts umfasste 256 Klasse‑C‑Netzwerknummern. Vier solcher Werte umfassten daher: [4 × 256 = 1,024]

Diese 1.024 Einheiten machten [1,024 / 1,042 = 98,272553%] der Klasse‑C‑Zählung in der Gesamtzahl vom Januar 1983 aus. Ihre kombinierte numerische Kapazität betrug [1,024 × 256 = 262,144]. Das entsprach vier Klasse‑B‑Netzwerken in roher numerischer Kapazität: [4 × 65,536 = 262,144]

Der Bereich zeigt, warum Netzwerkeinheiten-Zählungen nicht als Zählungen von Begünstigten gelesen werden können. Er zeigt auch, dass die gewählte Klasse keine mechanische Funktion der aggregierten numerischen Kapazität war. Eine prominente Organisation konnte als große Ansammlung kleiner klassenbasierter Einheiten erscheinen und nicht als ein einzelner grober Block.

Die veröffentlichte Tabelle sagt nicht, warum. Sie zeigt nicht, ob die BBN-Netzwerke separat geroutet, für Tests verwendet, für verschiedene lokale Umgebungen reserviert oder nach einem anderen technischen Plan organisiert waren. Das Ersetzen durch vier Klasse‑B‑Netze in einem kontrafaktischen Szenario bewahrt die rohe Kapazität, aber nicht notwendigerweise die Topologie, die Experimentierumgebung, das Routing-Verhalten oder die beabsichtigte Verwaltungsstruktur. Der Bereich ist daher ein Beleg gegen eine vereinfachende Lesart von einer Organisation pro Klasse und kein Beleg für die Überlegungen des ursprünglichen Administrators.

RFC 820 enthält auch offensichtliche Unregelmäßigkeiten in der Veröffentlichung. Mehrere Verteidigungs-Klasse‑C‑Zeilen wiederholen einen numerischen Wert, während die Gesamtzahlen unterschiedliche Einheiten zählen. Temporäre Nummern, umbenannte Netzwerke und Übergangseinträge erscheinen an anderer Stelle. Die eigenen Gesamtzahlen der Quelle sind daher für aggregierte Messungen sicherer als eine naive Zählung der sichtbaren Zeilen. Sie bleiben von den Definitionen der Quelle abhängig.

Die Momentaufnahme von 1990 führt einen anderen Nenner ein. RFC 1166 berichtete separat über 4.210 Netzwerke, die für das ARPA-Internet und DDN-Internet zugewiesen waren, und 18.781, die für Internet- und unabhängige Nutzungen zugeteilt waren. Die angeschlossene Teilmenge umfasste 29 Klasse‑A‑, 1.209 Klasse‑B‑ und 2.972 Klasse‑C‑Netze. Die breitere Zuteilungsgesamtzahl enthielt 34 Klasse‑A‑, 2.533 Klasse‑B‑ und 16.214 Klasse‑C‑Netze.

Die breitere Gesamtzahl ist geeignet, um die weltweit eindeutige klassenbasierte Kapazität zu messen, die in zugewiesene oder zugeteilte Nutzung gegeben wurde, einschließlich unabhängiger Netzwerke. Die angeschlossene Teilmenge kommt einer Zählung von Netzwerken innerhalb der spezifizierten Internet-Umgebungen näher. Keine der beiden Gesamtzahlen ist eine Antragstellerzählung. Keine zeigt, wie viele Anträge abgelehnt oder überarbeitet wurden.

Die Quellen von 1992 warnen davor, die Momentaufnahmen in eine trügerisch präzise kontinuierliche Reihe zu pressen. RFC 1338 berichtete, dass eine Analyse der Dateinetwork-contacts.txtdes DDN-NIC am 25. Februar 1992 46 zugewiesene Klasse‑A‑ und 5.467 zugewiesene Klasse‑B‑Nummern ergab. RFC 1466 gab später die Gesamtzahlen vom Mai 1992 mit 49 und 7.354 wieder. Die Dokumente verwendeten auch unterschiedliche Nenner für den Klasse‑B‑Pool: 16.256 in RFC 1338 und 16.383 in RFC 1466.

Es wäre unsicher, die gesamte Differenz als einen Zuteilungsschub von drei Monaten zu interpretieren. Die Dateien, Filter, die Behandlung reservierter Bereiche oder die Bedeutung von „zugewiesen“ könnten sich unterschieden haben. Ohne die datierten zugrunde liegenden Dateien und ihre Transformationsregeln kann die Diskrepanz nicht allein aus den beiden Gesamtzahlen aufgelöst werden. Die zeitgenössischen Autoren nahmen eindeutig ein schnelles Wachstum wahr, aber diese Wahrnehmung macht unterschiedliche Messungen nicht austauschbar.

Empfängernamen reparieren den fehlenden Nenner nicht

Die Zuweisung einer Geografie ist schwieriger als das Multiplizieren von Klassenzahlen. Die frühen Register enthielten kein Standard-Länderfeld neben jedem Netzwerk. Einige Namen identifizierten explizit einen Ort oder eine Institution. Andere beschrieben ein Projekt, ein experimentelles System, einen Auftragnehmer oder ein transnationales Netzwerk. Eine Kontaktadresse konnte angeben, wo die Verwaltung stattfand, ohne jedes Land zu identifizieren, in dem das Netzwerk betrieben wurde.

Die Klasse‑A‑Einträge von RFC 1166 enthielten eindeutig nicht-amerikanische Fälle, darunter RSRE im Vereinigten Königreich, CAN-INET in Kanada und JAPAN-A mit einem Kontakt an der University of Tokyo. Frühere Register enthielten das University College London und transatlantische Paket- oder Satellitennetzwerke. Dies reicht aus, um die Behauptung zurückzuweisen, dass Zuweisungen großer Klassen ausschließlich amerikanisch waren. Es reicht nicht aus, um einen verlässlichen Länderprozentsatz zu ermitteln.

Ein transatlantisches Satellitennetzwerk widersetzt sich der Zuweisung zu einem einzelnen Land. Ein Unternehmen kann in mehreren Rechtsordnungen tätig sein. Ein Projektname kann seinen ursprünglichen institutionellen Standort überdauern. Spätere Registereinträge können Fusionen, Übertragungen, Umstrukturierungen oder geänderte Kontakte widerspiegeln. Die heutige Geografie kann nicht ohne eine dokumentierte Kette rückwirkend als die ursprüngliche Geografie des Empfängers projiziert werden.

Namen ändern auch die Beobachtungseinheit. Mehrere Einträge können zu einer Organisation gehören; ein Eintrag kann mehrere Organisationen oder Betriebsstandorte unterstützen. Der BBN-Klasse‑C‑Bereich ist das klarste Beispiel für viele Netzwerknummer-Einheiten unter einem Namen. Merits spätere Nutzung von Netzwerk 35 über mehrere autonome Systeme hinweg veranschaulicht das umgekehrte Problem: Ein klassenbasiertes Netzwerk konnte an einer verteilten Routing-Anordnung teilnehmen.

Das Fehlen erfolgloser Nachfrage ist schwerwiegender. Veröffentlichte Register zeigen überwiegend abgeschlossene Zuweisungen. Sie geben nicht die gesamte Population der Antragsteller preis. Fehlende Beobachtungen können umfassen:

• Anträge, die zur Vervollständigung zurückgesandt wurden;
• Anträge, die in einer kleineren Klasse als ursprünglich beantragt bewilligt wurden;
• verzögerte oder aufgegebene Anträge;
• Organisationen, die an einen Anbieter oder ein anderes Register verwiesen wurden;
• Netzwerke, die private oder nicht eindeutige Nummerierung verwendeten;
• Organisationen, die das entsprechende Verfahren nicht kannten;
• Antragsteller, die durch Gateway‑, Konnektivitäts- oder Ausrüstungsanforderungen abgeschreckt wurden;
• erfolgreiche Empfänger, deren Originalformulare nicht mehr erhalten sind.

Ohne diesen Nenner können die Momentaufnahmen keine Bewilligungsquoten, Verzögerungen, ungleichen Zugang oder First-Mover-Vorteile auf Antragstellerebene messen. Sie können nicht zeigen, ob technisch ähnliche Antragsteller unterschiedliche Klassen erhielten. Sie können nicht belegen, dass die Engineering-Kapazität einer Organisation den Erfolg wahrscheinlicher machte.

Die Daten können Grobheit, Konzentration und die sich verändernde Verteilung klassenbasierter Einheiten belegen. Sie können einen Mechanismus identifizieren, durch den dauerhafte frühe Zuteilungen spätere Optionen bewahren könnten. Sie können diesen Mechanismus jedoch nicht ohne abgeglichene Anträge und Ergebnisse in einen gemessenen sozialen Effekt umwandeln.

Diese Grenze verändert die Sprache der Schlussfolgerung. „Frühe Empfänger hatten besseren Zugang“ würde Belege über vergleichbare Antragsteller erfordern. „Administratoren bevorzugten fähige etablierte Akteure“ würde Belege über Entscheidungen und Alternativen erfordern. Die vertretbare Behauptung ist konditional: Wenn eine Organisation eine große Zuteilung erhielt und einsetzte, bevor strengere veröffentlichte Kriterien galten, könnten die Kosten der Umnummerierung es ihr erlauben, einen Optionssatz zu behalten, den ein späterer Antragsteller zu denselben Bedingungen möglicherweise nicht erhalten würde.

Das ist plausible Pfadabhängigkeit. Es ist keine quantifizierte First-Mover-Dividende.

Öffentliche Kriterien entstanden mit zunehmendem Druck

Die unvollständige frühe Schnittstelle sollte nicht mit dem Fehlen jeglicher Kriterien verwechselt werden. Die Aufzeichnungen zeigen einige frühe Berechtigungsregeln und viel explizitere spätere Zuteilungsrichtlinien.

Das Forschungskriterium von RFC 820 verknüpfte die Nummernzuteilung mit der Gateway-Bereitschaft. Es empfahl auch Kontinuität, wenn ein experimentelles Netzwerk in den Betrieb überging: Wenn eine Umnummerierung Härten verursachte, konnte das Netzwerk seine Kennung behalten, während seine Verwaltungskategorie wechselte. Dies war eine explizite Anerkennung, dass die Bereitstellung Wechselkosten verursachte. Es zeigt nicht, dass Administratoren einen zukünftigen Marktwert antizipierten. Es zeigt, dass Kontinuität betrieblich bereits von Bedeutung war.

Bis 1990 verwendete RFC 1174 direkt die Sprache der Knappheit. Schnelles Wachstum und Internationalisierung machten eine weitere Delegation zeitgemäß, und Klasse‑A‑ und ‑B‑Kennungen wurden als zunehmend knappe Ressourcen beschrieben, die eine sorgfältige Zuteilung erforderten. Das Dokument verband ein Kapazitätsproblem mit einem administrativen Problem. Eine globale Antragstellerpopulation war von Funktionen abhängig, die noch immer in US-amerikanischen Institutionen angesiedelt waren, während die Zahl der Netzwerke und Aufzeichnungen zunahm.

Die vorgeschlagene Antwort war eine kontrollierte Verteilung statt einer sofortigen Aufgabe der zentralen Autorität. Das Internet Registry würde das Hauptregister bleiben und als Standard dienen, wo keine delegierte Autorität existierte. Zugelassene Organisationen konnten Blöcke und delegierte Verantwortung erhalten. Kopien aggregierter Registrierungsdaten würden verteilt, während Aktualisierungen zentralisiert blieben.

Im Oktober 1992 setzteRFC 1366die Richtung in spezifischere Regeln um. Von Kandidaten für regionale Registries wurde erwartet, dass sie in ihren geografischen Gebieten anerkannt, stabil, angemessen ausgestattet und den gemeinsamen IANA- und Internet-Registry-Richtlinien verpflichtet waren. Die zentralen Funktionen behielten die Verantwortung für den Klasse‑B‑Raum, wobei die regionalen Registries bei der Bewertung halfen.

Für Klasse B nannte RFC 1366 zwei Kriterien: einen Subnetting-Plan, der mehr als 32 Subnetze und mehr als 4.096 Hosts dokumentierte. Er erlaubte eine Einzelfallprüfung, wenn ein Block von Klasse‑C‑Netzen technisch ungeeignet war. Für Klasse C schlug er bitweise zusammenhängende Blöcke vor, die nach Bedarf und einer 24‑Monats-Prognose dimensioniert waren.

Die Kriterien machten einige Faktoren öffentlich, ließen aber Raum für Ermessen. „Mehr als 32 Subnetze“ hing von einer vorgeschlagenen Topologie ab. „Mehr als 4.096 Hosts“ hing davon ab, was als Host zählte und ob die Zahl den aktuellen Einsatz oder ein glaubhaftes Wachstum beschrieb. Technische Nichteignung erforderte eine Erklärung und keine automatische Berechnung.

Die kanonische Quelle der Zeit, das am 1. August 1992 veröffentlichteRIPE-048, zeigt die sich entwickelnde europäische Schnittstelle. Es hieß, dass das RIPE NCC Anträge von europäischen Organisationen bearbeite und dass Antragsteller die bereitgestellten Unterlagen in der Regel über einen IP-Service-Provider oder das RIPE NCC zurücksenden würden. Es verknüpfte die Zuteilung mit Provider-Beziehungen und der voraussichtlichen externen Konnektivität.

RIPE-048 stellte fest, dass Klasse‑A‑ und ‑B‑Nummern knapp seien und eine Begründung hinsichtlich der erwarteten Netzwerkgröße und -struktur erforderten. Ein Klasse‑A‑Antrag erforderte eine detaillierte technische Begründung und eine globale Prüfung, die mehrere Monate dauern konnte. Es riet, eine angemessene Anzahl von Klasse‑C‑Netzen anstelle eines Klasse‑B‑Netzes zu verwenden, wenn das Netzwerk auf diese Weise konstruiert werden konnte, wobei ausdrücklich darauf hingewiesen wurde, dass dies frühere, durch Routing-Tabellen-Beschränkungen motivierte Ratschläge umkehrte.

Das Dokument verwies auf ein separates einseitiges Klasse‑B‑Informationsblatt, aber der eingesehene RIPE-048-Text gibt dieses Blatt nicht wieder. Es wäre daher unangemessen, eine detaillierte Liste von Feldern wie projizierte Hosts, Subnetze und Auslastung RIPE-048 selbst zuzuschreiben. Die direkte Unterstützung ist enger: erwartete Größe und Struktur, Provider- oder Konnektivitätskontext, Eignung von Klasse C, detaillierte Begründung für Klasse A und die Möglichkeit einer langwierigen globalen Prüfung.

RFC 1466, veröffentlicht im Mai 1993, liefert die detaillierten Felder direkt. Von einem Klasse‑B‑Antragsteller wurde erwartet, dass er mehr als 32 Subnetze und mehr als 4.096 Hosts dokumentierte. Der Engineering-Plan musste erklären, warum ein Block von Klasse‑C‑Netzen unvernünftig war, und die innerhalb von 24 Monaten erwartete Anzahl von Hosts sowie die Anzahl der Hosts pro Subnetz in diesem Zeitraum enthalten. Die Pläne sollten vertraulich bleiben und zur Beurteilung dienen, ob der Antrag gerechtfertigt war. Ein Antragsteller, der den Test nicht bestand, würde einen Klasse‑C‑Block erhalten, während Ausnahmen möglich blieben.

Für Klasse C legte RFC 1466 eine Leiter für zusammenhängende Zuteilungen fest, die auf der 24‑Monats-Prognose des Antragstellers basierte:

Diese Schwellenwerte verwendeten Adressanforderungen und nicht die praktische Kapazität von 254 Hosts aus dem Eingangsbeispiel. Diese Unterscheidung spiegelt die eigene Zuteilungsleiter des Dokuments wider und sollte nicht stillschweigend in eine andere Konvention „korrigiert“ werden.

Die Richtlinie erlaubte eine Anpassung an die Topologie. Eine Organisation mit 600 Hosts, die gleichmäßig auf zehn Ethernets verteilt waren, konnte zehn Klasse‑C‑Netze, eines pro LAN, erhalten, wenn sie die Abweichung mit einem Engineering-Plan begründete. Registries konnten auch eine Erklärung verlangen, wenn der Verzicht auf Subnetting von Klasse‑C‑Netzen übermäßig viel Platz verbrauchen würde.

Die Entscheidungsschnittstelle der späten Zeit war daher sichtbarer als die frühe. Antragsteller wussten, dass Host-Gesamtzahlen, Subnetzpläne, ein 24‑Monats‑Horizont und die Eignung für Klasse C von Bedeutung waren. Sie wussten auch, dass Ausnahmen und das Ermessen der Registry bestehen blieben. Der Wandel ging nicht von Ermessen zu keinem Ermessen. Er ging von dünnen öffentlichen Kriterien zu strukturiertem Ermessen.

Grenzfälle verhindern eine Moralerzählung

Die aggregierten Messungen können mehrere vereinfachende Geschichten stützen, wenn ihre Grenzen ignoriert werden. Die genannten Fälle sind wertvoll, weil sie diese Geschichten abschwächen, ohne vorzugeben, undokumentierte Motive aufzudecken.

Der BBN-Bereich stellt die Behauptung infrage, dass prominente etablierte Akteure ausnahmslos eine grobe Klasse erhielten. Im Januar 1983 entfielen 1.024 der 1.042 Klasse‑C‑Einheiten in der Quellengesamtzahl auf „BBN local networks“. Vier Klasse‑B‑Netze hätten mit vier klassenbasierten Einheiten dieselbe rohe numerische Kapazität bereitgestellt. Dennoch zeigte das Register die feine Klasse in großer Zahl.

Dies beweist nicht, dass Administratoren eine feinkörnige Zuteilung für BBN bevorzugten. Die ursprüngliche Begründung fehlt. Der Bereich könnte Tests, separate lokale Netzwerke, Experimente oder interne Verwaltungszwecke unterstützt haben. Seine Mitglieder sind möglicherweise nicht alle als unabhängige globale Routen erschienen. Die vertretbare Feststellung ist einfach, dass institutionelle Prominenz nicht mechanisch auf eine Zuweisung einer großen Klasse abgebildet wurde.

Bristol stellt eine andere Behauptung infrage. Eine europäische Universität erhielt am 8. März 1991 ein Klasse‑B‑Netz, nachdem das Routing-Wachstum offensichtlich war und bevor die detaillierten Kriterien von 1992–1993 veröffentlicht wurden. Die Bestätigung schließt die absolute Behauptung aus, dass mittelgroße Legacy-Klassen für nicht-amerikanische Universitäten geschlossen waren.

Sie belegt keine Gleichbehandlung. Der Antrag fehlt, und es gibt keine abgeglichene Gruppe erfolgloser Universitäten. Der Fall beweist, dass ein solches Ergebnis vorkam, nicht wie oft oder warum.

Merits Netzwerk 35 liefert einen betrieblichen Grenzfall. RFC 1166 führte Netzwerk 35 unter den Klasse‑A‑Zuteilungen auf.RFC 1482, veröffentlicht im Juli 1993, zeigte es so auf dem NSFNET-T3-Backbone konfiguriert, dass Routing-Ankündigungen von bis zu sechs autonomen Systemen erwartet werden konnten.

Diese Konfiguration von 1993 belegt nicht die Gründe für die ursprüngliche Zuteilung. Sie zeigt jedoch, dass eine einzelne klassenbasierte Netzwerknummer später eine aggregationsähnliche betriebliche Rolle in einer umfangreichen gerouteten Umgebung spielen konnte. Ein rückblickender Auslastungstest, der ausschließlich auf der Anzahl aktiver Hosts basiert, würde diese Routing-Funktion außer Acht lassen.

Diese Fälle schränken die These ein, anstatt sie zu beweisen. Große Zuteilungen waren nicht notwendigerweise irrational. Sammlungen kleiner Netzwerke waren nicht auf randständige Antragsteller beschränkt. Nicht-amerikanische Universitäten waren nicht kategorisch von Klasse B ausgeschlossen. Eine große Netzwerknummer konnte eine Routing-Rolle über die zu einem Zeitpunkt sichtbare Anzahl von Hosts hinaus haben.

Falsifikation funktioniert hier durch die Beseitigung universeller Behauptungen. Sie liefert nicht die fehlenden Entscheidungsakten. BBN, Bristol und Merit sollten als Grenzfälle gegen vereinfachende Erklärungen behandelt werden, nicht als Fenster in die ursprünglichen Überlegungen des Administrators.

Vier Belastungen traten auf unterschiedlichen Zeitskalen auf

Das Wort Knappheit kann mehr verschleiern als erklären, solange die beschränkte Ressource nicht benannt wird.

Die Endlichkeit des Adressraums betraf den begrenzten 32‑Bit‑Raum und, unmittelbarer, die begrenzten Vorräte an Klasse‑A‑ und Klasse‑B‑Netzwerknummern. Ein Klasse‑A‑Netz umfasste (2^{24}) numerische lokale Adresswerte und verbrauchte einen von ungefähr 126 normalen Netzwerknummer-Plätzen, die in den damaligen Tabellen anerkannt waren. RFC 1466 meldete nur etwa 11 Klasse‑A‑Nummern als nicht zugewiesen oder nicht reserviert gemäß seinen Richtliniendefinitionen und reservierte die obere Hälfte des Klasse‑A‑Raums auf unbestimmte Zeit.

Die Knappheit des Routing-Status betraf Speicher, Verarbeitung, Protokollaktualisierungen und Betriebsstabilität. Sie konnte akut werden, während große Teile des numerischen Adressraums noch nicht zugewiesen waren. Jedes separat sichtbare Klasse‑C‑Netz konnte ein Ziel zur Tabelle eines Routers hinzufügen. Die Warnung von RFC 1118 vor Knoten, die auf etwa 700 Netzwerke beschränkt waren, und die Routing-Reihe von RFC 1338 zeigen, warum ein subnettiertes Klasse‑B‑Netz betrieblich günstiger erscheinen konnte als mehrere kleinere Netzwerke.

Der Bedarf auf Antragstellerebene war wiederum anders. Die 300‑Host‑Organisation erlebte den gesamten IPv4‑Pool nicht als reichlich. Sie erlebte eine verfügbare Klasse als 46 normale Host-Adressen zu klein und die nächste als bei Weitem größer als benötigt. Zwei Klasse‑C‑Netze lösten die Kapazität, führten aber möglicherweise Routing- und Koordinationskosten ein. Die Knappheit des Antragstellers war das Fehlen einer passenden Zuteilungseinheit.

Administrative Aufmerksamkeit betraf die Fähigkeit, Formulare entgegenzunehmen, Fragen zu stellen, Pläne zu bewerten, Aufzeichnungen abzugleichen, Delegationen zu koordinieren und Entscheidungen zurückzusenden. RFC 1174 verknüpfte weitere Delegation mit schnellem Wachstum und Internationalisierung. RFC 1466 stellte fest, dass die Nachfrage innerhalb von zwei Jahren erheblich zugenommen hatte und dass die Zuteilung einen systematischeren Ansatz erforderte. RIPE-048 warnte, dass die globale Prüfung eines Klasse‑A‑Antrags mehrere Monate dauern könne.

Diese Belastungen bewegten sich nicht im Gleichklang. Routing-Tabellen konnten schnell wachsen, obwohl theoretisch Millionen von Klasse‑C‑Netzwerknummern verfügbar blieben. Ein kleiner Antragsteller konnte auf eine harte Klassengrenze stoßen, während die vollständige numerische Erschöpfung noch in weiter Ferne lag. Ein zentrales Register konnte eine zunehmende Arbeitslast haben, selbst wenn jedes einzelne Formular einfach war. Eine Richtlinie, die Klasse‑B‑Nummern schonen sollte, konnte Antragstellern bewusst höhere Ausrüstungs- oder Routing-Kosten auferlegen.

Die Trennung verhindert auch kausale Abkürzungen. Die Existenz eines endlichen 32‑Bit‑Raums diktierte kein bestimmtes Verwaltungsregime. Das Klassendesign bestimmte die verfügbaren Einheiten. Routing-Beschränkungen veränderten ihre relativen betrieblichen Kosten. Administrative Institutionen entschieden, wie sie Autorität verteilten und Ausnahmen bewerteten. Antragsteller lieferten unvollständige Prognosen und wählten, welche Anträge sie stellten.

Knappheit war kein einzelnes Ereignis. Sie war ein Satz nicht zusammenpassender Beschränkungen.

Die praktikablen Alternativen trugen alle Kosten

Ein kontrafaktisches Szenario der Zeit sollte fragen, was mit den damals verfügbaren Protokollen, Geräten und Institutionen vernünftigerweise hätte getan werden können. Es sollte nicht annehmen, dass ein Administrator 1981 das Problem hätte lösen können, indem er ein modernes beliebiges Präfix in ein Register schrieb.

Man betrachte eine Organisation, die 1.000 normale Hosts erwartete. Vier Klasse‑C‑Netze boten: [4 × 254 = 1,016] normale Host-Adressen. Ein Klasse‑B‑Netz bot 65.534. In Bezug auf die Adressschonung waren vier Klasse‑C‑Netze dramatisch besser. In einem klassenbasierten Routing-System konnten sie vier extern sichtbare Netzwerkeinträge erfordern. Der Rat von RFC 1118, dass ein Campus nicht mehr als zwei diskrete Netzwerke ankündigen solle, machte diese Kosten bis 1989 materiell.

Die erste praktikable Alternative bestand darin, mehrere Klasse‑C‑Netze zuzuteilen und die zusätzlichen Netzwerknummern in Kauf zu nehmen. Dies erforderte kein neues Adressformat. Es schonte die numerische Kapazität und konnte Geräte aufnehmen, die kein Subnetting beherrschten. Zu den Kosten gehörten zusätzliche Registrierung, Konfiguration und potenziell globale Routen. Zukünftiges Wachstum konnte einen weiteren Antrag oder eine Umnummerierung auslösen.

Die zweite Alternative bestand darin, ein Klasse‑B‑Netz zuzuteilen und internes Subnetting zu verlangen. Dies schonte den externen Routing-Status und gab der Organisation erheblichen Raum für Wachstum. Ihre Kosten waren eine viel größere Reservierung numerischer Adresswerte und die Abhängigkeit von subnettierungsfähigen Hosts und Gateways. In einer Zeit gemischter 4.2BSD‑, 4.3BSD- und anderer Implementierungen war Kompatibilität ein betriebliches Problem und keine administrative Fiktion.

Eine dritte Option bestand darin, zusammenhängende Klasse‑C‑Netze zuzuteilen, um eine spätere Aggregation vorzubereiten. Zusammenhängigkeit half, die Möglichkeit zu bewahren, mehrere Netzwerke als ein Präfix darzustellen, sobald Routing-Protokolle und Router beliebige Netzwerk-und-Maske-Informationen unterstützten. Vor einer solchen Unterstützung interpretierte das klassenbasierte System die Komponenten immer noch als einzelne Klasse‑C‑Netzwerke. Zusammenhängigkeit allein ließ die Routing-Einträge nicht verschwinden.

RFC 1338 machte diese Abhängigkeit explizit. Sein vorgeschlagener Zuteilungsplan konnte mittleren Organisationen angemessen dimensionierte Klasse‑C‑Blöcke geben, aber der Routing-Vorteil erforderte, dass Inter-Domain-Protokolle beliebige Netzwerk-plus-Maske-Ziele darstellen konnten. Multihomed-Organisationen benötigten möglicherweise dennoch spezifischere Ankündigungen. Die Bereitstellung erforderte Softwareänderungen, betriebliche Koordination und Einvernehmen zwischen dem NIC, der IANA und den Service-Providern.

Früheres Subnetting war eine weitere praktikable Antwort, aber es löste die interne Topologie innerhalb einer zugewiesenen Klasse. Es verringerte nicht die Größe der gewährten Klasse. Ein subnettiertes Klasse‑B‑Netz stellte immer noch 65.536 numerische Werte unter eine Zuteilung. Ein Klasse‑A‑Netz unter nicht verwandten Organisationen aufzuteilen, hätte eine gemeinsame Routing- und Administrationsschicht oder klassenlose externe Unterstützung erfordert, die die ursprüngliche zweistufige Architektur nicht bot.

Transparentes Bridging konnte mehrere LANs als ein Netzwerk erscheinen lassen, aber es verlagerte die Komplexität in eine größere Verbindungsschicht-Domäne. Es beseitigte weder Ausfall‑, Leistungs- noch Koordinationskosten. Es war kein universeller Ersatz für geroutete Subnetze.

Regionale oder anbieterbasierte Delegation konnte die administrative Aufmerksamkeit verteilen, ohne das Adressformat zu ändern. Blöcke von Klasse‑C‑Nummern konnten an Organisationen delegiert werden, die den Antragstellern näher standen. Dies konnte die Kommunikationswege verkürzen, den Dienst in der Landessprache verbessern und die Routineprüfung vom zentralen Register wegbewegen.

Delegation verursachte ebenfalls Kosten. Die zentralen und regionalen Stellen benötigten konsistente Aufzeichnungen, gemeinsame Kriterien und zuverlässige Aktualisierungsverfahren. Jemand musste entscheiden, welche regionale Institution Legitimität, Ressourcen und Neutralität besaß. RFC 1366 und RFC 1466 widmeten diesen Qualifikationen erhebliche Aufmerksamkeit, weil die Delegation folgenreiche Autorität und nicht nur Postarbeit übertrug.

Eine weitere Möglichkeit bestand darin, häufigere Umnummerierung oder Rückforderung zu verlangen. Das hätte ungenutzte Kapazität zurückgewinnen können, aber es hätte Kosten für Hosts, Gateways, Zugangskontrollen, Dokumentation, Korrespondenznetzwerke und Betriebspersonal verursacht. Die Kontinuitätsempfehlung von RFC 820 zeigt, dass die Härten der Umnummerierung bereits anerkannt waren. Eine Regel, die diese Kosten ignorierte, würde Adresswerte schonen, indem sie Störungen auf die Betreiber abwälzte.

Jede Alternative bepreiste die Knappheit daher unterschiedlich:

• Mehrere Klasse‑C‑Netze schonten Adresswerte, konnten aber Routen und administrative Transaktionen verbrauchen.
• Ein subnettiertes Klasse‑B‑Netz schonte externen Zustand, verbrauchte aber eine grobe Adresseinheit und erforderte kompatible Ausrüstung.
• Zusammenhängende Klasse‑C‑Netze bewahrten zukünftige Aggregationsoptionen, boten aber kein sofortiges klassenloses Routing.
• Regionale Delegation verteilte die Prüfung, erforderte aber Koordination, Legitimität und Aufzeichnungskonsistenz.
• Umnummerierung gewann Kapazität zurück auf Kosten der Betriebskontinuität.

Das beobachtete System war nicht das einzige technisch mögliche System. Es war eine Antwort auf Kosten, die nicht alle gleichzeitig minimiert werden konnten.

Was sich änderte, was blieb und was nicht gefolgert werden kann

Die Belege stützen eine aufgeteilte Zuschreibung von Kausalität.

Das klassenbasierte Design schuf die Diskontinuitäten. Die 32‑Bit‑Adresse hätte auf andere Weise unterteilt werden können, aber die eingesetzte Architektur bot feste A‑, B- und C‑Grenzen. Für einen Bedarf knapp über 254 normalen Hosts gab es keine native Klasse, die einen moderaten Anstieg bot. Das war eine Protokolleigenschaft.

Routing und Hardware machten die Diskontinuitäten wirtschaftlich und betrieblich bedeutsam. Mehrere Klasse‑C‑Netze konnten Adresswerte schonen, während sie die Belastung durch Netzwerknummern und Routing erhöhten. Ein subnettiertes Klasse‑B‑Netz konnte externen Zustand schonen, erforderte jedoch geeignete Software und verbrauchte eine viel größere Zuteilung. Dies waren für zeitgenössische Ingenieure sichtbare Beschränkungen.

Die administrative Richtlinie bestimmte, wie das System reagierte. Frühes veröffentlichtes Material enthielt Berechtigungs- und Gateway-Bereitschaftskriterien, rekonstruiert aber keine vollständige Schnittstelle zur Klassenauswahl. Bis 1990–1993 diskutierte die öffentliche Aufzeichnung explizit Knappheit, Delegation, Host- und Subnetzschwellen, 24‑Monats-Prognosen, Engineering-Pläne und Ausnahmen. Das Urteilsvermögen wurde strukturierter, ohne zu verschwinden.

Die Ergebnisse auf Antragstellerebene bleiben unterbestimmt. Den verfügbaren Momentaufnahmen fehlen vollständige Anträge, Ablehnungen, Alternativen, Auslastungsaufzeichnungen und Entscheidungserklärungen. Sie können nicht belegen, dass technisch fähige Antragsteller generell überlegenen Zugang genossen oder dass Administratoren systematisch etablierte Akteure bevorzugten. Sie können auch nicht belegen, dass große frühe Zuteilungen in jedem Fall gerechtfertigt waren.

Die Momentaufnahmen zeigen jedoch einen plausiblen Mechanismus der Pfadabhängigkeit. Sobald ein Empfänger eine Zuteilung eingesetzt hatte, verursachte eine Umnummerierung Kosten. RFC 820 erkannte Härten ausdrücklich als Grund an, eine Nummer beizubehalten, wenn ein experimentelles Netzwerk in Betrieb ging. Eine große frühe Zuteilung konnte daher bestehen bleiben, nachdem sich die Kriterien für vergleichbare neue Zuteilungen verschärft hatten.

Der Vorteil sollte als Option beschrieben werden, nicht als gemessene Dividende. Der Empfänger konnte intern expandieren, weiterhin ein klassenbasiertes Ziel präsentieren, seltener umnummerieren oder Kapazität behalten, deren spätere Beschaffung schwierig wurde. Ob ein bestimmter Empfänger diese Optionen nutzte, sie verdiente oder ihre spätere Bedeutung vorhersah, ist eine separate empirische Frage.

Moderne Belege bestätigen die Persistenz, ohne frühe Motive aufzuklären. Eine Studie aus dem Jahr 2017 über gemeldete IPv4‑Transfers ergab, dass Legacy-Adressraum 63,82 Prozent des Adressraums in ihrer Stichprobe gemeldeter Transfers ausmachte. Dieselbe Untersuchung zeigte, warum spätere Aufzeichnungen mit Vorsicht interpretiert werden müssen: Routing-Änderungen können Anbieterwechsel, Neuzuweisungen, organisatorische Umstrukturierungen oder komplexes Adressmanagement widerspiegeln und nicht einen Verkauf.

Dieses Ergebnis ist nur als schmale Überprüfung relevant. Es zeigt, dass Zuteilungen aus der Zeit vor den Registries lange genug bestanden, um wesentlich an späterer Umverteilung teilzunehmen. Es zeigt nicht, warum 1983 eine Klasse gewählt wurde, ob der ursprüngliche Antragsteller eine genaue Prognose lieferte, ob die Zuteilung fair war oder was ein früher Administrator beabsichtigte.

Der heutige Geldwert ist noch weiter von der frühen Entscheidung entfernt. Ein aktueller Preis, der auf alle Adressen innerhalb eines Legacy-Blocks angewendet würde, würde ungerouteten Raum, Richtlinienbeschränkungen, Transaktionskosten, Fragmentierung, betriebliche Abhängigkeiten und die Unterscheidung zwischen Registrierung und Kontrolle ignorieren. Noch wichtiger: Er würde spätere Knappheit an die Stelle zeitgenössischer Motive setzen.

Die historische Schlussfolgerung ist daher begrenzt, aber folgenreich. Das klassenbasierte IPv4 wandelte technische Granularität in eine administrative Entscheidungsgrenze um. Routing-Begrenzungen machten die größere Einheit manchmal vertretbar. Gerätegrenzen machten Subnetting manchmal kostspielig. Frühe Antragsteller und Administratoren arbeiteten mit Prognosen, die heute nicht mehr aus abgeschlossenen Registern rekonstruiert werden können. Spätere Richtlinien machten die Abwägungskriterien expliziter und verlagerten die Arbeit hin zu regionalen und anbieterbasierten Institutionen.

Die administrative Knappheit wurde in der Lücke zwischen 254 und 65.534 geboren, aber nicht, weil die Lücke eine Antwort diktierte. Sie wurde geboren, weil jede verfügbare Antwort Kosten für einen anderen Akteur oder ein anderes System verursachte und jemand entscheiden musste, welche Kosten zu tragen waren.

Quellen

• RFC 790,Assigned Numbers
• RFC 791,Internet Protocol
• RFC 820,Assigned Numbers
• RFC 950,Internet Standard Subnetting Procedure
• RFC 1118,The Hitchhikers Guide to the Internet
• RFC 1122,Requirements for Internet Hosts—Communication Layers
• RFC 1166,Internet Numbers
• RFC 1174,IAB Recommended Policy on Distributing Internet Identifier Assignment
• RFC 1338,Supernetting: an Address Assignment and Aggregation Strategy
• RFC 1366,Guidelines for Management of IP Address Space
• RFC 1466,Guidelines for Management of IP Address Space
• RFC 1482,Aggregation Support in the NSFNET Policy-Based Routing Database
• RIPE-048,RIPE Internet Network Numbers Template
• Computer History Museum,Guide to the SRI ARC/NIC Records
• University of Bristol,25 Years of Internet at University of Bristol
• On IPv4 Transfer Markets: Analyzing Reported Transfers and Inferring Transfers in the Wild