Die 32-Bit-Grenze war technisch; das Rationierungssystem war politisch

Zusammenfassung

• RFC 791legte jedes IPv4-Quell- und Zieladressfeld auf 32 Bit fest und interpretierte gewöhnliche Unicast-Adressen zunächst über drei Klassen; sie schrieb keine regionalen Register, Bedarfsprognosen, Nutzungstests, Anbieterabhängigkeit, Audits, Sanktionen oder Rechtsmittel vor.
• Die 2^{32} möglichen Werte, also 4.294.967.296, stellten nie einen einheitlichen Pool zuweisbarer öffentlicher Host-Adressen dar. Die Klassenstruktur, Sonderwerte, Reservierungen, zugewiesene Blöcke, Routing-Sichtbarkeit und tatsächliche Nutzung schufen unterschiedliche Nenner, die nicht kombiniert werden können.
• Von 1993 bis 1996 wählten veröffentlichte Richtlinien entscheidende Regeln: 24-Monats-Prognosen und Klasse-B-Schwellen in RFC 1466; topologiebasierte Aggregation in RFC 1519; und gestaffelte Zuweisungen, Anbieterhierarchie, Nutzungstests, Audits, Adressrückgabe und Rechtsmittel beim übergeordneten Register in RFC 2050.
• Erhaltung und Aggregation begegneten echten technischen Risiken, insbesondere der Klassenverschwendung und dem Wachstum der Routing-Tabellen. Das politische Element lag nicht in der Erfindung der Knappheit, sondern darin, dass identifizierbare Institutionen aus möglichen Wegen zur Verteilung von Kosten, Autorität, Ausnahmen und Rechtsmitteln wählten.
• Öffentliche Zuordnungsregister zeigen die positiven Ergebnisse, nicht die Anträge, Ablehnungen, Überarbeitungen, Verzögerungen oder informellen Ratschläge, die sie hervorbrachten. Der Text des Regimes und seine technische Begründung lassen sich mit größerer Zuversicht rekonstruieren als seine volle distributive Wirkung.

Die Architektur legte die Grenze fest; die Verwaltung wählte den Test

Zwei datierte Dokumente stellen die wesentliche Unterscheidung her.

Im September 1981 spezifizierte RFC 791 ein Quelladressfeld und ein Zieladressfeld, jeweils 32 Bit. Sie definierte eine Internet-Adresse als vier Oktette und unterteilte ihre anfängliche gewöhnliche Unicast-Interpretation in die Formate Klasse A, Klasse B und Klasse C. Eine Klasse-A-Adresse verwendete ein Klassenidentifikationsbit, sieben Bits Netznummer und 24 Bits lokale Adresse. Klasse B verwendete zwei Klassenbits, 14 Bits Netznummer und 16 Bits lokale Adresse. Klasse C verwendete drei Klassenbits, 21 Bits Netznummer und acht Bits lokale Adresse. Dies waren Protokolleigenschaften, die in der Adressdiskussion und der Headerspezifikation dargelegt wurden.RFC 791, September 1981, Abschnitte 2.3 und 3.1, Seiten 7 und 11–12

Im Mai 1993 empfahl RFC 1466, dass ein Register zusammenhängende Klasse-C-Zuweisungen basierend auf der Prognose des Antragstellers über die benötigten Endsystem-Adressen in den folgenden 24 Monaten dimensioniert. Eine Prognose unter 256 Adressen entsprach einer Klasse-C-Netznummer; unter 512 zwei; unter 1.024 vier; und so weiter, bis zu 64 zusammenhängenden Klasse-C-Netznummern für eine Prognose unter 16.384. Für eine Klasse B gab das Dokument an, dass ein Antragsteller mehr als 32 Subnetzeundmehr als 4.096 Hosts rechtfertigen musste, gestützt durch einen technischen Plan für die folgenden 24 Monate.RFC 1466, Mai 1993, Abschnitte 4.2.1 und 4.3, Seiten 6–8

RFC 1466 war informativ. Ihr Statusvermerk gab ausdrücklich an, dass sie keinen Internetstandard spezifiziert. Elise Gerich ist die Autorin; die Zusammenfassung berichtet von allgemeiner Unterstützung für ihre Empfehlungen durch die Federal Engineering Planning Group im Auftrag des Federal Networking Council, die Co-Vorsitzenden der Intercontinental Engineering Planning Group und RIPE. Diese Kombination ist der Nachweis einer Empfehlung einer Autorin mit institutioneller Unterstützung. Sie beweist nicht, dass jedes Register jeden Schwellenwert sofort umsetzte, dass eine normative IETF-Aktion die Richtlinie erzwang oder dass jedes betroffene Netzwerk einverstanden war.RFC 1466, Status, Zusammenfassung und Danksagungen, Seiten 1 und 9

Das Protokoll und die Empfehlung beantworteten unterschiedliche Fragen. Ein 32-Bit-Feld definierte den äußeren mathematischen Raum. Es wählte keinen Prognosehorizont, keine Zuordnungshierarchie, keine Nutzungsformel, keine geografische Region, keine Prüfbefugnis oder keinen Rechtsweg. Die Regeln konnten umsichtige Antworten auf echte Zwänge sein, aber sie waren nicht aus dem Header ableitbar.

Dies ist die enge Bedeutung vonPolitikhier. Sie identifiziert eine Entscheidung, die von einer benannten Institution, Autorin oder Durchführungsverantwortlichen getroffen wurde, aus technisch und administrativ plausiblen Arrangements, bei der die Wahl Autorität verlagerte oder unterschiedliche Kosten für Dokumentation, Zeitplan, Anbieterabhängigkeit, Routing, Renummerierung oder Überarbeitung auferlegte. Es bedeutet nicht, dass Knappheit erfunden wurde, dass die Akteure parteiisch waren oder dass ihre Entscheidungen korrupt waren. Es stellt die Fragen, wer die Regel wählte, welcher alternative Parameter unter den damaligen Bedingungen möglich gewesen wäre, und wer die daraus resultierende Last oder Autorität trug.

Ein einziger Adressraum erzeugte mehrere inkompatible Nenner

Die vertraute Arithmetik ist korrekt:

[2^{32}=4.294.967.296]

Ihre Einheit sind nominale binäre Werte pro 32-Bit-Quell- oder Zieladressfeld. Dies ist keine Zählung zuweisbarer öffentlicher Hosts, Organisationen, Kundenverbindungen, Registerzuweisungen, gerouteter Präfixe oder Adressraumanfragen.

Die Klassenbits unterteilten diesen mathematischen Raum sofort. Das rohe Klasse-A-Netznummernfeld enthielt 2^7 = 128 Bitmuster; Klasse B enthielt 2^{14} = 16.384; und Klasse C enthielt 2^{21} = 2.097.152. Die administrative Buchhaltung behandelte nicht jedes rohe Muster als gewöhnliche Netznummer. Die Tabelle von Mai 1992 in RFC 1466 zählte stattdessen 126 Klasse-A-Netznummern, 16.383 Klasse B und 2.097.151 Klasse C. Dies sind Populationszahlen von Netznummern nach Klassen, keine Adresswerte oder Organisationen.

Die Tabelle verzeichnete ebenfalls 49 zugewiesene Klasse-A-Netznummern, 7.354 Klasse B und 44.014 Klasse C im Mai 1992. Dies sind erfolgreiche Einträge in einer bestimmten administrativen Tabelle. Sie offenbaren weder die Anzahl der Antragsteller noch wie viele Adressen belegt, angekündigt, erreichbar oder beantragt waren.RFC 1466, Abschnitt 3, Tabelle 1, Seite 3

Eine vertretbare Prüfung der Nenner trennt daher die folgenden Populationen.

