Zusammenfassung

  • RFC 1897 verband die ASN des Providers, einen Teil des bestehenden IPv4-Netzes, das Standort-Subnetz und die Schnittstellenkennung in einer Testadresse und kündigte zugleich Rücknahme und Renummerierung an.
  • RFC 2471 verschob das 6bone in den Präfix 3FFE::/16. Register, BGP4+-Routen und pTLA-Pflichten machten daraus einen ernsthaften Betrieb, aber keine dauerhafte Produktionsberechtigung.
  • RFC 3701 stoppte neue Zuteilungen und setzte den 6. Juni 2006 als Enddatum. Die Rückgabe an IANA beendet den Zuteilungsnachweis; verschwundene Altlasten müssen gesondert belegt werden.

Geliehen hieß nicht wirkungslos

RFC 1897 wies Adressen für Tests mit IPv6-Prototypen zu. Sie durften für diesen Zweck geroutet werden, aber nicht als gewöhnlicher Internet-Adressraum. Der Text nannte sie ausdrücklich temporär, kündigte ihre Rücknahme an und verpflichtete die Nutzer zu einer späteren Renummerierung.

Diese Einschränkungen beschrieben die Reichweite der Erlaubnis, nicht die Leistungsfähigkeit der Technik. Ein Standort konnte eine Adresse erhalten, konfigurieren und in einem Register dokumentieren. Ein Nachbar konnte die Route annehmen, der Datenpfad Pakete transportieren und eine Anwendung antworten. Jeder Schritt belegt etwas anderes. Keiner macht aus einer Versuchszuteilung Eigentum oder ein unbegrenztes Produktionsrecht.

Die Adresse selbst barg mehrere Abhängigkeiten. Ihr Format enthielt die 16-Bit-ASN des aktuellen Providers, die oberen 24 Bit des routbaren IPv4-Netzes des Teilnehmers, ein 16-Bit-Subnetzfeld und eine 48-Bit-Schnittstellenkennung. Reichte der IPv4-Präfix über 24 Bit hinaus, wanderten die restlichen Bits ins Subnetzfeld. Als Schnittstellenkennung diente nach Möglichkeit eine IEEE-MAC-Adresse.

Damit verdichtete eine einzige Zahl Providerbeziehung, IPv4-Topologie, physischen Link und Schnittstellenidentität. Das beschleunigte den Einstieg, weil Bekanntes wiederverwendet wurde. Zugleich war die spätere Umzugsrechnung ablesbar: Änderten sich Provider, IPv4-Kontext, Link oder Adressarchitektur, mussten alle abhängigen Einträge mitziehen.

Die Architektur zog weiter, also zog der Versuch um

RFC 1884 legte die frühe 128-Bit-Adressarchitektur für IPv6 fest. RFC 1887 skizzierte eine providerorientierte Hierarchie, in der Adressen Topologie ausdrücken und die Routinglast begrenzen sollten. Auf dieser Grundlage entstand RFC 1897.

Die allgemeine Architektur entwickelte sich jedoch weiter. RFC 2374 führte ein aggregierbares Format mit TLA-, NLA- und SLA-Ebenen ein und trennte öffentliche von standortinterner Topologie. RFC 2471 erklärte deshalb RFC 1897 für überholt und vergab an das 6bone die TLA-ID 0x1FFE, aus der 3FFE::/16 entstand.

Auch diese zweite Zuteilung blieb befristet. RFC 2471 wiederholte Rücknahme und künftige Renummerierung. Die NLA-Hierarchie sollte Transitnetze und Endstandorte im 6bone abbilden; die interne Struktur blieb Sache der Organisation. Formale Gültigkeit im neuen Schema belegte die Position im Testnetz, nicht einen Anspruch nach dessen Ende.

RFC 3701 berichtete später, der Wechsel vom ursprünglichen 5F00::/8 zu 3FFE::/16 sei mit wenigen Problemen verlaufen. Das ist ein zeitgenössisches Urteil über eine koordinierte Migration, aber keine Vollerhebung. Es sagt weder, dass jedes Gerät erfasst wurde, noch dass DNS, Tunnel, ACLs und Anwendungen kostenlos umzuziehen waren.

Betriebsreife adelte die Versuchserlaubnis nicht

Das 6bone war mehr als ein reservierter Nummernblock. RFC 2546 und RFC 2772 beschrieben BGP4+, Aggregation, Filter, DNS, ein Register im RIPE-181-Stil, Kontakt- und Policy-Objekte sowie Pflichten der pTLA-Betreiber. Die Teilnahme war freiwillig und auf Wohlwollen gestützt; die Verantwortung für Scope, Leaks und falsche Ankündigungen war dennoch konkret.

Gerade diese Praxis machte den Versuch aussagekräftig. Ein Registerobjekt dokumentierte erklärte Zuständigkeit. Eine BGP-Sitzung dokumentierte den Austausch von Erreichbarkeit. Eine akzeptierte Route dokumentierte eine Kontrollentscheidung. Pakettransport und Anwendungserfolg verlangten weitere Beobachtungen. Selbst zusammen änderten sie die Rechts- und Betriebsklasse des Präfixes nicht.

Die Beweiskette lautet daher: Spezifikation, Delegation, Konfiguration, Routingpolitik, Kontrollpfad, Weiterleitung und Anwendung. Beim Rückbau folgt eine zweite Kette: Ersatz unter Produktionsautorität beschaffen, installieren, DNS und Tunnel umstellen, Zugriffskontrollen und Dokumentation ändern, Altpfad zurückziehen und verbleibende Verweise testen.

Ein Datum machte aus der Warnung einen Vollzug

Als reguläre IPv6-Zuteilungen verfügbar waren, drohte ein dauerhaftes Testnetz zum parallelen System zu werden. RFC 3701 stoppte neue pTLA-Zuteilungen zum 1. Januar 2004 und setzte den 6. Juni 2006 als Auslaufdatum. Danach sollten 6bone-Präfixe in keiner Form mehr im Internet verwendet werden; Betreiber durften sie filtern. IANA sollte 3FFE::/16 zurücknehmen.

Der Plan versprach ehemaligen Teilnehmern weder einen bestimmten Produktionspräfix noch eine automatische Umwandlung. Ersatz musste aus dem zuständigen regulären Verfahren kommen. Das Dokument hielt außerdem fest, dass die Charta der früheren Arbeitsgruppe die Aufsicht über das 6bone nicht mehr umfasste, und wählte den IETF-Prozess als Ort der Stilllegung. Das belegt einen Governance-Weg, nicht die individuelle Zustimmung jedes Teilnehmers.

RFC 5156 verzeichnete später 5F00::/8 und 3FFE::/16 als an IANA zurückgegeben; bis zu einer Neuzuteilung sollten sie nicht im öffentlichen Internet auftauchen. Damit war das Zuteilungskonto geschlossen. Doch ein Registereintrag löscht keine Literale aus Quellcode, DNS, Firewalls, Logs oder Handbüchern. Administrative Rückgabe und operative Tilgung brauchen verschiedene Belege.

Quellen