Zusammenfassung

  • Die spätere IPv6-Basis war eine überarbeitete Fassung von SIPP. Kritik am IPAE-Übergang und an der Tragfähigkeit des 64-Bit-Adressraums führte zu neuen Entwurfsentscheidungen.
  • RFC 1752 empfahl das überarbeitete SIPP mit festen 128-Bit-Adressen als Grundlage für IPng. Der Bericht dokumentiert eine Mehrheitsabwägung, keine Einstimmigkeit oder sofortige Umstellung.

Ein Gewinner, zusammengesetzt aus mehreren Arbeiten

Wer eine technische Auswahl im Nachhinein betrachtet, sieht oft einzelne Kandidaten in einer Rangliste. RFC 1752 legt eine andere Perspektive nahe: Das empfohlene Design nahm Gestalt an, während die IETF bereits an mehreren Lösungswegen arbeitete. CATNIP, SIPP und TUBA wurden anhand technischer Kriterien verglichen. Keiner der Entwürfe war frei von Problemen. CATNIP galt als zu unvollständig; bei SIPP und TUBA sahen die Prüfer jeweils brauchbare Elemente, aber auch Mängel, die vor einer langfristigen Nutzung behoben werden mussten. RFC 1752, §§1, 7–8

Die Geschichte von SIPP verlief selbst über Zusammenführungen. Frühere Ansätze wie SIP und IPAE wurden gebündelt; später kamen weitere Arbeiten hinzu. Das SIPP-Whitepaper von 1993 beschrieb ein schlankes IP mit 64-Bit-Adressen, die über Routingoptionen erweitert werden konnten. Das sollte den Sprung von IPv4 erleichtern, ließ aber zwei Fragen offen: Wie zuverlässig war der Übergang im Betrieb, und wie viel Hierarchie ließ sich in 64 Bits unterbringen? RFC 1710

Die erste Frage betraf IPAE. Die Prüfer hielten den Mechanismus für komplex und zweifelten daran, dass er in einem realen, heterogenen Internet zuverlässig funktionieren könnte. Bei der zweiten Frage gab es keine geschlossene Front. Ein Teil der Teilnehmenden hielt 64 Bits für ausreichend; andere rechneten mit ineffizienter Adressvergabe und künftigen Routinghierarchien, für die der Raum nicht reichen könnte. Unbehagen löste zudem die Idee aus, erweiterte Adressen über Loose Source Routing abzubilden. RFC 1752, §8.2

Das ist ein wichtiger Unterschied: Die Aktenlage zeigt keinen Beweis, dass ein 64-Bit-Design technisch nicht funktioniert hätte. Sie zeigt, dass die Prüfer für eine dauerhafte globale Architektur eine Reserve an Hierarchie verlangten, die sich nicht zuverlässig aus damaligen Annahmen ableiten ließ. Der Streit drehte sich deshalb um Prognosen, Zuteilungseffizienz und Routingkomplexität – nicht um eine einzige Rechenaufgabe.

Aus einer Kandidatenwahl wird eine Synthese

Auf dem IPng-Treffen am 19. und 20. Mai 1994 nahe Chicago wurden die Schwächen der Ansätze diskutiert. Steve Deering und Paul Francis, zwei SIPP-Vorsitzende, schlugen anschließend eine Revision vor. Sie ersetzten die 8-Byte-Adresse durch eine feste Länge von 16 Bytes. Hinzu kamen optionale serverlose Autokonfiguration, die vollständige Nutzung der 16 Bytes in höheren Verbindungskennungen und der Verzicht auf den Route Header zur Adresserweiterung. RFC 1752, §9

Damit wurde eine zuvor variable Ausweichmöglichkeit durch eine explizite Architekturentscheidung ersetzt. Feste 128 Bits vereinfachten bestimmte Annahmen für Adresshierarchie und Netztopologie, erhöhten aber den Paketaufwand. Auf langsamen Verbindungen oder bei sehr großen Datenströmen ist das kein abstrakter Nachteil. RFC 1752 stellt die Gegenargumente zur Länge dar und hält fest, dass technische Argumente auf beiden Seiten vorgebracht wurden.

