Zusammenfassung

  • Ein 6rd-Kundenpräfix setzt sich aus dem IPv6-Präfix des Anbieters und ausgewählten Bits der IPv4-Adresse des Kundenrouters zusammen. Änderungen im alten Adressplan können deshalb die neue Dienstleistung verändern.
  • Eine vom Anbieter kontrollierte Domäne ist nicht mit einem einzigen zentralen Datenpfad gleichzusetzen. Kundenrouter derselben Domäne können direkt über IPv4 miteinander kommunizieren.
  • Zustandslose Weiterleitung beseitigt keine Betriebsverantwortung. Gemeinsame Konfiguration, passende Lebensdauern und die Übernahme erhaltener Präfixe ins native Routing bleiben eigenständige Aufgaben.

Zustandslos ist nicht voraussetzungslos

Eine Tabelle weniger im Relay ist ein handfester technischer Gewinn. Bei 6rd braucht der Grenzrelay keine Zuordnung für jeden einzelnen Datenfluss vorzuhalten. Die erforderlichen Informationen lassen sich aus Adressen ableiten. Das macht den Dienst attraktiv, wenn das Zugangsnetz noch IPv4 nutzt, Kunden aber bereits IPv6 erhalten sollen.

Doch was nicht mehr pro Datenfluss gespeichert wird, verschwindet nicht vollständig aus dem System. Ein Teil der Verbindlichkeit steckt nun im Adressplan und in Parametern, auf die sich die beteiligten Geräte einigen müssen. Die RFC 5969 beschreibt nicht nur einen Transportweg, sondern eine Abhängigkeit des IPv6-Kundenpräfixes von der IPv4-Adresse des Kundenrouters.

Diese Abhängigkeit wird sichtbar, wenn die IPv4-Adresse wechselt. Aus einer anderen Eingabe entsteht ein anderes IPv6-Präfix. Die Spezifikation weist darauf hin, dass dies in das Kundennetz hineinwirken und Dienste beeinträchtigen kann. Ein Fehler im Ableitungsverfahren ist dafür nicht erforderlich.

Die Aussage ist architektonisch. Für diesen Beitrag wurden weder ein Netz vermessen noch Ausfälle bei einem bestimmten Betreiber festgestellt. Die Quellen belegen den Zusammenhang, nicht seine heutige Häufigkeit oder einen bezifferten Schaden. Für die Unternehmensführung ist schon der Zusammenhang relevant: Wer IPv4-Zuteilungen ändern darf, beeinflusst möglicherweise ein Produkt, das organisatorisch anderswo verantwortet wird.

Im Präfix steckt bereits eine Produktentscheidung

Der Kundenrouter heißt im Verfahren CE. Sein delegiertes IPv6-Präfix kombiniert das 6rd-Präfix des Anbieters mit dem benötigten hinteren Teil seiner IPv4-Adresse. Gemeinsame höherwertige IPv4-Bits können entfallen. Wie viele das sind, bestimmt IPv4MaskLen.

Die Länge des delegierten Präfixes ergibt sich aus 6rdPrefixLen plus 32 minus IPv4MaskLen. Im Beispiel der RFC stammen die IPv4-Adressen aus 10/8. Die gemeinsamen ersten acht Bits müssen nicht in jedem Kundenpräfix wiederholt werden. Ein 6rd-Präfix /32 und die verbleibenden 24 IPv4-Bits ergeben damit /56.

Diese Rechnung teilt nicht nur Adressen zu. Sie legt mit fest, wie viel Raum dem Kunden für eigene Subnetze bleibt. Bits, die der Unterscheidung von Endpunkten dienen, stehen nicht noch einmal für die Unterteilung des Standorts zur Verfügung. Eine Optimierung des IPv4-Plans kann deshalb die Eigenschaften des IPv6-Angebots berühren.

Zwei Grenzen sind auseinanderzuhalten. Die DHCP-Option verlangt, dass die betreffenden Längen zusammen höchstens 128 Bits beanspruchen. Die Adressierungsbeschreibung empfiehlt hingegen ein delegiertes Präfix mit einer Länge von höchstens 64 Bits, um zustandslose Adressautokonfiguration zu ermöglichen. Ein formal zulässiger Parameter belegt noch kein zweckmäßiges Kundennetzkonzept.