Diese Unterscheidungen sind keine semantische Spitzfindigkeit. Jede Zeile beantwortet eine andere Frage. Eine Zuweisung auf oberster Ebene reduziert einen administrativen Pool, ohne zu zeigen, dass der zugewiesene Raum angekündigt wird. Eine Route kann einen großen Block mit wenigen belegten Endpunkten abdecken. Mehrere Routen können eine einzelne Zuweisung darstellen. Eine Zuteilung kann ungenutzt bleiben, während ein Host mehrere Adressen oder Schnittstellen haben kann. RFC 791 selbst sah Hosts mit mehreren physischen Schnittstellen und mehreren logischen Internet-Adressen vor.

Ein Register und eine Routing-Tabelle können nicht einfach zusammengeführt werden, weil sie beide Präfixe enthalten.

Die damalige übliche Konvention zur Host-Identifikation schuf eine weitere Population. RFC 1519 beschrieb ein Klasse-C-Netzwerk als unterstützend höchstens 2^8 – 2 = 254 gewöhnliche Host-Identifikatoren und ein Klasse-B-Netzwerk als unterstützend höchstens 2^{16} – 2 = 65.534, nach Ausschluss der lokalen All-Zero- und All-One-Werte, die gemäß der zitierten Konvention verwendet wurden. Dies sind potenzielle gewöhnliche Identifikatoren innerhalb eines Netzwerks, keine Zählungen verbundener Hosts.RFC 1519, Proposed Standard, September 1993, Abschnitt 1, Seiten 1–2

Angenommen, nur zur Veranschaulichung des Maßstabs, dass ein Identifikator für jeden von 600 verbundenen Hosts benötigt wird. Die 65.534 gewöhnlichen Identifikatoren einer Klasse B würden 65.534/600 = 109,223 Mal den angegebenen Bedarf liefern und 65.534 – 600 = 64.934 gewöhnliche Identifikatoren außerhalb dieses unmittelbaren Bedarfs lassen. Die Berechnung zeigt die Klassen-Granularität; sie beweist nicht, dass ein echter Antragsteller mit 600 Hosts keine Reserve benötigte, eine flache Topologie hatte oder mit einem beliebigen klassenlosen Block arbeiten konnte.

RFC 1466 schlug ein anderes Beispiel für 600 Hosts vor. Wenn 600 Hosts gleichmäßig auf zehn Ethernets verteilt wären und die Topologie die Verwendung eines gemeinsam genutzten Klasse-C-Blocks erschwerte, könnte der Antragsteller zehn Klasse-C-Netznummern erhalten, eine pro Ethernet, vorbehaltlich einer technischen Begründung für die Abweichung von der standardmäßigen Zweierpotenztabelle. Die betrachtete Einheit waren dann Klasse-C-Netznummern, nicht 600 Adressen aus einem freien Pool.RFC 1466, Abschnitt 4.3, Seite 8

Spätere Beweise erfordern die gleiche Vorsicht. Die CAIDA-Studie zum IPv4-Verbrauch wurde aus einer IANA-Datei vom 14. September 2005 und WHOIS-Snapshots vom 31. August 2005 für ARIN, APNIC, LACNIC und RIPE erstellt. Ein AFRINIC-Snapshot fehlte. CAIDA entfernte Formatunterschiede zur Schaffung einer gemeinsamen Darstellung und beschränkte die Zeilen jedes RIR auf den Raum, der diesem Register in der IANA-Datei zugeordnet war, wodurch doppelte Vorkommen durch Migrationen und Verweise reduziert wurden. Sie gruppiert migriertes Legacy-Material in einen separaten Satz „sonstiges“.CAIDA, „IPv4 Consumption Rates“, Methodik und Warnhinweise

Ihre Zahlen verwendeten das Adressvolumen, üblicherweise ausgedrückt in/8-Äquivalentmengen. Sie unterschieden IANA-Zuweisungen, das erste Vorkommen in einem nachgelagerten Register und die spezifischste in den Daten gefundene Zuteilung. CAIDA gab ausdrücklich an, dass die Grafiken Zuweisungen zeigten, keine Ankündigungen oder Erreichbarkeit. Sie erklärte auch, dass eine IANA-Bereinigung vielen Legacy-Einträgen, für die genaue historische Daten nicht verfügbar waren, das Datum August 1993 zuwies. Dies sind rekonstruierte administrative Daten, keine gefundenen Transaktionsdaten.CAIDA, Methodik, Warnhinweise und Abbildungen 1–7

Die Rekonstruktion ist nützlich, um zu zeigen, warum administrative Ebenen getrennt werden müssen. Sie ist kein zeitgenössischer Beweis für die Erfahrung von Antragstellern im Jahr 1993. Sie misst keine Anträge, Ablehnungen, Überarbeitungen, Routen, Ankündigungen, erreichbare Hosts, belegte Schnittstellen, Motivationen oder politische Kausalität.

Der Artikel von Richter, Allman, Bush und Paxson,A Primer on IPv4 Scarcity, ist noch später. Er wurde am 10. November 2014 eingereicht, am 27. Februar 2015 überarbeitet und als redaktioneller Beitrag inACM Computer Communication Review45(2) im April 2015 veröffentlicht. Er ist eine wertvolle retrospektive Synthese und eine Quellenspur für technische, institutionelle und Erschöpfungsentwicklungen. Er kann nicht feststellen, was ein Akteur 1981–1998 wusste, wie ein damaliger Antragsteller die Interaktion mit einem Register erlebte, ob ein Mechanismus eingesetzt wurde oder ob Zeitgenossen einer späteren Markt- oder Eigentumsdoktrin anhingen.Richter et al., „A Primer on IPv4 Scarcity“, Veröffentlichungshinweis

Die äußere mathematische Grenze war einzigartig. Die betriebliche Knappheit war es nicht. Sie manifestierte sich in Zählungen von Netznummern nach Klassen, reservierten Bereichen, Registerbeständen, Zuteilungseinheiten und Routerzuständen, jeweils mit eigenem Datum und Nenner.

Klassenverschwendung und Routing-Druck waren real

Der erste unmittelbare Druck kam von der Granularität. Eine Organisation, die mehr als 254 gewöhnliche Host-Identifikatoren benötigte, hatte keine klassengerechte Zuteilungseinheit, die einem Bedarf von 300, 600 oder 4.000 entsprach. Eine Klasse B konnte viel zu groß sein. Ein Satz von Klasse-C-Netzwerken konnte im Adressvolumen näher sein, aber schwieriger zu verwalten und, vor effektiver Aggregation, teurer für das globale Routing-System.

Subnetting half innerhalb eines vorhandenen klassengebundenen Netzwerks. RFC 950, eine Spezifikation auf dem Weg zum Standard vom August 1985, definierte eine Adressmaske, die das lokale Adressfeld in Subnetz- und Hostteile unterteilte. Eine Organisation konnte eine einzige extern sichtbare Netznummer über mehrere interne Subnetze verwenden, anstatt jedes interne Kabel als unabhängiges Netzwerk anzukündigen. Dies allein erlaubte es einem Register nicht, weltweit geroutete Präfixe beliebiger Länge an ein Internet auszugeben, dessen Inter-Domain-Mechanismen immer noch auf Klasseninterpretation beruhten.RFC 950, August 1985, Abschnitt 2.1, Seiten 4–6

Der zweite Druck kam von der Weiterleitungstabelle. Das Ersetzen einer alten Klasse-B-Zuweisung durch 16 separat angekündigte Klasse-C-Netzwerke konnte eine Klasse-B-Netznummer bewahren, aber gleichzeitig 16 Routing-Einträge hinzufügen, wo keine Aggregation verfügbar war. Adresserhaltung und Routing-Erhaltung konnten daher in entgegengesetzte Richtungen gehen.

RFC 1519, veröffentlicht als Proposed Standard im September 1993, beschrieb drei Probleme: die schnelle Erschöpfung der Klasse-B-Netznummern, das Wachstum der Routing-Tabelle über die Fähigkeiten verfügbarer Software und Router hinaus und die zukünftige Erschöpfung des 32-Bit-Raums. Seine unmittelbare Strategie war CIDR: Zuweisung zusammenhängender Blöcke geeigneterer Größe, Ausrichtung der Verteilung an der Topologie und Ankündigung von Aggregaten, wo Protokollunterstützung und Konnektivität es erlaubten.RFC 1519, Status und Abschnitte 1–3, Seiten 1–9

