Zusammenfassung

  • 2001 erlaubte 6to4, aus einer global eindeutigen IPv4-Adresse ein IPv6-Präfix unter 2002::/16 abzuleiten und IPv4-Netze zu queren, ohne jeden Tunnel vorab auszuhandeln.
  • Anycast ließ das Relay später automatisch erscheinen. Hin- und Rückweg konnten aber von verschiedenen Betreibern ohne gemeinsame Verantwortung abhängen. Filter, schlechte Routen und standardmäßige Aktivierung machten Bequemlichkeit zur wiederkehrenden Störung.
  • RFC 7526 setzte 2015 den Anycast-Relay-Mechanismus außer Gebrauch. Weder das grundlegende Unicast-6to4 noch 2002::/16 wurden damit verworfen — eine Grenze, die beim Lesen des heutigen Registers wichtig bleibt.

Eine Adresse vor der Vereinbarung

Der einprägsamste Teil von 6to4 ist eine Rechenoperation. Die 32 Bit einer global eindeutigen IPv4-Adresse werden hinter das Präfix 2002 gesetzt, und ein Standort erhält ein /48. RFC 3056 schrieb das als 2002:V4ADDR::/48. Ein Netz ohne natives IPv6 konnte intern Adressen daraus vergeben. Am Rand verpackte ein 6to4-Router das IPv6-Paket mit dem IPv4-Protokoll 41 direkt in IPv4.

RFC 3056 erschien im Februar 2001 und bezeichnete 6to4 als optionalen Übergangsmechanismus, nicht als dauerhafte IPv6-Architektur. Das Versprechen war enger und praktisch: Standorte konnten über das IPv4-Internet kommunizieren, ohne für jeden Partner einen Tunnel zu konfigurieren und ohne zunächst für diesen Zweck ein gewöhnliches IPv6-Präfix zu erhalten. Die IPv4-Adresse war Material und Wegweiser zugleich.

Die Bequemlichkeit hatte von Beginn an Grenzen. Eine private IPv4-Adresse konnte kein weltweit gültiges 6to4-Präfix liefern. Änderte sich die IPv4-Adresse, änderte sich auch das abgeleitete IPv6-Präfix. Zudem musste weiterhin jemand Pakete zwischen der 6to4-Welt und nativem IPv6 transportieren. Automatisiert war die Adressbildung, nicht die allgemeine Erreichbarkeit.

Das Relay, das aus dem Blick verschwand

Zwischen zwei 6to4-Standorten zeigte die eingebettete IPv4-Adresse der Gegenseite, wohin der Tunnel gehörte. Zwischen 6to4 und einem nativen IPv6-Ziel war dagegen ein Relay nötig, das beide Welten verstand.

RFC 3068 lieferte eine verblüffend einfache Antwort: Relay-Router teilten sich die IPv4-Anycast-Adresse 192.88.99.1. Der 6to4-Router schickte den Verkehr dorthin, und gewöhnliches IPv4-Routing wählte ein Relay, das die Route ankündigte. Nutzer mussten kein bestimmtes Gateway mehr finden oder konfigurieren. Ein Mechanismus mit betrieblichem Abstimmungsbedarf fühlte sich nun wie ein Schalter an.

Der Schalter verbarg eine Asymmetrie. Das Relay für den Hinweg musste nicht den Rückweg tragen. Ein natives IPv6-Netz konnte für 2002::/16 ein anderes Relay unter einem anderen Betreiber und einer anderen Routingpolitik wählen. Beide Relays mussten voneinander nichts wissen. Der Erfolg hing von kompatiblen Diensten mehrerer Organisationen ab; der Mechanismus schuf weder einen Vertrag zwischen ihnen noch einen Verantwortlichen für die gesamte Rundreise.

Am Adressformat war das nicht zu erkennen. Eine exakt nach Dokument erzeugte 6to4-Adresse konnte auf eine Firewall treffen, die Protokoll 41 verwarf, auf eine fehlende Relay-Route, ein schlecht platziertes Relay oder einen Rückweg ins schwarze Loch. Das Präfix konnte korrekt sein und die Verbindung dennoch scheitern.