Auch die überarbeitete Vorlage war eine Synthese. Der Protokollkern stammte größtenteils aus SIPP. TUBA beeinflusste Autokonfiguration und Übergang, die Adressstruktur bezog CIDR-Arbeiten ein, und Überlegungen aus SDRP wirkten auf den Routingheader. So wird verständlich, warum die Empfehlung nicht als Sieg eines isolierten Teams gelesen werden sollte: Die IETF konzentrierte die weitere Arbeit auf eine Basis, deren Bausteine mehrere Diskussionen aufgenommen hatten. RFC 1752, §9

Was die Empfehlung festlegte

Im Januar 1995 empfahlen die IPng-Area-Direktoren, die 128-Bit-Fassung von SIPP als Grundlage für IPng zu verwenden. Sie stellten ausdrücklich fest, dass über die Adresslänge keine Einstimmigkeit erreicht worden war. Nach ihrer Einschätzung sprach sich jedoch eine klare Mehrheit für feste 16 Bytes als Kompromiss zwischen Effizienz, Funktion, Flexibilität und globaler Anwendbarkeit aus. Das ist ein Bericht über die IPng-Gruppe, keine Abstimmung aller Netzbetreiber. RFC 1752, §§10.2–11

Eine „Grundlage“ ist außerdem kein fertiges Deployment. RFC 1752 forderte eine konzentrierte Standardisierungsarbeit und nannte weitere Aufgaben zu Übergang, Koexistenz, Autokonfiguration und Tests. Erst RFC 1883, veröffentlicht im Dezember 1995, spezifizierte IPv6 in einem eigenen Dokument. Auch danach blieb der tatsächliche Netzbetrieb eine getrennte Frage. RFC 1883

Die Abgrenzung zu RFC 1550 ist ebenso wichtig. Dieser hatte die Sammlung von Anforderungen vor der Auswahl zum Thema. Die spätere SIPP-Revision zeigt, was danach mit einem Kandidaten geschah, wenn Kriterien und technische Prüfung konkrete Einwände hervorbrachten. Inputs sammeln und Architektur ändern sind zwei verschiedene Funktionen im selben Prozess. RFC 1550

Spätere Interessen nicht in die damaligen Quellen hineinlesen

Eine größere Adressarchitektur beeinflusst Routing, Geräte, Verwaltung von Nummernressourcen und den Parallelbetrieb mit IPv4. Daraus entstehen wirtschaftliche und institutionelle Folgen. Die technischen RFCs belegen jedoch nicht von selbst, wer welche späteren Vorteile erhielt oder welche privaten Motive die Beteiligten 1994 hatten.

Heng Lu argumentiert 2026, dass spätere IPv6-Förderung mit Anreizen bei Regionalregistern und Geräteherstellern zusammenhängt. Diese Perspektive stellt die Erzählung einer neutralen technischen Unvermeidlichkeit infrage. Sie belegt aber nicht, dass solche Interessen die damalige SIPP-Änderung verursacht haben. Die zeitgenössischen Dokumente sprechen von Übergangssicherheit, Routinghierarchie, Adresslänge und einem nicht einstimmigen Kompromiss. Eine spätere politische Ökonomie ist eine zusätzliche Deutung, keine Ersatzquelle für die Motive der Beteiligten. Heng Lu, „Why IPv6 Was Pushed, and Who It Actually Serves“

Der historische Kern ist damit weder Unvermeidlichkeit noch eine unbelegte Absichtsthese. Die technische Auswahl veränderte den Kandidaten: Ein Übergangsmechanismus wurde infrage gestellt, eine feste Adresslänge eingeführt und Arbeit aus mehreren Projekten kombiniert. Die Empfehlung legte einen Ausgangspunkt fest, aber sie bewies nicht, dass die gewählte Architektur für jeden Betreiber günstiger wäre. Ihre Folgen mussten im späteren Betrieb sichtbar werden.

Quellen