Sein quantitatives Argument erfordert sowohl die exakte Tabelle als auch den gerundeten Text.

Tabelle I, von MERIT, berichtete 4.526 angekündigte Routen im Januar 1992 und 8.561 im Dezember 1992. Abschnitt 3.3.2 beschrieb dagegen die NSFNET-Routing-Datenbank von Januar als mit „ungefähr 4.700“ Einträgen und die von Dezember mit 8.500. Er gab an, dass die historische Tabelle zwischen 1988 und 1991 durchschnittlich alle zehn Monate gewachsen war, und veröffentlichte eine Prognose von ungefähr 30.000 Einträgen zwei Jahre nach dem Referenzpunkt Januar 1992.RFC 1519, Tabelle I und Abschnitt 3.3.2, Seiten 7–9

Diese Prognose ergibt sich nicht aus den angegebenen gerundeten Einträgen:

[4.700\times 2^{24/10}=24.806,75]

Unter Verwendung der genauen Beobachtung aus Tabelle I für Januar erhält man:

[4.526\times 2^{24/10}=23.888,37]

Keines dieser Ergebnisse ist bei gewöhnlicher Rundung ungefähr 30.000. Der Artikel kann 30.000 nur als die veröffentlichte und nicht abgeglichene Prognose der RFC-Autoren beibehalten. Die Quelle erklärt die Differenz von etwa 5.193 Einträgen zwischen 30.000 und dem Ergebnis mit den gerundeten Einträgen nicht. Es wäre unangemessen, eine andere Referenz, Wachstumsrate oder versteckte Anpassung zu erfinden, um die Lücke zu schließen.

Der Dezember-Vergleich ist direkter. Die beobachtete Einheit in Tabelle I war 8.561 angekündigte Routen im Dezember 1992. Abschnitt 3.3.2 rundete dies auf 8.500 und verglich es mit über 9.400, die von einer früheren Kurve vorhergesagt wurden. Die Autoren sagten, sie könnten nicht feststellen, ob die niedrigere Beobachtung eine signifikante Änderung des Wachstums darstellte. Es handelte sich um Beobachtungen und Prognosen im MERIT/NSFNET-Kontext, nicht um eine Volkszählung aller Router oder eine physikalische Grenze, an der das Internet gescheitert wäre.

Die RFC untersuchte auch die Auswirkung der Ausgabe von vier bis sechzehn Klasse-C-Routen, wo zuvor eine Klasse B hätte verwendet werden können. Sie prognostizierte bedingt, dass die Routing-Tabelle innerhalb von sechs Monaten 10.000 Einträge und innerhalb eines Jahres 20.000 überschreiten könnte. Dies waren Szenarioergebnisse basierend auf separat angekündigten Klasse-C-Netzwerken, keine beobachteten Ergebnisse. Die Aggregation sollte genau diese Vervielfachung verhindern.

Die technische Logik war fundiert. Wenn Kunden, die über denselben Anbieter verbunden waren, zusammenhängende Teilmengen des Blocks dieses Anbieters erhielten, konnte der Anbieter eine einzige, weniger spezifische Route ankündigen. Zehn unabhängig geroutete Kundenblöcke könnten zehn weltweit sichtbare Einträge erfordern; zehn topologieausgerichtete Kundenblöcke könnten, vorbehaltlich Ausnahmen und korrektem Betrieb, von einem einzigen Aggregat abgedeckt werden. Die genaue Ersparnis hing von Multihoming, Routing-Richtlinie, Ausfällen, Filtern und der Notwendigkeit ab, spezifischere Routen dennoch zu propagieren.

Der Übergang war nicht automatisch. RFC 1338, ein im Juni 1992 veröffentlichter Informationsvorschlag, später überholt durch RFC 1519, warnte, dass ein neuer Adressplan und Änderungen an den Inter-Domain-Routing-Protokollen erforderlich waren. Er gab an, dass die Routing-Tabellen in der Zwischenzeit zwischen der Implementierung topologieorientierter Zuweisungen und dem Einsatz kompatibler Protokolle sehr schnell wachsen könnten.RFC 1338, Juni 1992, Abschnitt 2.1, Seite 4

BGP-4 lieferte eine Spezifikation für den Transport klassenloser Präfixe und Routenaggregation, aber der Veröffentlichungsstatus darf nicht mit dem Einsatz verwechselt werden. RFC 1654 war eine BGP-4-Spezifikation auf dem Weg zum Standard im Juli 1994. RFC 1771, ebenfalls auf dem Weg zum Standard, ersetzte sie im März 1995 und beschrieb die Unterstützung für IP-Präfixe, die Entfernung des Klassenkonzepts in BGP sowie Routen- und AS-Pfad-Aggregation.RFC 1654, Juli 1994, Status und Abschnitte 1–2, Seiten 1–2;RFC 1771, März 1995, Status und Abschnitte 1–2, Seiten 1–2

Diese Veröffentlichungen belegen den Spezifikationsstatus und die dokumentierte Fähigkeit. Sie belegen nicht, wie viele Router zu einem bestimmten Zeitpunkt BGP-4 ausführten, welche Netzwerke klassenlose Routen austauschten, welcher Teil der Tabelle aggregiert war oder ob die Einführung 1998 universell war. Ohne eine benannte Reihe von Routing-Snapshots, ein Beobachtungsdatum, eine Population und einen Beobachtungspunkt ist keine numerische Einsatzrate oder Behauptung „etabliert 1998“ gerechtfertigt.

Die Prognoseregel verteilte die Unsicherheit

Die Klasse-B-Regel von RFC 1466 verdeutlicht am besten die institutionelle Wahl. Ihre genannten Kriterien erforderten mehr als 32 Subnetzeundmehr als 4.096 Hosts. Der Antragsteller musste auch darlegen, warum ein Klasse-C-Block unangemessen war, und die voraussichtliche Anzahl von Hosts und Subnetzen für die nächsten 24 Monate angeben. Wenn der Plan eine Klasse B nicht rechtfertigte, war das angegebene Ergebnis ein Klasse-C-Block. Ein Antragsteller, der die numerischen Kriterien nicht erfüllte, aber keine Klasse-C-Netzwerke verwenden konnte, konnte ein technisches Argument vorbringen. Das Dokument bezeichnete diese Schwellen als vorgeschlagene Kriterien und nicht als protokollarische Invariante.RFC 1466, Abschnitt 4.2.1, Seiten 6–7

Das unmittelbare technische Ziel war die Erhaltung von Klasse-B-Netznummern. Nach der damaligen Konvention exponierte eine Klasse B 65.534 gewöhnliche Host-Identifikatoren. Die Zuweisung dieser Einheit an ein Netzwerk mit wesentlich geringerem Bedarf konnte einen großen Teil ihrer Kapazität blockieren. Der Subnetzplan überprüfte, ob der Antragsteller die Topologie benötigte, die eine Klasse B aufnehmen konnte, anstatt einfach ihre Bequemlichkeit zu bevorzugen.

RFC 1466 erkannte die Belastung an. Sie gab an, dass die Beschränkungen für Klasse-B-Zuweisungen einige Organisationen zwingen könnten, zusätzliche Ressourcen für die Verwendung mehrerer Klasse-C-Netznummern aufzuwenden. Das Dokument betrachtete diese Kosten als bedauerlich, aber für die weitere Erhaltung notwendig. Dies ist ein ungewöhnlich direkter Nachweis der Kostenin­zidenz: Die Empfehlung der Autorin wählte eine Erhaltungsregel und identifizierte als Konsequenz zusätzliche technische Ausgaben für die betroffenen Antragsteller.RFC 1466, Abschnitt 4.2, Seite 6

