Zusammenfassung

  • RFC 9872 empfiehlt die PREF64-Option in Router Advertisements nach RFC 8781, sofern sie verfügbar ist; RFC 7050 bleibt Rückfall für fehlende Signale und ältere Endpunkte.
  • In Multihoming-Szenarien ist nicht das Präfix allein der Betriebszustand, sondern seine befristete Zuordnung zu Router, Quelladresse, nächstem Hop und Übersetzungsergebnis.

Der Fehler sieht zunächst nach Erfolg aus. DNS64 liefert ein gültiges Präfix, der Host synthetisiert eine korrekte IPv6-Adresse und hat zwei funktionierende Standardrouter. Wählt er jedoch die Quelladresse und den nächsten Hop des anderen Anbieters, liegt der passende NAT64-Übersetzer außerhalb dieses Weges.

RFC 9872 macht aus dieser verlorenen Zuordnung eine Einsatzempfehlung. Das im September 2025 veröffentlichte IETF-Informationsdokument fordert Endpunkte auf, PREF64 zuerst über die Option aus RFC 8781 zu beziehen. NAT64-Betreiber sollen sie ankündigen. Die DNS-Heuristik aus RFC 7050 bleibt zulässig, wenn die Option fehlt oder Altgeräte sie nicht verarbeiten.

PREF64 ist ein IPv6-Präfix für die Adresssynthese; RFC 6052 definiert seine Formate. Es ermöglicht lokales DNS64 nach RFC 6147, CLAT in RFC 6877 und die Behandlung von IPv4-Literalen aus RFC 8305. Diese Fähigkeiten beweisen keinen erreichbaren Übersetzer.

RFC 7050 leitet das Präfix aus synthetischen AAAA-Antworten für ipv4only.arpa. ab; RFC 8880 regelt den Sondernamen. Das Verfahren hängt vom DNS64 der Zugangsnetzes oder von Sonderbehandlung im Endpunkt ab. Ein anderer Resolver oder ein Split-Tunnel-VPN kann DNS ersetzen, während Verkehr lokal bleibt, und so Ermittlung und gültigen Pfad voneinander trennen.

Bei mehreren Anbietern können mehrere Präfixe erscheinen. Eine DNS-Antwort bindet ein Präfix nicht zuverlässig an den passenden Upstream, das IPv6-Quellpräfix und das Default Gateway. Der Host kann daher ausschließlich korrekte Einzelwerte zu einer nicht ausführbaren Kombination zusammensetzen. Verloren ist die Herkunftsbeziehung.

Router Advertisements halten diese Beziehung am ersten Hop. RFC 4861 nutzt sie bereits für Routerpräsenz und IPv6-Linkparameter. RFC 8781 ergänzt Präfix und Lebensdauer. Der Host kann speichern, welcher Router welches PREF64 ankündigte, und es bei Lebensdauer null zurückziehen. Das bleibt begrenzte Evidenz: RA, Route und Übersetzer benötigen eigene Prüfungen.

Auch die Änderungsgewalt verschiebt sich. DNS-Ermittlung erfordert nach der Stack-Konfiguration einen weiteren Austausch und hält das Ergebnis bis zum TTL-Ablauf. Bei externem DNS64 hat der Netzbetreiber dieses TTL womöglich nicht unter Kontrolle. Eine neue RA kann die Information unmittelbar ändern oder widerrufen. Entscheidend ist die Dauer eines falschen Zustands.

Der Sicherheitsbedarf wandert zum ersten Hop. RFC 6105 beschreibt RA-Guard, macht aber erlaubte Anzeigen nicht automatisch richtig. RFC 9463 ermöglicht die Bekanntgabe netzbestimmter verschlüsselter Resolver; geschütztes DNS beweist dennoch keine Uplink-Zuordnung.

Migration verlangt eine Bestandsaufnahme. Konforme moderne Endpunkte bevorzugen RFC 8781, Altgeräte können RFC 7050 brauchen. RFC 9872 hält außerdem fest, dass mobile Betriebssysteme die Option unterstützen können, obwohl Mobilfunktechnik sie nicht in RAs einfügen kann. Der offizielle Datensatz belegt Veröffentlichung, nicht Einsatz bei einem bestimmten Betreiber.

Heng Lus Vorrang laufenden Codes verlangt einen wiederholbaren Pfadnachweis. Seine minimale Anfangsspezifikation hält das gemeinsame Signal schmal und die Annahme lokal. Die Kritik an der permanenten Dual-Stack-Steuer macht die parallelen Kosten von DNS, RA, Schutz, Übersetzung und Altunterstützung sichtbar.

RFC 9872 ersetzt keinen Test durch ein anderes Symbol. Es bewahrt nur genug Kontext, damit der Host besser entscheidet und der Betreiber die Entscheidung später rekonstruieren kann.

Quellen