Zusammenfassung

  • RFC 6334 definiert die DHCPv6-Option 64, mit der ein B4 den Namen eines DS-Lite-AFTR erhält. Der Name ermöglicht einen Verbindungsversuch, belegt aber weder DNS, Tunnelaufbau, NAT-Zustand noch Rückverkehr.
  • Tomek Mrugalski verfasste RFC 6334 gemeinsam mit David W. Hankins. Das Kundengerät erhält eine begrenzte Endpunktangabe; Kapazität, Platzierung, Hochverfügbarkeit und Übersetzungsprotokollierung bleiben Betriebsaufgaben des Anbieters.

Ein empfangener Name ist noch kein Dienst

Ein Gateway-Protokoll zeigt „AFTR empfangen“, und eine Statusseite wird grün. Damit ist belegt, dass eine DHCPv6-Antwort einen Namen enthielt. Offen bleibt, ob der B4 ihn über seinen DNS-Pfad auflösen konnte, ob die ausgewählte IPv6-Adresse erreichbar war, ob der Tunnel zustande kam und ob der AFTR den erforderlichen Zustand für die Übersetzung dieses Datenstroms anlegte. Selbst ein ausgehendes IPv4-Paket mit übersetzter Adresse sagt nicht, ob die Antwort zum Teilnehmer zurückkam. Wer all diese Schritte in einer Anzeige zusammenfasst, verliert die Information, die bei einem Ausfall zuerst gebraucht wird.

RFC 6334 definiert OPTION_AFTR_NAME, DHCPv6-Code 64, als Option mit einem vollqualifizierten Domainnamen für einen Address Family Transition Router. Der AFTR ist der Endpunkt auf Anbieterseite im Dual-Stack-Lite-Modell; der B4 startet den Softwire auf Kundenseite. Die Option überträgt keinen fertigen Tunnel, reserviert keine Kapazität, erstellt keine NAT-Zuordnung und prüft keine Anwendung. Sie nennt den nächsten möglichen Endpunkt, nicht den Erfolg der gesamten Dienstkette.

Wie DS-Lite Aufgaben in das Anbieternetz verschiebt

Dual-Stack Lite ermöglicht es, einen IPv6-basierten Zugang zu nutzen und zugleich IPv4-Verkehr für Geräte und Dienste weiterzuleiten, die ihn benötigen. Geräte im Haushalt verwenden private IPv4-Adressen. Das B4 kapselt ihre IPv4-Datagramme in IPv6 und sendet sie an den AFTR. Dieser entfernt die Kapselung und übersetzt den Verkehr mit gemeinsam genutzten öffentlichen IPv4-Adressen. Der Anbieter muss damit nicht jedem Gerät im Haushalt eine eigene öffentliche IPv4-Adresse zuordnen.

Die gemeinsame Nutzung bündelt jedoch Zuständigkeiten und Zustand. Der Anbieter entscheidet, welche Teilnehmergruppen einen AFTR verwenden, wo zusätzliche Kapazität steht und wie Antworten zum richtigen Tunnel zurückfinden. RFC 6333 beschreibt Gruppen von Nutzern um einen AFTR sowie die Möglichkeit, weitere Instanzen hinzuzufügen oder näher an Zugangsnetze zu stellen. Das sind Architekturvarianten, keine Messung realer Netze. Aus ihnen lassen sich weder die heutige Verbreitung noch Teilnehmerzahlen, Kosten oder Auslastung eines bestimmten Anbieters ableiten.

B4 und AFTR erfüllen unterschiedliche Aufgaben. Das B4 benötigt funktionierendes IPv6, muss die Option prüfen, den Namen auflösen und den Tunnel einer Schnittstelle zuordnen. Der AFTR muss den Softwire annehmen, die Kapselung entfernen, den IPv4-Verkehr übersetzen und genug Zustand halten, um Antworten zurückzuleiten. Ein Mitschnitt am Heimrouter kann die Messungen auf Anbieterseite nicht ersetzen.

Was Code 64 festlegt

Der B4-Client fordert OPTION_AFTR_NAME an, indem er Code 64 in die OPTION_ORO aufnimmt. Ohne diese Anforderung sendet der Server den AFTR-Namen nicht. Die Option enthält einen im DHCPv6-Format codierten Domainnamen; der Client prüft Länge und Struktur. Das IANA-Register führt Code 64 als einzelne Option, die der Client im ORO anfordern darf. Es handelt sich also um einen konkreten Konfigurationsaustausch und nicht um eine automatische Suche nach beliebigen verfügbaren Endpunkten.

Auch die anschließende Auswahl ist begrenzt. Der B4 löst den Namen über einen AAAA-Eintrag auf. Gibt es mehrere IPv6-Adressen, wählt er eine Adresse für die betreffende Schnittstelle. Mehrere parallele DS-Lite-Tunnel je Schnittstelle sind nicht der vorgesehene Mechanismus. Bei mehreren AFTR-Name-Optionen oder mehreren möglichen Namen verwendet der Client gemäß RFC nur den ersten. Daraus folgt kein allgemeines clientseitiges Load-Balancing und kein umfassendes Failover zu einem anderen AFTR.