Der 24-Monats-Horizont war nicht weniger ein Parameter. Der Informations-RFC dokumentierte, warum Prognosen notwendig waren, zeigte aber nicht, dass 24 Monate den Gesamtabfall an Adressen, Bearbeitungskosten, Verzögerungen oder Prognosefehler einzigartig minimierten. Ein Test über 12, 18 oder 36 Monate wäre eine vom Analysten konstruierte Variante, es sei denn, ein direkter Vorschlag aus der Zeit würde vorgelegt. Solche Variationen sind administrativ denkbar, da derselbe Antragsteller dieselben Kategorien technischer Nachweise über einen anderen Horizont einreichen könnte.

Ihre praktische Leistung bleibt unbekannt: Ein kürzerer Horizont würde die Exposition gegenüber optimistischem Wachstum verringern, aber wiederholte Anträge erhöhen, während ein längerer Horizont die Transaktionshäufigkeit auf Kosten eines größeren Prognosefehlers reduzieren könnte.

Die klassenlose Zuweisung war 1993 eine technisch fundiertere Alternative, jedoch nur innerhalb gewisser Grenzen. RFC 1338 hatte im Juni 1992 zusammenhängende Anbieterblöcke vorgeschlagen, und RFC 1519 spezifizierte im September 1993 die CIDR-Zuweisungs- und Aggregationsstrategie. Ihre eigenen Warnungen zeigen die erforderlichen Annahmen: Register mussten an geeigneten Grenzen zuweisen, Anbieter mussten topologieausgerichtete Blöcke aufrechterhalten, und Inter-Domain-Protokolle und Router mussten beliebige Netzwerk-Masken-Paare unterstützen.

Bevor diese Bedingungen ausreichend implementiert waren, konnte die Ausgabe feinerer Blöcke die Routen vervielfachen anstatt zu reduzieren.

RFC 2050 änderte das Prognosedesign im November 1996. Sie trennte Zuweisungen an ISPs von Zuteilungen an Endkunden. Abschnitt 2.1 gab an, dass neue ISPs eine Mindestzuweisung basierend auf dem unmittelbaren Bedarf erhalten würden. Spätere Zuweisungen könnten erhöht werden, nachdem der ISP eine Nutzungsüberprüfung vorgelegt hatte, und der zusätzliche Raum sollte etwa drei Monate nachgelagerter Zuteilungen abdecken. Der prognostizierte Kundenstamm habe wenig Einfluss; nachgewiesene Bedürfnisse überwögen.RFC 2050, BCP 12, November 1996, Abschnitt 2.1, Seiten 4–5

Die berühmten 25- und 50-Prozent-Zahlen befanden sich woanders. Sie standen in Abschnitt 3.1 für Endkundenzuteilungen: eine sofortige Nutzungsrate von 25 Prozent und eine Nutzungsrate von 50 Prozent innerhalb eines Jahres. Abschnitt 3.6 definierte den Zähler als die Anzahl der mit dem Netzwerk verbundenen Hosts und den Nenner als die Gesamtzahl der möglichen Hosts in diesem Netzwerk. Das Ein-Jahres-Kriterium bedeutete daher, dass erwartet wurde, dass die verbundenen Hosts innerhalb dieses Horizonts mindestens 50 Prozent der möglichen Hostpopulation des Netzwerks erreichten. Es handelte sich nicht um ein Verhältnis von Kunden zu Adressen, zugewiesenen Adressen zu Zuweisungsgröße, Schnittstellen zu Adressen oder nachgelagerten Zuteilungen zu ISP-Zuweisungen.RFC 2050, Abschnitte 3.1 und 3.6, Seiten 7 und 9

Diese Unterscheidung ändert die institutionelle Analyse. Endkunden waren einem Nutzungstest ausgesetzt, der auf verbundenen Hosts im Verhältnis zu möglichen Hosts in ihrem vorgeschlagenen Netzwerk basierte. ISPs waren einem schrittweisen Start, überprüfter nachgelagerter Nutzung und einer Nachschubmenge ausgesetzt, die etwa drei Monate zusätzlicher Zuteilungen abdecken sollte. Die Kombination würde eine fiktive gemeinsame Metrik erzeugen.

Beide Designs platzierten die Prognoseunsicherheit irgendwo. Eine längere anfängliche Zuweisung exponierte den gemeinsamen Pool, wenn die Nachfrage ausblieb. Eine kleinere anfängliche Zuweisung erhöhte die Bedeutung der Reaktionsfähigkeit des Registers und der Fähigkeit des Antragstellers, wiederholtes Wachstum zu dokumentieren. Die RFCs legen die gewählten Regeln und ihre erklärten Ziele fest. Sie liefern keine Verteilungen der Bearbeitungszeiten, beantragten Anfangsbeträge, Überarbeitungshistorien oder den Nachweis, dass eine Klasse von Antragstellern systematisch mehr Verzögerungen erlitt.

Die Hierarchie verwandelte Topologie in Abhängigkeit

RFC 1466 schlug vor, Teile des Klasse-C-Nummernraums in große geografische Blöcke aufzuteilen und die primäre Zuweisungsverantwortung an qualifizierte regionale Register zu delegieren. Sie beschrieb diese Aufteilung als „im Wesentlichen eine administrative Aufteilung“, die die verteilte Registrierung unterstützen sollte. Sie bevorzugte ein einziges anerkanntes regionales Register auf dieser Ebene, erwartete, dass die Organisation anerkannt und ausreichend ausgestattet war, und verlangte eine Verpflichtung zu den Richtlinien der IANA und des zentralen Internet-Registers. Das zentrale Register blieb verfügbar, um einen Antragsteller bei Bedarf zu bedienen, obwohl es ihn an die regionale Stelle verweisen konnte.RFC 1466, Abschnitte 2, 3 und 4.3, Seiten 2–4 und 7

Der Gesamtplan verband verteilte Verwaltung mit potenzieller Aggregation. Geografische Blöcke konnten die zentrale Arbeitslast reduzieren und grobe Zusammenfassungen ermöglichen, wo Geografie und Topologie zusammenfielen. Keine dieser Beziehungen war garantiert. Ein Kontinent war nicht im IPv4-Header kodiert, und die physische oder Anbietertopologie folgte nicht notwendigerweise einer regionalen Grenze.

Die Wahl eines einzigen anerkannten regionalen Registers konzentrierte die Auslegungsautorität über lokale Zuweisungen, Nachweise und Ausnahmen. Eine gemeinsam genutzte Datenbank mit überlappenden Registern oder eine allgemeine Wahl des Antragstellers zwischen zentralen und regionalen Entscheidern wäre eine analytische Alternative, kein dokumentierter Vorschlag aus der Zeit in den hier verwendeten Quellen. Ihre Machbarkeit würde eine schnelle Datenbankkoordination, zuverlässige Eindeutigkeitsprüfungen, gemeinsame Zuweisungsregeln und ein Mittel zur Verhinderung konkurrierender Zuteilungen voraussetzen.

Diese Annahmen waren 1993 administrativ anspruchsvoll. Die Alternative ist nützlich, um die Autorität zu verorten, nicht um zu behaupten, dass überlappende Register bessere Ergebnisse erzielt hätten.

RFC 1519 verlagerte die Hierarchie zur Anbietertopologie. Sie empfahl, dass die meisten, wenn nicht alle Netznummern über Dienstanbieter verteilt werden. Ihre technische Logik war direkt: Adressen aus dem Block eines Anbieters konnten durch das Aggregat dieses Anbieters repräsentiert werden, während unabhängig gehaltene Blöcke oft spezifischere Routen erforderten. Das Dokument argumentierte auch, dass verteilte Zuweisung die bürokratische Last der zentralen Nummernbehörden verringerte.RFC 1519, Abschnitte 2.2 und 3, Seiten 5–8