Auch private IPv4-Adressen bleiben kontextabhängig. Überlappende IPv4-Räume sind in verschiedenen 6rd-Domänen möglich, wenn diese unterschiedliche 6rd-Präfixe verwenden. Eine Adresse aus einer Domäne ist deshalb nicht ohne Weiteres eine eindeutige Endpunktidentität in einer anderen. Das Verfahren darf zudem nicht mit einer Aufteilung einer gemeinsam genutzten IPv4-Adresse nach Portbereichen verwechselt werden.

Der alte Plan bleibt somit Teil der Leistungserbringung. Selbst wenn Anschlussgerät und Produktname gleich bleiben, kann eine Adressänderung Bedingungen verschieben, auf die Kunden ihre internen Netze aufgebaut haben.

Fünf Wochen waren das Ergebnis konkreter Kontrolle

Der historische Bericht über Free/Iliad in RFC 5569 beschreibt fünf Wochen zwischen der Entscheidung am 7. November 2007 und dem Betriebsbeginn am 11. Dezember. Mehr als 1,5 Millionen Kunden konnten IPv6 nutzen, sofern sie die Funktion aktivierten.

Das ist eine Aussage über berechtigte beziehungsweise technisch erreichbare Kunden, nicht über gemessene aktive Nutzer, gleichzeitige Verbindungen oder Anwendungsqualität. Der informative Bericht erschien 2010. Er liefert keine heutige Nutzungsstatistik und keine allgemeine Zusage, dass sich ein anderer Bestand im selben Zeitraum umstellen lässt.

Die Organisation konnte die Software ihrer Kundengeräte verändern, Relays bereitstellen und das vorhandene Zugangsnetz einsetzen. Der Bericht beschreibt auch eine Entwicklung des Adressplans: zunächst eine /32-Zuteilung mit /64-Kundenpräfixen, später eine /26-Zuteilung mit /60-Kundenpräfixen für bis zu 16 LANs. Das ist die dokumentierte historische Konfiguration, keine Rechnung, nach der /26 plus 32 Bits /60 ergäbe.

Die Errata zu RFC 5569 präzisieren dabei die Zeitform. Die verifizierte redaktionelle Korrektur 2023 stellt klar, dass die spätere Zuteilung bereits erfolgt war und nicht lediglich erwartet wurde. Auch die anderen verifizierten Einträge sind redaktioneller Art. Sie ergänzen weder Leistungsdaten noch heutige Ansprüche auf bestimmte Adresszuteilungen.

Der Managementwert des Beispiels liegt daher nicht in einer kopierbaren Zahl von Wochen. Er liegt in der Verbindung von Verfahren und Eingriffsmöglichkeit. Ein Betreiber kann den Algorithmus übernehmen, ohne dieselbe Verfügungsgewalt über die installierten Kundengeräte zu besitzen. Technische Einfachheit und organisatorische Umsetzbarkeit sind getrennt zu belegen.

Die IPv4-Lease begrenzt den neuen Dienst

RFC 5969 empfiehlt lange IPv4-Adresszuweisungen, weil ein Wechsel der Adresse auch das daraus abgeleitete IPv6-Präfix verändert. Das Ziel ist geringere Unruhe im Kundennetz. Daraus folgt weder eine Pflicht zu lebenslang festen Adressen noch ein einheitliches kommerzielles Produkt.

Ist die IPv4-Lease-Zeit bekannt, dürfen die entsprechenden an LAN-Hosts angekündigten Lebensdauern und die Lebensdauern per DHCPv6 delegierter Präfixe diese Zeit nicht überschreiten. Ist die IPv4-Lebensdauer unbekannt, empfiehlt das Dokument die Standardwerte aus RFC 4861. Unbekannt bedeutet nicht unbegrenzt verlässlich.

Gemeint ist die Lease im Adresszuweisungsprotokoll, nicht ein Vertrag zur kommerziellen Anmietung eines IPv4-Blocks. Der Betreiber kann denselben Block weiterhin nutzen und trotzdem die konkrete Adresse eines Kunden neu vergeben. Für dessen 6rd-Präfix zählt die individuelle Zuweisung, die in die Berechnung eingeht.

Eine Verkürzung dieser Zeit kann aus Sicht des IPv4-Adressmanagements sinnvoll erscheinen. Die Bewertung ist aber unvollständig, wenn sie die Folgen für IPv6 ausblendet. Der Gewinn an Flexibilität an einer Stelle kann Koordinationsaufwand bei Kundengeräten, Support und nachgelagerten Netzen erzeugen.