Eine DHCPv6-Antwort belegt, dass ein angeforderter Konfigurationswert in einem bestimmten Austausch zurückkam. DNS-Antwort, IPv6-Erreichbarkeit, Tunnelstatus, AFTR-Annahme, NAT-Zustand, Rückverkehr und Anwendungserfolg müssen separat beobachtet werden. Diese Abgrenzung ist kein Mangel der Option. Sie verhindert, dass ein Konfigurationsschritt fälschlich als Ende-zu-Ende-Nachweis gilt.

Die Nachweiskette bis zur Antwort

Eine belastbare Störungsanalyse verbindet Zeitpunkte und geeignete Kennungen über die einzelnen Schritte hinweg. Zuerst wird festgehalten, ob der ORO Code 64 anforderte und welcher Name zurückkam. Danach werden DNS-Abfrage und AAAA-Antwort mit dem Resolver des B4, der ausgewählten Adresse und dem beobachteten TTL verknüpft. Es folgen der Tunnelversuch und sein Zustand je Schnittstelle. Auf Anbieterseite sind Softwire-Eingang, AFTR-Gesundheit, Erzeugung und Ablauf der NAT-Zuordnung sowie die Weiterleitung des Rückpakets zu vergleichen.

Ein kontrollierter IPv4-Rundlauf kann einen Teil der Kette prüfen, muss aber Ziel und Umfang ausweisen. Er beweist nicht, dass jede Anwendung eines Teilnehmers funktioniert. Ein externer Test kann erfolgreich sein, obwohl eine bestimmte AFTR-Gruppe gestört ist. Ein bestehender Tunnel kann stehen, während neue NAT-Zuordnungen scheitern. Und nach einem Endpunktwechsel können neue Flüsse funktionieren, während langlebige Verbindungen ihren bisherigen Zustand verloren haben.

Die Nachweise liegen häufig bei verschiedenen Teams: DHCP, DNS, CPE-Entwicklung, Backbone, AFTR-Betrieb, Support und Missbrauchsbekämpfung. Für jeden Übergang braucht es einen Verantwortlichen und einen Beleg. Gleichzeitig müssen Datenschutz und Zugriffsschutz festlegen, wer Ereignisse miteinander verknüpfen darf. Ohne solche Vereinbarungen wird ein kleines Konfigurationsfeld bei der Fehlersuche zu einem organisatorischen Übergabeproblem.

Optionsentwurf und Implementierbarkeit

Die später veröffentlichte RFC 7227 gibt Leitlinien für neue DHCPv6-Optionen. Sie behandelt wiederverwendbare Formate, Kardinalität und Reihenfolge, ORO, Client-, Server- und Relay-Verhalten, Prüfung, Sicherheit und langfristige Kompatibilität. RFC 6334 erschien 2011, RFC 7227 drei Jahre später; die spätere Leitlinie darf deshalb nicht als Ursache des AFTR-Name-Entwurfs dargestellt werden. Zusammen zeigen die Texte, dass auch ein kleines Feld präzise Regeln braucht, damit vorhandene Software es implementieren und Betreiber es verlässlich auswerten können.

Die aktuelle DHCPv6-Basis ist RFC 9915 vom Januar 2026. Sie ersetzt RFC 8415, verweist weiterhin auf getrennte Dokumente für einzelne Optionen und hält die Verbindung zwischen ORO-Verhalten und IANA-Register aufrecht. Das Register dokumentiert Code 64 und seine formale Verwendung. Es verrät nicht, welche Anbieter den Mechanismus heute einsetzen oder wie viele Anschlüsse davon abhängen.

Eine gemeinsame Spezifikation ist keine Einzelleistung

RFC 6334 hat zwei Autoren: David W. Hankins und Tomek Mrugalski. RFC 7227 ist die Arbeit von fünf Autoren; RFC 9915 entstand mit einem größeren Autorenteam. Das IETF Datatracker-Profil listet Mrugalskis Beiträge zu DHCP-Dokumenten, und ein ISC-Profil ergänzt beruflichen Kontext. Diese Aufzeichnungen belegen weder, dass eine Person allein das gesamte Protokoll geschaffen hat, noch dass sie heutige Betreiberkonfigurationen steuert.

Die Einordnung einer technischen Leistung sollte die Kette zwischen Text und Betrieb erhalten. Ein Standard legt eine gemeinsame Schnittstelle fest. Implementierer bauen den B4, Anbieter wählen Endpunkte, Kapazität, Redundanz und Protokollierung. RFC 9313 vergleicht DS-Lite mit anderen Übergangsmodellen für IPv4-as-a-Service; daraus folgt nicht, dass DS-Lite überall überlegen oder derzeit marktführend ist.

Vom Standard zum laufenden Dienst

Die Kette beginnt mit der Anforderung der Option. Der Server liefert einen Namen; der B4 prüft ihn, löst ihn auf, wählt eine Adresse und versucht den Tunnel. Der AFTR muss Verkehr annehmen, übersetzen und Antworten zurückleiten. Der Anbieter muss Kapazität, Verfügbarkeit und nachvollziehbare Zustände bereitstellen. Erst wenn die Anwendung eine Antwort erhält, ist auch diese letzte Ebene beobachtet.

Ein Protokollsatz wie „AFTR-Name empfangen“ ist nützlich, wenn er genau diesen Schritt bezeichnet. Für die Aussage „IPv4 funktioniert“ braucht es spätere, korrelierte Nachweise. Die knappe DHCPv6-Anweisung hebt die Betriebsverantwortung nicht auf; sie macht sichtbar, dass der Anbieter nach der Namensauswahl mehr leisten muss.

Quellen