RFC 2050 beschrieb ein dreistufiges Registersystem: IANA, regionale Internet-Register und lokale Internet-Register. Im ISP-Kontext konnte ein ISP, der an mehreren Standorten Routen ohne Default-Routing austauschte, direkt bei seinem regionalen Register Raum beantragen. Anderen ISPs wurde gesagt, sie sollten Raum bei einem vorgelagerten Anbieter beantragen. Der direkte regionale Zugang war an Multihoming oder die Verbindung mit einem großen neutralen Austauschpunkt gebunden, den die RFC als Verbindung von vier oder mehr nicht verwandten ISPs definierte.RFC 2050, Abschnitte 1.1 und 2.1, Seiten 3–4

Derselbe Abschnitt ermutigte Anbieter, Kunden­zuteilungen als Leihgaben für die Dauer der Konnektivität zu behandeln. Wenn ein Kunde den Anbieter wechselte, empfahl sie die Rückgabe der alten Adressen und die Renummerierung in den Raum des neuen Anbieters, mit einer ausreichenden Übergangsfrist vor der Wiederverwendung. Dies war eine Routing-Strategie mit einer Wechselkostenfolge. Raum vom Anbieter verbesserte die Aggregationsmöglichkeiten; die Adresskontinuität des Kunden wurde von der Beziehung zum Anbieter abhängig.

Die Kosten wurden bereits anerkannt. RFC 1900, eine Informationserklärung des Internet Architecture Board vom Februar 1996, gab an, dass Organisationen, die nach einem Anbieterwechsel nicht umnummerierten, mit eingeschränkter Konnektivität, zusätzlichen Kosten zur Unterstützung der resultierenden Routing-Last oder beidem konfrontiert sein könnten. Ihr Titel,Renumbering Needs Work, fasste den Stand der Technik zusammen. Sie rief zur Entwicklung und Bereitstellung von Mechanismen zur Erleichterung von Wechseln auf; sie berichtete nicht, dass Renummerierung billig oder routinemäßig geworden war.RFC 1900, Februar 1996, Abschnitt 1, Seiten 2–3

Die benannten Entscheider und Durchführenden waren die RFC-Autoren, die IANA- und Registerbehörden, die regionalen und lokalen Register, die Anbieter, die Raum zuwiesen, und die Transitnetzwerke, die Routen akzeptierten oder filterten. Die mögliche Alternative zur damaligen Zeit war nicht unbegrenzte portable Adressierung. Es war ein anderer Kompromiss: Mehr direkte Zuweisungen würden die Abhängigkeit einiger Kunden von der Renummerierung verringern, aber ohne zuverlässige Aggregation oder Koordination über die Routenakzeptanz könnten sie weltweit sichtbare Präfixe hinzufügen. Die erhaltenen Dokumente belegen die Richtung des Abwägens.

Sie quantifizieren nicht, wie viele Kunden umnummerierten, wie viele alte Routen beibehielten, was sie bezahlten oder wie konsequent Anbieter die Rückgabe durchsetzten.

Die Prüfbefugnis existierte auf dem Papier; ihre Praxis bleibt ungemessen

Die dritte institutionelle Wahl betraf Überprüfung und Konsequenzen.

RFC 1466 erlaubte dem zentralen Internet-Register, Buchhaltungs- und Technikpläne von delegierten regionalen Zuweisungen zu erhalten und die Konsistenz dieser Pläne mit den Richtlinien zu überprüfen. Ausnahmen von den Klasse-C-Dimensionierungskriterien waren von Fall zu Fall zu entscheiden. Das Dokument lieferte kein Ausnahmeregister, keine Standardantwortzeit, keine veröffentlichte Beweislast oder unabhängigen Prüfer.RFC 1466, Abschnitte 4.2.2 und 4.3, Seiten 7–8

RFC 2050 beschrieb einen umfangreicheren Satz von Nachweisen. Ein Register konnte Subnetzmasken, Hostzählungen, Topologie, Routing-Pläne, Bereitstellungszeitpläne, frühere Zuteilungen und Bestätigungen verlangen. Zuvor von Divisionen oder Tochtergesellschaften derselben Muttergesellschaft gehaltener Raum konnte auf Unternehmensebene berücksichtigt werden. Anträge wurden von Fall zu Fall bearbeitet, wobei die Routinge­ffizienz eine relevante Überlegung war.RFC 2050, Abschnitte 3.2–3.5, Seiten 8–9

Abschnitt 4 gab an, dass alle Adressanträge einer Prüfung und Verifizierung mit allen Mitteln unterliegen, die das regionale Register für angemessen hält. Stellt sich heraus, dass eine Zuteilung auf falschen Informationen beruhte, konnte das Register den Antrag für ungültig erklären und die zugeteilten Adressen an den freien Pool zurückgeben. Abschnitt 3.1 stellte separat klar, dass eine Adresse gültig bleibt, solange die Qualifikationskriterien weiterhin erfüllt sind, und behielt sich eine Ungültigkeitserklärungsbefugnis vor, wenn der Bedarf nicht mehr besteht. Die Rückgabeempfehlung in Abschnitt 2.1 galt für Kundenadressen vom Anbieter, wenn die Konnektivität endete. Es handelte sich um verwandte, aber getrennte Befugnisse: Ungültigkeitserklärung wegen Falschinformation, Überprüfung des Fortbestehens des Bedarfs und Rückgabe bei Anbieterwechsel.RFC 2050, Abschnitte 2.1, 3.1 und 4, Seiten 4–5, 7 und 10

Der Text sah auch eine hierarchische Überprüfung vor. Abschnitt 6 erlaubte einer Organisation, die mit dem zuweisenden Register unzufrieden war, Berufung beim übergeordneten Register einzulegen. Relevante Unterlagen mussten zur Verfügung gestellt werden, und eine weitere Berufung konnte die Kette bis zur IANA hinaufgehen. Jedes Register sollte sein Berufungsverfahren dokumentieren. Der Prüfer blieb innerhalb derselben Registerhierarchie; die RFC schuf kein externes Gericht.RFC 2050, Abschnitt 6, Seite 11

Diese Bestimmungen autorisierten Durchsetzung und Überprüfung. Sie belegen keine Praxis. Keine zitierte Datei belegt die Häufigkeit von Prüfungen, die verwendeten Methoden, ob Antragsteller Vorankündigung oder eine Abhilfemöglichkeit erhielten, wie Prognosefehler von Falschaussage unterschieden wurden, die Häufigkeit von Adressrückgaben oder ob eine Berufung ein Ergebnis änderte. Der Text kann keine Konsistenz zwischen Registern oder in Einzelfällen belegen.

Mehrere Verfahrensvarianten sind mit der Technologie von 1996 denkbar, da sie die Verwaltung und nicht die Paketformate ändern: schriftliche Begründung von Ausnahmen, definiertes Prüfprotokoll, Vorankündigungs- und Abhilfefrist, anonymisierte Statistiken oder Überprüfung durch Stellen außerhalb der ursprünglichen Entscheidungskette. Dies sind vom Analysten konstruierte Parameter, sofern kein datierter Vorschlag vorgelegt wird. Sie würden Personal, Aufzeichnungen, Vertraulichkeitskontrollen und vereinbarte Autorität erfordern. Ihre Kosten und Effekte können nicht allein aus der RFC geschätzt werden.

Die institutionelle Wahl war daher real, aber begrenzt. RFC 2050 gab den regionalen Registern Ermessensspielraum bei der Überprüfung und den dargelegten Konsequenzen, während die Überprüfung innerhalb der übergeordneten Kette blieb. Dieses Design konnte Falschaussagen abschrecken und Adressaufzeichnungen bewahren. Es konzentrierte auch die Untersuchungs-, Ausnahme- und Sanktionsbefugnis. Die Beweise, dass diese Befugnis existierte, sind stark; die Beweise für ihre Inanspruchnahme und ihre distributiven Effekte fehlen.

Die RIPE-Akte belegt weniger als eine Zuweisungsakte

Die RIPE-Episode liefert den Nachweis delegierten Betriebs, aber keine vollständige Zuweisungsentscheidung.