Wie der Rückfall die Rechnung verbarg

RFC 3964 von 2004 konzentrierte sich auf Sicherheit. Ein Relay sollte prüfen, ob die IPv4-Quelle des Tunnels zur IPv4-Adresse in der 6to4-Quelle passte. Ohne Filterung konnte gefälschter Verkehr reflektiert, durch das Übergangssystem verschleiert oder schwerer zugeordnet werden. Das Dokument behauptete nicht, jedes Relay sei feindlich. Es zeigte, dass automatische Kapselung Vertrauensgrenzen überschritt, die eine Adresse allein nicht kontrollieren konnte.

2011 konnte RFC 6343 eine breitere Betriebsgeschichte beschreiben: Filter gegen Protokoll 41, fehlende oder unerreichbare Relays und Wege, die nur in einer Richtung funktionierten. Das Dokument zitierte damalige Experimente mit 6to4-Verbindungsfehlern von ungefähr 9 bis 20 Prozent. Das war keine weltweite Vollerhebung, aber genug, um eine Übergangshilfe zu einem sichtbaren Zuverlässigkeitsproblem zu machen.

Die Kosten verschwanden oft nur aus dem Blick. Eine Dual-Stack-Anwendung konnte IPv6 versuchen, auf das Scheitern von 6to4 warten und schließlich auf IPv4 zurückfallen. Für den Nutzer wirkte die Seite bloß langsam. Softwareanbieter hatten daher einen Grund, funktionierende native Wege zu bevorzugen und Alternativen gegeneinander antreten zu lassen, wie später bei Happy Eyeballs. Jede Schicht verringerte ihr Symptom, ohne die fehlende Verantwortung für das Relay-System zu ersetzen.

Die Aktivierung als Voreinstellung verlängerte das Muster. Wer 6to4 nie angefordert hatte, konnte vom Betriebssystem oder Randgerät trotzdem eine abgeleitete Adresse und eine scheinbare IPv6-Route erhalten. RFC 6343 nannte das schlechte Praxis und empfahl, 6to4 standardmäßig zu deaktivieren. Die Umkehr war bezeichnend: Was wegen geringer Abstimmung attraktiv gewesen war, sollte nur noch durch eine informierte Entscheidung eingeschaltet werden.

Den Umweg verwerfen, nicht die Geschichte

RFC 7526 formalisierte im Mai 2015 den Rückzug. Der Anycast-6to4-Mechanismus wurde außer Gebrauch gesetzt, RFC 3068 und das verwandte RFC 6732 erhielten den Status Historic, und die Anycast-Routenankündigung sowie der Relay-Dienst unter 192.88.99.1 sollten enden. Implementierungen sollten 6to4 standardmäßig abschalten. Der öffentliche Umweg galt nicht länger als empfohlene Übergangsinfrastruktur.

Der Umfang dieser Entscheidung wird leicht verwischt. RFC 7526 erklärte ausdrücklich, dass der grundlegende Unicast-Mechanismus aus RFC 3056 und das Präfix 2002::/16 nicht außer Gebrauch gesetzt wurden. Im aktuellen IANA-Register für besondere IPv6-Adressen ist der Block weiterhin als 6to4 verzeichnet. Ein Registereintrag dokumentiert eine architektonische Zuweisung; er verspricht keinen verfügbaren oder ratsamen öffentlichen Relay-Weg.

Darum endet diese Geschichte nicht mit einer Löschung. Der Standardisierungsprozess konnte eine Betriebsempfehlung zurücknehmen und zugleich das Vokabular bewahren, um alte Adressen, verwaltete Anordnungen und Restsysteme zu erkennen. 2002::/16 ist heute ein Hinweis auf den Mechanismus, nicht darauf, dass sein Anycast-Dienst die Überprüfung überstanden hätte.