Zusammenfassung

  • RFC 1380 trennte sofortige Betriebsmaßnahmen, kurzfristiges CIDR, eine mittelfristige Antwort auf Adressknappheit und langfristige Internet-Layer-Arbeit. Alle vier sollten sofort starten, nicht nacheinander.
  • CIDR sollte im bestehenden Adressraum Zeit kaufen, brauchte aber Policy, Protokoll, Implementierung und Deployment. Die Arbeit konnte Ressourcen von der dauerhaften Lösung abziehen.
  • Empfehlung, verlangsamtes Wachstum, Übergangsplan, Architekturwahl und Betriebsergebnis sind verschiedene Nachweise unter verschiedener Verantwortung.

Drei Probleme liefen mit unterschiedlicher Geschwindigkeit

RFC 1380 unterschied die Knappheit von Class-B-Netznummern, die Explosion der Routingtabellen und eine spätere Erschöpfung des 32-Bit-Adressraums. Mehrere Class-C-Netze konnten eine Class B sparen und zugleich mehr Routen erzeugen. Größere Router verschoben die Hardwaregrenze, nicht die Ursache des Wachstums. Ein größerer Adressraum ohne Aggregation vergrößerte womöglich nur das alte Routingproblem.

Auch die Routinggrenze hatte zwei Formen. Speicher, Rechenleistung und Update-Bandbreite belasteten Geräte; Konfiguration und Kontrolle der gewünschten Pfade belasteten Menschen. Die ungefähr jährliche Verdopplung von Zuteilungen und Einträgen in der Merit-NSFNET-Datenbank war eine datierte Beobachtung. Sie war keine Vollerhebung aller Router und keine Bestätigung einer Prognose.

ROAD bereitete Entscheidungen vor

ROAD war eine einmalige Sondergruppe, keine dauerhafte gewöhnliche IETF Working Group. Sie tagte nach Santa Fe, arbeitete persönlich und per E-Mail, berichtete in San Diego und leitete Aufgaben in BOFs, offene Plenarsitzungen und künftige Gruppen weiter.

Damit war auch ihre Autorität begrenzt. ROAD konnte Probleme ordnen und Arbeit empfehlen, besaß aber nicht jede spätere Adressvergabe, Norm, Implementierung oder lokale Migration. RFC 1380 ist Informational und nennt sich vorläufiger Bericht der IESG-Beratungen. Das Dokument belegt eine Prozessstufe, keinen Internet Standard und keine Ausführung.

Für die nahe Routingfrage gab es mit CIDR eine Richtung. Für größere Adressen gab es noch keine endgültige Auswahl. Übergang, Infrastrukturwirkung, Change Control, Schulung und Implementierungserfahrung waren nicht hinreichend untersucht. Dringlichkeit ersetzte diese Belege nicht.

Die Phasen standen nicht in einer Warteschlange

Eine einzige Architektur konnte die nahen Routingprobleme, Adressknappheit und fortgeschrittene Funktionen nicht gleichzeitig lösen und rechtzeitig ausgewählt, gebaut und ausgerollt werden. Ein neuer Internet Layer musste zudem eine große installierte Basis überwinden.

Das IESG nannte vier Horizonte: immediate, short-term, mid-term und long-term. Die Namen klingen sequenziell. RFC 1380 ordnete jedoch an, alle sofort zu beginnen; eine aufeinanderfolgende Bearbeitung war unbezahlbar.

Dringlichkeit bedeutete somit nicht, sämtliche Fachleute an den nächsten Engpass zu schicken. Jeder Horizont brauchte einen verantwortlichen Start. Wartete die Zukunftsarbeit auf das Ende des Provisoriums, sammelte dieses zuvor Nutzer, Werkzeuge, Budgets und Abhängigkeiten. Die Brücke wurde selbst zur installierten Basis.

Sofort war nicht gleich gelöst

Konservativere Vergabe, Ausrichtung auf Aggregation, Rückgewinnung ungenutzter Class B, leistungsfähigere Router und Topologiearbeit verlangten kein neues Protokoll. Das Memo sagte ausdrücklich, diese Schritte lösten keines der Probleme; sie verlangsamten lediglich deren Eintritt.

Eine strengere Regel belegt eine Policy-Änderung. Eine Rückgabe belegt eine bestimmte Ressource. Ein Upgrade belegt lokale Kapazität. Eine kleinere Tabelle belegt Entlastung an einem Beobachtungspunkt. Keiner dieser Nachweise beendet allein Adressknappheit, menschliche Last oder Übergangsrisiko.

Die Maßnahmen verlagern Kosten: Antragsteller liefern mehr Nachweise, Registries urteilen mehr, Betreiber kaufen Geräte. Topologievereinfachung kann alternative Pfade kosten. Dass Hostsoftware unverändert bleibt, macht eine Intervention nicht institutionell neutral.