Das Dokument RIPE-062,RIPE NCC Internet Numbers Registration Procedures, Version 0.5 vom Juli 1992, erscheint als Anhang A des ersten RIPE NCC-Quartalsberichts. Es gab an, dass das RIPE NCC seit dem 1. Mai 1992 als delegiertes Register für europäische Internet-Netznummern fungierte. Sein Verfahren bestand darin, Nummern an Dienstanbieter und nationale oder lokale Koordinierungsstellen zu vergeben, nicht direkt an einzelne Organisationen. Es erlaubte Dienstanbietern, Klasse-B-Netznummern einzeln zu beantragen, und verlangte eine Begründung basierend auf Organisationsgröße, vorhandenem Netzwerk, erwartetem Wachstum und der Unmöglichkeit, einen Klasse-C-Block zu verwenden.RIPE-062, Version 0.5, Juli 1992, Seite 25 ff.

Abschnitt 3 von RFC 1466 hielt später zwei engere Tatsachen fest. Das RIPE NCC hatte den Klasse-C-Netznummernbereich 193.0.0 bis 193.255.255 bereits vor Annahme des RFC-Vorschlags erhalten und zugestimmt, in diesem Bereich gemäß den Richtlinien der RFC 1466 zuzuweisen.RFC 1466, Abschnitt 3, Seite 3

Der Bereich enthält 2^{16} = 65.536 Klasse-C-Netznummern der Größe/24. Ausgedrückt als späterer CIDR-Bereich 193.0.0.0/8 umfasst er 2^{32-8} = 16.777.216 nominale Adresswerte. Die erste Zahl zählt Klasse-C-Netznummerneinheiten; die zweite zählt die vom Bereich abgedeckten binären Werte. Keine von beiden misst verbundene Hosts, nachgelagerte Zuweisungen, Ankündigungen, Nutzung oder die vom RIPE NCC beantragte Menge.

Die erhaltenen Dokumente liefern nicht den zugrunde liegenden Antrag, eine formelle Zuweisungsurkunde, einen Entscheidungsvermerk, die in Betracht gezogenen alternativen Blockgrößen, ausgehandelte Bedingungen oder ein genaues Zuweisungsdatum. RIPE-062 belegt ein delegiertes Verfahren. RFC 1466 belegt den vorherigen Besitz des Blocks 193.* und die Zustimmung, die neuen Richtlinien anzuwenden. Verteilte Verwaltung und potenzielle Aggregation waren Ziele des übergeordneten Richtlinienplans; es kann nicht behauptet werden, dass sie das dokumentierte Motiv oder die ausgehandelte Bedingung dieser speziellen Zuweisung darstellen.

Die Akte enthält auch keine Berufungs- oder Überprüfungsakte bezüglich der Delegation. Sie erlaubt den Schluss auf Registerebene, dass die Delegation 1992 funktionierte. Sie erlaubt keinen Schluss auf Antragstellerebene über Ablehnungen, Ungleichbehandlung, Verzögerungen oder die Auswirkung eines Schwellenwerts.

Technische Antworten kamen schrittweise

Der Zeitraum bot keinen vollständigen Ersatz für Rationierung. Sie bot Teilantworten mit unterschiedlichem Status, Voraussetzungen und Kostenübertragungen.

Private Adressierung veranschaulicht den Unterschied zwischen Spezifikation und Substitution. RFC 1918, BCP 5 vom Februar 1996, reservierte drei Blöcke für private Netzwerke. Sie verlangte von einem Unternehmen zu bestimmen, welche Hosts keine externe Netzwerkkonnektivität benötigten. Der Wechsel eines Hosts von privat zu öffentlich bedeutete, seine IP-Adresse, die entsprechenden DNS-Einträge und Konfigurationsdateien auf anderen Hosts, die auf die Adresse verwiesen, zu ändern. Private Routing-Informationen sollten sich nicht über die Unternehmensgrenzen hinaus ausbreiten, und private DNS-Verweise erforderten eine Isolierung.RFC 1918, Februar 1996, Abschnitte 2–5, Seiten 3–7

NAT war mehr als ein Konzept im Mai 1994, aber weniger als eine bewährte universelle Lösung. RFC 1631 war informativ und beschrieb einen vorläufigen Entwurf. Abschnitt 3 erklärte, dass Anwendungen, die eine IP-Adresse in ihren Daten transportieren, fehlschlagen könnten, es sei denn, der Übersetzer erkennt und überschreibt den Inhalt; Verschlüsselung könnte dies unmöglich machen. Abschnitt 4 identifizierte experimentelle Implementierungen in der KA9Q-Software und einem Cray Communications-Router, getestet mit Telnet und FTP, und gab an, dass die Prototypen Transparenz nur innerhalb der durch das Papier dargelegten Grenzen demonstrierten.RFC 1631, Mai 1994, Abschnitte 3 und 4, Seiten 6–9

IPv6 änderte den architektonischen Nenner. RFC 1883, eine im Dezember 1995 veröffentlichte Spezifikation auf dem Weg zum Standard, vergrößerte die IP-Adressgröße von 32 auf 128 Bit. Sie ersetzte nicht die zum Zeitpunkt ihrer Veröffentlichung installierten IPv4-Hosts, Router, Anwendungen oder Betriebsabläufe. Für ein Register, das 1996 einen IPv4-Antrag bearbeitete, war IPv6 ein spezifizierter Nachfolger, kein Beweis, dass das unmittelbare Problem der IPv4-Zuweisung verschwunden war.RFC 1883, Dezember 1995, Status und Abschnitt 1, Seiten 1 und 3

Rückgewinnung hatte ebenfalls Schritte. RFC 2050 empfahl die Rückgabe von Adressen vom Anbieter nach Beendigung der Konnektivität und autorisierte Ungültigkeitserklärung unter bestimmten Umständen. Sie enthielt keinen Datensatz über zurückgewonnene Blöcke und belegte nicht, wie leicht operative Netzwerke sie abgeben konnten. Rückgewinnung war ein autorisierter Mechanismus, keine gemessene Angebotsantwort.

Hardwareverbesserung blieb eine bedingte Möglichkeit. RFC 2050 gab an, dass die Adressierungsbeschränkungen die Router-Technologie, Zuweisungspraktiken und Architekturgeschichte widerspiegelten. Das Dokument berichtete eine Schlussfolgerung seiner Autoren, der zuständigen IETF-Arbeitsgruppe und der IESG, dass keine andere damals einsetzbare Technologie diese Einschränkungen überwand, während eine erneute Prüfung erlaubt wurde, falls Router später größere und dynamischere Tabellen handhabten oder Aggregation auf andere Weise möglich wurde. Dies ist eine zeitgenössische institutionelle Bewertung der Technologie, kein Referenzpunkt für jeden Router und kein Beweis, dass die begleitenden Prognose-, Prüf- und Berufungsparameter institutionell einzigartig waren.RFC 2050, Einleitung, Seite 2

RFC 2050 repräsentierte die Praxis ohne politische Billigung

Die institutionelle Rolle ist wichtig, da „die IETF entschied“ mehrere verschiedene Handlungen zusammenfassen würde.

RFC 2050 war BCP 12, veröffentlicht im November 1996, mit Autoren Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg und Jon Postel. Ihre Zusammenfassung beschrieb die damals von den regionalen Registern verwendeten Richtlinien zur Umsetzung der von der IANA entwickelten Leitlinien und gab an, dass die Regeln weiterhin überarbeitet werden könnten.RFC 2050, Titelseite, Zusammenfassung und Einleitung, Seiten 1–2

Die IESG-Bemerkung war bewusst enger als eine Billigung. Mit der Genehmigung des Dokuments als Best Current Practice erklärte die IESG, dass sie die Richtlinie als getreue Darstellung der damaligen Registerpraxis ansah. Sie lehnte ausdrücklich ab, die Richtlinie zu genehmigen oder zu empfehlen, und sah eine erneute Überprüfung im Lichte späterer Arbeitsgruppendiskussionen vor. Die Billigung der beschreibenden Genauigkeit, die Verfassung des Textes, die Ausarbeitung der Registerrichtlinien, die Umsetzung durch die Register und die Beratung durch eine Arbeitsgruppe waren getrennte institutionelle Rollen.

