IPv4 nur im Notfall

Wichtig ist, dass diese Systeme für ihre Namensauflösung nur den DNS-Server des Providers nutzen. Dafür gibt es drei Möglichkeiten:

• Die Namensauflösung liefert nur eine IPv6-Adresse: Die Clients greifen über ihre globale IPv6-Adresse auf das Zielsystem zu.
• Die Namensauflösung liefert sowohl eine IPv4- als auch eine IPv6-Adresse: Die Clients bevorzugen die IPv6-Adresse und greifen auf das Ziel zu.
• Die Namensauflösung liefert nur eine IPv4-Adresse: Hier reagiert der DNS-Server des Providers und fälscht in seiner Antwort an den Client zusätzlich eine IPv6-Adresse und fügt diese seiner Antwort hinzu.

Dafür hängt er die hexadezimale Repräsentation der IPv4-Adresse an ein vorher definiertes IPv6-Präfix an. Hierbei wählt der Admin des DNS-Servers das hierzu optional reservierte Präfix 64:FF9B::/96 oder auch einen freien Bereich aus seinem Fundus der IPv6-Adressen. Der Client erhält nun in der DNS-Antwort wieder sowohl eine IPv4- als auch eine IPv6-Adresse und bevorzugt die IPv6-Adresse. Das entsprechende Paket sendet er an das Default Gateway bei seinem Provider.

Dort erkennt der Router die gefälschte IPv6-Adresse an dem verwendeten Präfix. Das System extrahiert die eingebettete IPv4-Adresse und führt eine Network Address Translation und Protocol Translation von IPv6 auf Ipv4 durch. Dieses Verfahren bezeichnen die Entwickler als NAT64 (Abbildung 2). Das erforderliche DNS Application Layer Gateway nennen sie DNS64.

Abbildung 2: Bei NAT64 fälscht der Provider eine IPv6-Adresse, um später diese Zugriffe auf IPv4 zu maskieren.

Für Linux gibt es dafür mehrere Implementierungen. So erlaubt Bind in seiner neuesten Version bereits den Einsatz als DNS64-Server. Für die NAT64-Komponente existieren sowohl die Userspace-Applikation Tayga [4] als auch eine Kernelkomponente Ecdysis [5].

Ein vermeintliches Problem beim Einsatz von NAT64 stellt die zunehmende Verbreitung von DNSSEC dar, das Veränderungen und damit ein technisches Fälschen der DNS-Antworten erkennt und entsprechende Antworten ignoriert.

NAT-PT

Das RFC 2766 beschrieb bereits im Jahr 2000 einen Network Address Translator/Protocol Translator namens NAT-PT, der im Gegensatz zu NAT64 zusätzlich auch ein NAT46 anbietet. Damit sollen nicht nur IPv6-Systeme auf beliebige IPv4-Ziele, sondern umgekehrt IPv4-Systeme auch auf beliebige IPv6-Ziele zugreifen. Da sich IPv4-Adressen problemlos in eine gefälschte IPv6-Adresse einbetten lassen, ist ein NAT64 recht einfach implementierbar. Der umgekehrte Weg erweist sich als deutlich komplizierter.

Der IPv4-Adressraum bietet zu wenig Platz, um beliebige IPv6-Adressen in gefälschte IPv4-Adressen einzubetten. Das verhindert, dass DNS46 und NAT46 unabhängig voneinander agieren, denn sie müssen ständig die Informationen untereinander austauschen. Obwohl einige funktionsfähige Implementierungen existieren, wurde 2007 aufgrund vielfältiger Probleme das RFC 2766 für NAT-PT in den historischen und unerwünschten Status versetzt (RFC 4966).

Für ein reines IPv4-System gibt es daher gegenwärtig keine Lösung für einen Zugriff auf Hosts, die nur über IPv6 erreichbar sind. Abhilfe schafft an dieser Stelle lediglich ein Dualstack-Proxy. Mit diesem verbinden sich die Clients dann per IPv4, um das IPv6-Zielsystem zu erreichen. Allerdings unterstützt diese Technik nur Protokolle, die das Nutzen von derartigen Application Layer Gateways erlauben. Dazu zählen DNS, SMTP, HTTP oder HTTPS.