Summary

  • Fassung 10 des IETF-Entwurfs schlägt vor, private und gemeinsam genutzte IPv4-Adressen mit dem bekannten NAT64-Präfix darzustellen. Der IESG Last Call läuft bis zum 23. November 2026.
  • Nicht verwaltete CLATs sollen solche Pakete standardmäßig übersetzen. Verwaltete PLATs müssen die Übersetzung abschaltbar machen; bestehende Sperrvorgaben sollen bei einer Aktualisierung erhalten bleiben.
  • Ein einziges Präfix macht die Übersetzung einfacher. Die Entscheidung über den Zugang zu internen Diensten fällt dann ausdrücklich in Routing, ACL und Firewall.

Manchmal steht die entscheidende Firewall-Regel gar nicht in der Firewall. RFC 6052 untersagt, eine nicht global erreichbare IPv4-Adresse unter 64:ff9b::/96 abzubilden. Ein Übersetzer muss ein solches Paket verwerfen. Wer nie eine eigene Sperrregel für interne Ziele formuliert hat, konnte trotzdem von diesem Pflichtverhalten profitieren. Der neue Entwurf würde diese bequeme Stellvertretung beenden.

Der Ausgangspunkt war ein echtes Adressproblem. Private Nummern nach RFC 1918 sind nur im jeweiligen Verwaltungsbereich eindeutig. Zwei Standorte dürfen beide 10.0.0.1 benutzen und damit völlig verschiedene Geräte meinen. Ein allgemein bekanntes IPv6-Präfix liefert keine zusätzliche Information über den richtigen Standort. Die pauschale Sperre trifft allerdings auch erwünschte Verbindungen: Ein reiner IPv6-Client braucht womöglich einen internen Dienst, der nur IPv4 spricht. Hinzu kommen gemeinsam genutzte Adressen nach RFC 6598.

Der Haken an zwei Präfixen

Auf dem Architekturdiagramm ist die Lösung schnell gezeichnet: das bekannte Präfix für öffentliches IPv4, ein netzspezifisches für interne Ziele. Ein DNS64-Server kann seine synthetisierte Antwort passend wählen. Ein CLAT auf dem Endgerät bekommt jedoch oft eine numerische IPv4-Adresse direkt von der Anwendung und baut daraus selbst eine IPv6-Adresse. Die DNS64-Auswahl sieht diesen Vorgang nicht.

Nach dem Entwurf liefern die verbreiteten Verfahren aus RFC 7050 und RFC 8781 zwar Übersetzungspräfixe, aber keine Tabelle, die einem bestimmten IPv4-Bereich das passende Präfix zuordnet. Kennt der Client beide, kann er sogar für dasselbe öffentliche Ziel zwei IPv6-Adressen erzeugen. Dann müssen Filter, Protokolle und Fehlersuche zwei Wege auseinanderhalten. Auch das lokale Präfix aus RFC 8215 liefert diese fehlende Zuordnung nicht, wenn es neben dem bekannten Präfix benutzt wird.

Fassung 10 greift deshalb die Normwörter in RFC 6052 an. Aus dem Verbot wird eine Erlaubnis, nicht globale IPv4-Ziele mit dem bekannten Präfix zu repräsentieren. Ein nicht verwalteter CLAT soll standardmäßig übersetzen. Ein verwalteter PLAT soll dies tun, solange er nicht anders konfiguriert ist, und eine Abschaltmöglichkeit anbieten. Eine Norm entscheidet nicht mehr pauschal für alle Netze; die einzelne Betriebsorganisation muss ihre Antwort konfigurieren.

Die Softwareaktualisierung darf keine Türen entriegeln

Im Sicherheitskapitel steht die heikle Nebenwirkung offen: Administratoren können die bisherige Pflicht zum Verwerfen als impliziten Schutz ihrer privaten Infrastruktur benutzt haben. Darum empfiehlt der Entwurf bestehenden, konformen PLATs, die Sperre bei einem Upgrade als Voreinstellung beizubehalten. Für eine absichtliche Freigabe braucht es passende Routen und ausdrückliche ACL-, Firewall- oder NAT-Filterregeln. Quelle, Ziel und Dienst müssen erkennbar zusammenpassen.

Die doppelte 10.0.0.1 ist der praktische Härtetest. Nach einer Firmenübernahme können zwei interne Netze dieselbe Zahl benutzen. Der Übersetzer kann das Paket fehlerfrei umschreiben und trotzdem zum falschen Gerät schicken. Technische Erreichbarkeit bescheinigt keine Berechtigung. Erst der Verwaltungsbereich, die Route und eine kontrollierbare Zugriffsregel geben der Zahl ihren betrieblichen Sinn.

Der Entwurf berichtet außerdem von uneinheitlichen CLAT-Implementierungen. Manche verwerfen private Ziele wie bislang verlangt; andere übersetzen sie schon heute. Er zählt weder die eine noch die andere Gruppe. Die fehlende Evidenz für ein konkretes Netz ist sein eigenes Inventar: Welche Clients erzeugen Ziele lokal? Welche Übersetzer sperren sie? Welcher private Dienst liegt in welchem Routingbereich? Ohne diese Antworten ist das einheitliche Präfix eine Schlüsselkarte, deren Raumliste niemand geprüft hat.

Die Fassung befindet sich noch im Last Call und ist keine veröffentlichte RFC. Ihre eigentliche Zumutung ist dennoch klar. Wer die einfache NAT64-Architektur möchte, muss die Zugangsentscheidung aus dem Schatten des Standards holen und für jede interne Tür selbst verantworten.

IETF-Entwurf · RFC 6052 · RFC 1918 · RFC 6598