Dafür muss niemand fahrlässig handeln. Eine Abteilung kann die Auslastung des Adresspools verbessern, während eine andere stabile Präfixe liefern soll. Ohne gemeinsame Verantwortlichkeit erfüllen beide ihre Ziele, obwohl sich ihre Entscheidungen gegenseitig verändern.

Die Domäne hat mehr Wege als ihr Grenzrelay

6rd verwendet ein eigenes IPv6-Präfix des Anbieters und unterscheidet sich damit von 6to4 mit seinem festen globalen Präfix. Eine definierte Anbieterdomäne macht die Zuständigkeit greifbarer. Sie ist jedoch nicht automatisch eine sternförmige Topologie, in der jeder Datenstrom einen zentralen Kontrollpunkt passiert.

CEs derselben Domäne können direkt über IPv4-Kapselung kommunizieren. Der Grenzrelay, kurz BR, wird für Verkehr zwischen der 6rd-Domäne und dem externen IPv6-Netz benötigt. Diese Unterscheidung bestimmt, welche Absender ein CE akzeptieren und welche Wege die Betriebsbeobachtung prüfen muss.

Die verifizierte technische Errata 3049 zu RFC 5969 korrigiert genau diesen Punkt im Sicherheitstext. Ein CE muss Verkehr nicht nur von bekannten BRs, sondern auch von anderen CEs derselben Domäne empfangen können. Eine Regel, die sich auf die ursprüngliche Relay-only-Formulierung stützt, kann legitime Kommunikation verhindern.

Auf derselben Seite steht der zurückgewiesene technische Korrekturvorschlag 3869. Er darf nicht als angenommene Änderung verwendet werden. Verglichen wird die in der inneren IPv6-Quelladresse eingebettete IPv4-Adresse mit der äußeren IPv4-Quelladresse. Die vollständige IPv6-Adresse wird nicht wie eine IPv4-Adresse behandelt. Abweichungen werden verworfen und als mögliche Quelladressfälschung gezählt; ein solcher Zähler ist noch keine abgeschlossene Angriffszuordnung.

Hinzu kommen gemeinsame Parameter: IPv4-Maskenlänge, 6rd-Präfix und dessen Länge sowie die IPv4-Adressen der BRs. DHCP-Option 212 liefert eine Konfiguration für eine Domäne. Bei einer gültigen Option erfolgt normalerweise automatische Konfiguration, doch der CE muss eine Abschaltmöglichkeit besitzen und die Option dann ignorieren.

Damit bleibt eine ausdrückliche Konfigurationshoheit bestehen. Wenige gemeinsame Eingaben haben große Reichweite. Zustandslose Weiterleitung kann uneinheitliche Vorstellungen darüber, zu welcher Domäne eine Adresse gehört, nicht von selbst auflösen.

Ein erreichbarer Relay bestätigt nicht alles

Mehrere BRs können eine gemeinsame IPv4-Anycast-Adresse nutzen, weil kein Zustand pro Datenfluss erforderlich ist. Der beobachtete Erfolg an dieser Adresse hat trotzdem eine begrenzte Aussagekraft. Er beweist nicht das Verhalten jedes einzelnen Relays oder jedes externen Ziels.

RFC 5969 warnt vor der Last, die regelmäßige Erreichbarkeitstests vieler CEs auf der Steuerungsebene eines BR erzeugen können. Falls CE-BR-Erreichbarkeitserkennung benötigt wird, muss sie über eine Methode der Weiterleitungsebene erfolgen, die keine besondere Bearbeitung durch die BR-Steuerungsebene verlangt. Der beschriebene Rückwegtest belegt diesen Weiterleitungsumlauf, nicht die vollständige Erreichbarkeit des externen IPv6-Netzes.

Auch Paketgrößen erfordern eine eigene Betrachtung. Eine ICMP-Fehlermeldung an die gemeinsame IPv4-Anycast-Adresse kann bei einem anderen BR ankommen als dem ursprünglichen Sender. Dynamisches Lernen der Pfad-MTU kann dadurch unzuverlässig werden und Blackholes entstehen lassen. Anycast-BRs müssen bei der Kapselung das DF-Bit setzen, auch um eine Verwechslung von Fragmenten verschiedener Relays mit gleicher Quelladresse bei der Wiederzusammensetzung zu verhindern.