CIDR war eine Kette von Zuständigkeiten

RFC 1338 beschrieb Supernetting als kurzfristige Brücke, welche Class-B- und Tabellenprobleme verlangsamen sollte, bis eine langfristige Lösung reifte. Die erwarteten drei Jahre waren Planungsannahme, keine Garantie.

Der Nutzen verlangte aggregierbare Vergabe, Inter-Domain-Protokolle für Netz-Masken-Paare, Routersoftware und Grenzen zu alten Domains und IGPs. Multihoming und Providerwechsel erhielten spezifische Routen. Zuteilung ohne classless Routing konnte das Tabellenwachstum zeitweise sogar beschleunigen.

RFC 1380 verteilte daher den Arbeitsplan: operative Adressplanung, BGP-Erweiterungen, mögliches IDRP und Deployment-Vorbereitung. CIDR sollte im bestehenden Schema Zeit kaufen. Es war weder ein Schalter noch kostenlos.

RFC 1519 revidierte später die CIDR-Spezifikation und behielt den Brückencharakter. Eine Dokumentrevision beweist keine Einführung, Topologie oder Wirkung.

Die Brücke beanspruchte ihr Ziel

Der erste sichtbare Preis war der Übergang. Ersatz oder Erweiterung des Internet Layer wäre für Hersteller, Betreiber und Nutzer traumatisch. Kurz- und mittelfristige Entscheidungen sollten diesen Bruch mindern oder einen glatten Pfad zur Zukunft bewahren.

Der zweite Preis war Opportunität. Entwicklung und Deployment des Provisoriums zogen Ressourcen aus anderen Vorhaben ab, ausdrücklich auch aus der Langfristlösung. Ingenieure, Testnetze, Change Windows und Aufmerksamkeit lassen sich nicht doppelt ausgeben.

Gewonnene Zeit gehört deshalb neben verbrauchte Fähigkeit. Achtzehn Monate neue Luft bei zwei Jahren gebundener Migrationsmannschaft können lokal gut und strategisch schlecht sein. RFC 1380 maß dieses spätere Verhältnis nicht; es verlangte, die Umleitung vor der Auswahl zu berücksichtigen.

Größere Adressen verlangten eine andere Akte

Ohne ausreichende Übergangsbelege gab das IESG keine endgültige Empfehlung. RFC 1380 verlangte Analysen zu Infrastruktur, bestehenden Protokollen, Routing, Vergabe, Leistung, Eigentum am Change Control, Management, Sicherheit und Schulung. Appendix B forderte Antworten Punkt für Punkt und dokumentierte Implementierungserfahrung.

Aufruf, Internet-Draft, öffentliche Prüfung, Präsentation, IESG-Empfehlung und IAB-Entscheidung waren getrennte Akte. Ein Zeitplan weist Lieferung und Verantwortung zu; er bestätigt nicht vorab die richtige Architektur.

RFC 1719 hielt später fest, dass der IPDecide BOF vor allem fehlende Richtung zeigte. Das IESG sollte in einem vorab veröffentlichten offenen Verfahren empfehlen und Dringlichkeit aus Vergaberaten, Policy, erwartetem CIDR-Gewinn sowie Entwicklungs-, Feld- und Migrationszeit bestimmen.

RFC 1752 dokumentierte 1995 einen neuen Akt: überarbeitetes SIPP wurde als IPng-Basis empfohlen, Protokoll, Autokonfiguration, Übergang und Koexistenz erhielten getrennte Arbeit, und Versionsnummer 6 hieß IPv6.

Diese Folge macht RFC 1380 nicht zur versteckten IPv6-Auswahl. Sie zeigt, dass weitere Belege, ein neuer Prozess und eine neue verantwortliche Empfehlung nötig waren. Auch diese beweist keine universelle Migration, Stilllegung von IPv4 oder Betriebserfolg.

Quellen und Grenzen

Der Artikel stützt sich auf die offiziellen RFC 1338, 1380, 1519, 1719 und 1752. Sie belegen damalige Diagnosen, Empfehlungen, Kriterien und Dokumentfolge. Sie belegen kein heutiges Netz, keine Genauigkeit jeder Prognose, keine pünktliche Erfüllung jedes Meilensteins, kein bestimmtes Produkt, keine autorisierte lokale Änderung und kein gemessenes Ergebnis.

Der begrenzte Schluss lautet: Dringende Entlastung und dauerhafter Ersatz waren 1992 schon getrennte Arbeiten, die zugleich beginnen mussten. Jede Zwischenlösung brauchte drei Konten — Nutzen, Ressourcenverbrauch und Ausstieg. Sonst blieb die gekaufte Zeit sichtbar, während die verbrauchte Zukunft verschwand.