Die RFC präsentierte Erhaltung, Routbarkeit und Registrierung als drei Ziele. Sie erkannte auch Konflikte zwischen diesen Zielen und mit den Interessen von Endbenutzern und Anbietern an. Erhaltung begünstigte eine enge Passung zwischen Angebot und nachgewiesenem Bedarf. Routbarkeit begünstigte eine hierarchische, topologiesensitive Verteilung. Registrierung begünstigte genaue Aufzeichnungen von Zuteilungen.

Eine für ein Ziel optimierte Zuweisung konnte bei einem anderen schlecht abschneiden: Eine kleine direkte Zuweisung konnte das Adressvolumen erhalten, aber eine Route hinzufügen; ein Anbieterblock konnte gut aggregieren, aber Renummerierung auferlegen; gründliche Überprüfung konnte die Aufzeichnungen verbessern, aber die Transaktionskosten erhöhen.

Diese Anerkennung ist der stärkste interne Gegenbeweis gegen eine vereinfachende Erzählung willkürlicher Bürokratie. Die Autoren erkannten ein technisches Problem mit mehreren Zielen und riefen zu umsichtigem Urteilsvermögen auf. Die Dokumente rechtfertigen, dieses Problem ernst zu nehmen. Sie verwandeln nicht jeden Schwellenwert oder jede institutionelle Maßnahme in eine notwendige Konsequenz des Headers.

Die beste technische Verteidigung übersteht die Prüfung

Ein faires Urteil beginnt mit der Gefahr einer irreversiblen Überzuweisung. Sobald Adressen in Router-Konfigurationen, DNS, Zugriffsregeln, Anwendungseinstellungen, Kundensysteme und Dokumentation integriert waren, wurde die Rückgewinnung teuer. Es konnte nicht angenommen werden, dass eine große optimistische Zuweisung nach Fehlschlagen der Prognose sauber zurückgegeben würde. Kleinere anfängliche Zuweisungen begrenzten diese Exposition.

Der schrittweise Start begegnete der Informationsasymmetrie. Ein neuer Anbieter kannte seinen Geschäftsplan besser als ein Register, aber keine Partei konnte die zukünftige Kundennachfrage beobachten. Das Verfahren von RFC 2050 verwendete unmittelbaren Bedarf, überprüfte nachgelagerte Zuteilungen und wiederholte Anträge, um einen Teil der Prognoseunsicherheit durch beobachtete administrative Historie zu ersetzen. Dies konnte den Pool erhalten und die Registrierungsgenauigkeit verbessern.

Die klassenlose Zuweisung korrigierte eine schwerwiegende Größenfehlanpassung. Die Wahl zwischen 254 und 65.534 gewöhnlichen Identifikatoren war für Netzwerke mittlerer Größe schlecht geeignet. Zusammenhängende Präfixe konnten sich dem Bedarf besser annähern als eine native Klasse B, während eine willkürliche Sammlung nicht zusammenhängender Klasse-C-Netzwerke vermieden wurde.

Aggregation betraf eine separate gemeinsame Ressource. Die Routenbeobachtungen von Januar und Dezember 1992 zeigten trotz der nicht abgeglichenen Zwei-Jahres-Prognose der RFC schnelles Wachstum in einer konkreten Tabelle von MERIT. Anbieteraggregate konnten die Anzahl der von fehlerfreien Routern transportierten Ziele reduzieren. Der Gewinn hing von Topologie, Software und Kooperation ab, war aber technisch substantiell.

Die Anbieterhierarchie folgte aus dieser Aggregationslogik. Wenn ein Kunde Adressen aus dem Block seines Anbieters verwendete, konnte sich der Rest des Internets oft auf das Aggregat des Anbieters verlassen. Portabler Raum verringerte die Abhängigkeit von einem einzelnen Anbieter, konnte aber eine separate globale Route erfordern. Das breitere Netzwerk, nicht nur der Kunde und das Register, trug den mit dieser Route verbundenen Zustand.

Dokumentation diente auch mehr als der Erhaltung. Zuteilungsaufzeichnungen erleichterten Erreichbarkeit, Reverse-DNS, Vermeidung doppelter Zuteilungen und Überprüfung der nachgelagerten Nutzung. Ein Antragsteller, der zusätzliche Kapazität beantragte, hatte Informationen, die das Register nicht hatte. Eine gewisse Überprüfung war daher rational, selbst wenn jedes Verfahrensdetail anfechtbar war.

Die Ausnahmebefugnis konnte verhindern, dass eine numerische Regel ihrem technischen Zweck zuwiderlief. Multihoming, ungewöhnliche Topologie, Gerätebeschränkungen oder ein großer direkter Bedarf konnten einen standardmäßigen Block ungeeignet machen. Eine Einzelfallbehandlung erlaubte dem Register, Umstände zu berücksichtigen, die ein einfacher Host-Prozentsatz nicht erfassen konnte.

Diese Überlegungen begründen ernsthafte technische Argumente für Erhaltung, Aggregation, Registrierung, schrittweisen Start und umsichtiges Urteil. Ein gleichförmiges System großer bedingungsloser Zuweisungen hätte die knapp gewordenen Klassen­einheiten schneller verbrauchen können. Ein gleichförmiges System kleiner unabhängig gerouteter Zuweisungen hätte die fehlerfreien Tabellen aufblähen können. Ein systemloses System hätte doppelte Zuteilungen und vergleichende Bedarfsbewertung erschwert.

Diese Verteidigung belegt keine institutionelle Einzigartigkeit. Sie zeigt nicht, dass der 24-Monats-Horizont der optimale Prognosehorizont war, dass die ISP-Nachschubperiode von RFC 2050 die kombinierten Kosten von Register und Antragsteller minimierte, dass ein einziges regionales Register die einzig lebensfähige Struktur war oder dass die hierarchische Berufung einer teilweise unabhängigen Überprüfung überlegen war. Die technischen Beweise stützen die Ziele und einige Mechanismen. Daten über Antragsteller, Routing, Personal und Ergebnisse wären erforderlich, um vollständige Designs zu bewerten.

Ein begrenzter Vergleich bis 1996 verortet die Autorität, nicht die Ergebnisse

Ein nützliches Kontrafaktum kann auf November 1996 festgelegt werden, als RFC 2050 veröffentlicht wurde. Halten wir die 32-Bit-IPv4-Felder, die damaligen installierten klassenlosen und klassengebundenen Hinterlassenschaften, die damals verfügbaren BGP-4-Spezifikationen, begrenzte Router-Ressourcen, unsichere Nachfrage, teure Renummerierung und das Fehlen einer sofortigen universellen Umstellung auf IPv6 konstant. Nehmen wir keine universelle Einführung von BGP-4, NAT oder privaten Adressen an, da die zitierten Spezifikationen keine Adoption messen.

Beginnen wir mit der dokumentierten Basis: anbieterorientierte Zuweisung, schrittweiser Start für neue ISPs, zusätzliche Kapazität zur Deckung von etwa drei Monaten Zuteilungen, Nutzungstests für Endkunden, Einzelfallausnahmen, Prüfbefugnis des Registers und Berufung beim übergeordneten Register.

Variieren wir nun analytisch drei institutionelle Parameter.

Die erste Variation ändert das Nachschubintervall. Ein ISP könnte genug erhalten, um sechs Monate statt etwa drei Monate abzudecken. Dies ist kein dokumentierter historischer Vorschlag. Es ist nur unter der Annahme administrativ plausibel, dass das übergeordnete Register einen größeren zusammenhängenden Block dimensionieren konnte, ohne Paketformate zu ändern, und dass die Anbieterprognosen ausreichend glaubwürdig waren. Der wahrscheinliche Effekt auf die Autorität ist eine Verringerung der Anzahl der Transaktionen mit dem Register und eine geringere Abhängigkeit von schnellem Nachschub.