Für einen gut kontrollierten IPv4-Pfad mit 1500 Bytes nennt die Spezifikation 1480 Bytes als Beispiel einer Tunnel-MTU. Bei unbekannter maßgeblicher MTU empfiehlt sie 1280. Das sind Entwurfsbedingungen und Empfehlungen, keine Messwerte dieses Beitrags. Ein kleiner erfolgreicher Test löst die Frage nach größeren Paketen nicht mit.

Die Ableitung ersetzt keinen Endpunktnachweis

Die informative Sicherheitsanalyse RFC 6324 von 2011 untersucht Schleifen bei automatischen IPv6-over-IPv4-Tunneln, wenn Routingannahmen und Adressinterpretationen nicht zusammenpassen. Entscheidend ist die Trennung zwischen einer berechenbaren Adresse und einem tatsächlich vorhandenen, zulässigen Tunnelendpunkt.

Bei 6rd müssen Prüfungen die anbieterspezifischen Präfixe kennen. Ein einziges globales Erkennungspräfix für sämtliche Domänen existiert nicht. Private IPv4-Räume bringen zusätzliche Geltungsbereichsfragen mit sich. Allgemeine Prüfregeln ersetzen deshalb keine Kenntnis der konkreten Domänen.

Das Dokument behandelt betriebliche Vermeidung problematischer Kombinationen und, wo passend, konsistente Nachbarinformationen oder begrenzte Endpunktmengen. Eine speziell für ISATAP beschriebene Maßnahme ist nicht automatisch eine 6rd-Lösung. Die jeweiligen Anwendungsgrenzen gehören zum Befund.

Es geht um bedingte Fehlermechanismen, nicht um eine aktuelle Bestandsaufnahme angegriffener 6rd-Netze. Das IPv6-Hop-Limit bleibt endlich. Für diesen Beitrag wurden weder Angriffspakete erzeugt und verschickt noch Betreiberinstallationen getestet. Die Errata-Abfrage für RFC 6324 ergab bei der Prüfung keine passenden Einträge; das ist ebenfalls kein heutiges Sicherheitsgutachten.

RFC 5969 erörtert zudem die Begrenzung unerwünschter Zugriffe auf BRs und den Umgang mit bekannten anderen Relays im IPv4-Bereich. Die Bezeichnung „Anbieternetz“ belegt noch nicht die Durchsetzung dieser Grenzen. Umgekehrt lässt sich aus einer Vorschrift allein kein Versäumnis eines konkreten Betreibers ableiten.

Die Abkürzung braucht eine vollständige Schlussrechnung

Für den Wechsel zu nativem IPv6 beschreibt RFC 5969 zwei unterschiedliche Wege: neue Präfixe mit Umnummerierung oder die Übernahme bestehender delegierter Präfixe ins native Routing. Die zweite Möglichkeit schützt die Nummerierung beim Kunden, verlangt aber eine andere Darstellung der Erreichbarkeit im Netz.

Diese Arbeit ist nicht schon erledigt, weil das neue Zugangsgerät IPv6 beherrscht. Ebenso hängt die Rückgewinnung des 6rd-Blocks von den verbleibenden Nutzern ab. Ein sichtbarer Rückbau an der zentralen Infrastruktur beweist nicht das Ende jeder Adressabhängigkeit.

Lu Hengs Note 32 zum Agency-Problem bietet dafür eine analytische Frage: Treffen Entscheidungsmacht und Folgenverantwortung zusammen? Hier heißt das, ob die Kontrolle über IPv4-Zuweisungen auch die Auswirkungen auf IPv6 und den späteren Ausstieg berücksichtigt. Es ist keine Behauptung, Lu Heng habe 6rd untersucht oder einem Betreiber unlautere Motive zugeschrieben.

Seine Note 36 zum Zweck von BTW stützt eine nüchterne Beschreibung von Struktur und Beweisgrenzen statt einer Kampagne für oder gegen ein Verfahren. Der schnelle Einstieg kann sinnvoll gewesen sein. Er wird nicht dadurch besser bewertet, dass seine fortbestehenden Voraussetzungen aus dem Bericht verschwinden.

Der alte Adressplan entscheidet weiter mit, weil er weiterhin Leistung erbringt. Gute Führung macht sichtbar, wer ihn verändern darf, welche Kundenfolgen daran hängen und welche Bedingungen erfüllt sein müssen, bevor diese Verbindung tatsächlich endet.