Das wahrscheinliche Risiko für die Erhaltung ist eine größere ungenutzte Kapazität, wenn das Wachstum ausbleibt. Ohne Antragshistorien, Prognosefehler und Zuteilungsdaten kann keine dieser Größenordnungen geschätzt werden.

Die zweite Variation behält den schrittweisen Start über drei Monate bei, veröffentlicht aber im Voraus Zuweisungsspannen und einen Standard-Nachweiszeitplan. Auch dies ist vom Analysten konstruiert. Sie setzt voraus, dass die Register über das Personal und die Aufzeichnungssysteme verfügten, um öffentliche Regeln aufrechtzuerhalten und gleichzeitig sensible Kundeninformationen zu schützen.

Sie könnte die Unsicherheit über die Dokumentation verringern und den Vergleich ähnlicher Fälle erleichtern, aber sie könnte zu strategischer Darstellung um die veröffentlichten Schwellenwerte anregen und die Flexibilität für ungewöhnliche Netzwerke verringern.

Die dritte Variation behält die technische Hierarchie bei, ändert aber die Überprüfung. Anfängliche Zuweisungs- und Prüfentscheidungen bleiben beim Register; ein Ausschuss, der nicht für die ursprüngliche Entscheidung verantwortlich ist, prüft schriftliche Ausnahmen und Ungültigkeitserklärungen. Keine direkte Quelle zeigt, dass ein solcher Ausschuss 1996 vorgeschlagen wurde. Die Variation ist nur administrativ denkbar, wenn das Registersystem Prüfer ernennen, vertrauliche Beweise unter Garantien teilen und ein zusätzliches Verfahren finanzieren konnte.

Sie verlagert einen Teil der Prüfungsautorität, ohne Adressbits hinzuzufügen oder die Routenaggregation zu ändern.

Eine breitere Variation der direkten Zuweisung kann ebenfalls beschrieben werden, aber ihre Annahmen sind schwerwiegender. Kleine Single-Homed-Organisationen könnten direkte regionale Blöcke erhalten und diese beim Anbieterwechsel behalten, vorbehaltlich eines vereinbarten weltweit akzeptierten Mindestpräfixes. Dieses Minimum, die Vereinbarung über die Routenakzeptanz und die administrative Kapazität sind alles analytische Parameter, keine gefundenen historischen Regeln. Dieses Design könnte die Kundenrenummerierung reduzieren, aber die Anzahl unabhängig sichtbarer Routen erhöhen.

Die zitierte Akte belegt nicht, dass Transitnetzwerke diese Routen akzeptiert hätten oder dass die damaligen Router die resultierende Tabelle hätten aufnehmen können.

Der Vergleich zeigt, wo Kosten und Ermessen liegen. Kurzer Nachschub legt mehr Transaktions- und Zeitplanrisiko auf den ISP, während die Exposition des Pools gegenüber Prognosefehlern begrenzt wird. Größere anfängliche Zuweisungen kehren einen Teil dieser Inzidenz um. Veröffentlichte Spannen tauschen Ermessen gegen Regeltransparenz. Ein separater Prüfer verlagert einen Teil der Korrekturbefugnis aus der ursprünglichen Entscheidungskette. Breitere Portabilität überträgt Kontinuität auf den Kunden und die Kosten des Routing-Zustands auf das breitere Netzwerk.

Sie kann nicht zeigen, welche Variation in großem Maßstab realisierbar war, wie viele Adressen jede verbrauchen würde, wie viele Routen jede generieren würde oder welche das Wohlbefinden verbessern würde. Eine Kalibrierung würde Antragstellernachfragen, bewilligte und abgelehnte Beträge, Bearbeitungszeiten, Prognosefehler, Anbieter-Routing-Richtlinien, Router-Kapazität, Personalkosten, Renummerierungsergebnisse, Prüfakten und vergleichbare Nutzungsbeobachtungen erfordern. Diese fehlen.

Die evidenzbasierte Schlussfolgerung ist daher enger: RFC 2050 selbst belegte keine institutionelle Einzigartigkeit ihres Designs. Sie dokumentierte die damalige Registerpraxis, gab ein zeitgenössisches technologisches Urteil ab und beschrieb Regeln, die konkurrierende Ziele in Einklang bringen sollten. Die analytischen Variationen identifizieren in diese Regeln eingebettete Entscheidungen. Sie belegen keine überlegene Leistung.

Vier Schlussfolgerungen mit unterschiedlichem Vertrauensniveau

Die architektonische Tatsache ist die stärkste. RFC 791 legte jedes IPv4-Quell- und Zielfeld auf 32 Bit fest. Das Ergebnis waren 2^{32} nominale Werte pro Feld, kein unbegrenzter Namensraum und keine 4.294.967.296 zuweisbaren öffentlichen Hosts.

Die klassenbezogenen und Routing-Folgen sind ebenfalls gut belegt. Die großen Unterschiede zwischen den gewöhnlichen Host-Kapazitäten von Klasse C und Klasse B machten mittelgroße Zuweisungen ineffizient. Mehrere Klasse-C-Netzwerke konnten eine Klasse-B-Netznummer bewahren, aber Routen hinzufügen. Die MERIT-Tabelle in RFC 1519 dokumentierte 4.526 angekündigte Routen im Januar 1992 und 8.561 im Dezember 1992.

Ihre Prognose von etwa 30.000 in zwei Jahren kann nicht aus der angegebenen Verdopplungsformel reproduziert werden, aber die zugrunde liegende Sorge um Routenwachstum und Klassengranularität hing nicht allein von diesem arithmetischen Fehler ab.

Die administrativen Entscheidungen sind identifizierbar. Gerichs Informations-RFC empfahl 24-Monats-Prognosen, Schwellenwerte, geografische Aufteilungen, Prüfungen und Einzelfallausnahmen. Die CIDR-Autoren verknüpften Zuweisung mit Anbietertopologie und klassenloser Aggregation. Hubbard, Kosters, Conrad, Karrenberg und Postel dokumentierten den schrittweisen Start, die Hierarchie, nutzungsbasierte Tests auf verbundene Hosts, Prüfbefugnis, Ungültigkeitserklärung, Rückgabe und hierarchische Berufung von BCP 12. Die IANA, regionalen und lokalen Register, Anbieter und Transitnetzwerke hatten unterschiedliche Umsetzungsrollen.

Die IESG akzeptierte RFC 2050 als getreue Darstellung der damaligen Praxis, lehnte es jedoch ab, die Richtlinie zu billigen.

Die Gesamtergebnisse bleiben ungelöst. Zuweisungsregister enthalten nicht den Antragsnenner. Die zitierten Quellen offenbaren nicht alle Ablehnungen, Kürzungen, Rückzüge, informellen Ratschläge, Verzögerungen, Prüfabhilfen, Rückgaben, Ausnahmen oder Berufungsergebnisse. Spätere Registerdaten enthalten übernommene und rekonstruierte Daten. Kein zitierter zeitgenössischer Datensatz misst die universelle Einführung von BGP-4, die vollständige Adressbelegung, die vergleichbare Antragstellerbelastung oder den kausalen Beitrag eines einzelnen Schwellenwerts zur Erhaltung.

Der Titel kann diese Unterscheidungen tragen. Das endliche Feld war technisch. Die klassengebundene Zuweisung und der Routerzustand erzeugten echten technischen Druck. Das Rationierungsregime war politisch im engen, evidenzbasierten Sinne, dass identifizierbare Institutionen die Prognosehorizonte, Zuweisungsstufen, Hierarchien, Beweistests, Ausnahmebefugnisse und Rechtsmittel unter Zwängen wählten, die keine einzige vollständige administrative Verfassung vorschrieben.

Technische Notwendigkeit rechtfertigte kollektives Handeln. Sie bestimmte nicht allein, wer den Bedarf definierte, vertrauliche Beweise hielt, Ausnahmen gewährte, Konsequenzen verhängte oder über die endgültige Berufung entschied.