NAT64

IPv6-Übergangsmechanismen
4in6	Tunneling von IPv4 in IPv6
6in4	Tunneling von IPv6 in IPv4
6over4	Transport von IPv6-Datenpaketen zwischen Dual-Stack Knoten über ein IPv4-Netzwerk
6to4	Transport von IPv6-Datenpaketen über ein IPv4-Netzwerk (veraltet)
AYIYA	Anything In Anything
Dual-Stack	Netzknoten mit IPv4 und IPv6 im Parallelbetrieb
Dual-Stack Lite (DS-Lite)	Wie Dual-Stack, jedoch mit globaler IPv6 und Carrier-NAT IPv4
6rd	IPv6 rapid deployment
ISATAP	Intra-Site Automatic Tunnel Addressing Protocol (veraltet)
Teredo	Kapselung von IPv6-Datenpaketen in IPv4-UDP-Datenpaketen
NAT64	Übersetzung von IPv4-Adressen in IPv6-Adressen
464XLAT	Übersetzung von IPv4- in IPv6- in IPv4-Adressen
SIIT	Stateless IP/ICMP Translation

NAT64 ist ein IPv6-Übergangsmechanismus. Er dient zur Übersetzung von IPv4- in IPv6-Adressen. Sein Zweck besteht vornehmlich in der Ermöglichung einer Kommunikation zwischen nur per IPv6 erreichbaren Hosts auf der einen Seite und nur per IPv4 erreichbaren Hosts auf der anderen Seite. In Sonderfällen ist es zwar möglich, durch IPv4-Hosts eine Verbindung zu initiieren, normalerweise bleibt dies allerdings den IPv6-Hosts vorbehalten. Da es auf absehbare Zeit jedoch viel mehr IPv6-Hosts als IPv4-Hosts geben wird, ist dies nicht problematisch, denn der Hauptzweck besteht darin, IPv4-Server von IPv6-Netzen aus anzusprechen.

NAT64 nutzt die Tatsache aus, dass die 128-bittigen IPv6-Adressen gut in der Lage sind, eine 32-bittige IPv4-Adresse zu enthalten:

• IPv4: 192.0.2.1 → c0.00.02.01 (Hexadezimale Schreibweise der IPv4-Adresse)
• IPv6: 64:ff9b:: → 64:ff9b::c000:0201 (in die letzten 32 Bits der IPv6-Adresse eingebettet)

Das Präfix 64:ff9b::/96 ist speziell für diesen Mechanismus reserviert worden. Alternativ und zur einfacheren Verwendung kann statt der rein hexadezimalen Schreibweise auch eine Mischschreibweise verwendet werden:

• 192.0.2.1 → 64:ff9b::192.0.2.1

Dabei wird die dezimale IPv4-Adresse von der IPv6-Implementierung automatisch in Hexadezimal-Schreibweise umgewandelt.

Will nun der IPv6-Host 2001:db8::1 Kontakt mit dem IPv4-Server 192.0.2.1 aufnehmen, so sendet er in seinem lokalen Netzwerk Pakete an die Adresse 64:ff9b::c000:0201. Hierbei würde beispielsweise eine statische Route helfen, die alle Pakete mit dem Ziel 64:ff9b::/96 an den NAT64-Router weiterleitet. Der NAT64-Router kann nun die Pakete entgegennehmen, die IPv4-Adresse „auspacken“ und den Inhalt ab inklusive OSI-Schicht 4 gekapselt in IPv4-Pakete über seinen IPv4-Anschluss weiterrouten:

• IPv6-Adresse: 64:ff9b::c000:0201 → IPv4-Adresse (hex.): c0.00.02.01 → IPv4-Adresse (dez.): 192.0.2.1

Bei der Nutzung der Präfixe ist man nicht unbedingt auf 64:ff9b::/96 beschränkt. Bei entsprechender Konfiguration kann man ein beliebiges Subnetz aus seinem zugeteilten Netz für diesen Zweck nutzen; siehe auch RFC 6052.^[1]

NAT64 ist stateful, das heißt, der NAT64-Router merkt sich, welcher IPv6-Host und welcher IPv4-Host miteinander kommunizieren. In der NAT64-Tabelle des Routers wird darüber Buch geführt. Dies funktioniert ähnlich wie herkömmliche NAT.

Ein Beispiel: Wenn 2001:db8::dead:beef eine Verbindung mit 192.0.2.56 aufbauen möchte, so schickt er (wie gehabt) die Pakete, die an diesen Host gerichtet sind, an 64:ff9b::c000:238, also im Grunde den Router. Dieser entnimmt die IPv4-Adresse und routet die Pakete weiter, merkt sich aber dabei

1. den Sender (Source host)
2. den Empfänger (Destination host)
3. den Sendeport (TCP/UDP; Source port)
4. den Empfängerport (TCP/UDP; Destination Port)

Trifft nun auf IPv4-Seite des Routers ein Paket mit gegenteiligen Daten ein, also Sender und Empfänger jeweils vertauscht, weiß der Router sofort, an welchen IPv6-Host er das Paket weiterleiten muss.

DNS64 ist eine Technik, die NAT64 ergänzt. Sie ist in RFC 6147 definiert^[2] und basiert auf DNS. Hierbei erzeugt ein DNS64-Server aus A-Resource Records (A-RRs, also DNS-Einträge für IPv4-Adressen) automatisch und transparent AAAA-RRs (AAAA: Feldname im DNS für IPv6-Adressen). Dies funktioniert über das erläuterte Verfahren:

1. 2001:db8::1 möchte Kontakt mit dem Nur-IPv4-Host host1.example.net aufnehmen. Er weiß nichts über die Protokollunterstützung dieses Hosts, da er nur dessen Namen kennt. Er fragt seinen Nameserver 2001:db8::2 nach der Adresse für host1.example.net
2. Sein DNS64-Nameserver 2001:db8::2 versucht nun zunächst eine AAAA-Auflösung, findet jedoch keinen passenden Eintrag (da host1.example.net ja keine IPv6-Adresse hat). Dafür erhält er vom für host1.example.net zuständigen Nameserver einen A-Record mit der IPv4-Adresse: 192.0.2.1
3. Diese IPv4-Adresse wird nun in die (evtl. nur für dieses Netzwerk gültige) IPv6-Adresse (bestehend aus dem NAT64-Präfix und der IPv4-Adresse in den hinteren 32 Bit) transformiert: 64:ff9b::192.0.2.1 bzw. 64:ff9b::c000:0201
4. Der DNS64-Server gibt nun dem anfragenden Host 2001:db8::1 einen AAAA-RR zurück: 64:ff9b::c000:0201
5. Für diesen ist das ganze transparent. Er hält die IPv6-Adresse für die valide Adresse von host1.example.net und kann nun über diese Adresse IPv6-Pakete senden, die vom NAT64-Router ebenfalls transparent konvertiert und an den Zielhost gesendet werden.

NAT64 mit DNS64 ist für IPv6-Hosts ein transparentes und einfaches Verfahren zur Verbindung beider Protokollwelten. Bei der Umstellung auf NAT64 mit DNS64 müssen Hosts lediglich auf einen DNS64-Nameserver wechseln, was in den meisten Umgebungen automatisiert über DHCPv6 oder SLAAC mit RFC 8106^[3] erfolgen kann.

Die Nachteile von NAT64 resultieren vorrangig daraus, dass es sich weiterhin um ein NAT-Verfahren handelt. Wird providerseitig ein dynamischer IPv4-Adresspool verwendet (statesome oder stateful NAT64) muss der Verbindungsaufbau vom Client aus erfolgen, d. h. Serverdienste sind auf Kundenseite nicht möglich. Das schließt auch Peer-to-Peer-Dienste mit ein. Ein dynamischer IPv4-Adresspool ist dabei aber Voraussetzung, um providerseitig IPv4-Adressen einzusparen, was für Provider den Vorteil von NAT64 gegenüber Dual-Stack darstellt.

NAT64 mit DNS64 basiert auf der Idee, bei einer DNS-Anfrage statt einer IPv4- eine IPv6-Adresse zurückzugeben. Werden aber keine Namen, sondern direkt IPv4-Adressen verwendet (zum Beispiel URIs mit numerischen IPv4-Adressen), findet erst gar keine DNS-Anfrage statt. Auch Anwendungen die veraltete, zu IPv6 inkompatible Programmierschnittstellen verwenden, können keine Verbindung aufbauen. Diese Probleme lösen ergänzende Verfahren wie 464XLAT.

NAT64 in Kombination mit DNS64 ist als öffentliches Angebot geeignet, zum Beispiel für Provider. Hierbei muss nur der DNS64-Nameserver dieses Providers bei den Clients eingetragen werden, um die Verbindung mit IPv4-Hosts zu ermöglichen.

Bei allgemein nutzbaren (providerunabhängigen) DNS64/NAT64-Angeboten können ausschließlich Global-Unicast-Adressen verwendet werden.

Es gibt aber auch öffentliche DNS64-Resolver (z. B. von Google^[4] und Cloudflare^[5]), die das well known prefix 64:ff9b::/96 zwar verwenden, wo aber das dazu passende NAT64-Gateway im eigenen Zugangsnetz vorausgesetzt wird.

Der Paketfilter pf von OpenBSD erlangte in der am 1. Mai 2012 zusammen mit OpenBSD 5.1 veröffentlichten Version Unterstützung für NAT64. Das Paket netfilter/iptables benötigt für NAT64^[6] noch einen Patch. Weitere Opensource NAT64-Implementationen als Programme außerhalb des Kernels sind TAYGA für Linux (stateless)^[7][8] und WrapSix (stateful)^[9] sowie innerhalb des Kernels Jool (stateful)^[10] Verschiedene Nameserversoftware unterstützt DNS64. So zum Beispiel: BIND,^[11] PowerDNS^[12] oder auch Unbound.^[13]

• RFC: 6146 – Stateful NAT64. (beschreibt den eigentlichen NAT64-Mechanismus, englisch).
• RFC: 6147 – DNS64. (beschreibt den für den Betrieb von NAT64 wichtigen Mechanismus DNS64, englisch).

• RFC: 8215 – Local-Use IPv4/IPv6 Translation Prefix. (definiert einen weiteren NAT64 Präfix zur lokalen Verwendung, englisch).

1. ↑ RFC: 6052 – IPv6 Addressing of IPv4/IPv6 Translators. Oktober 2010 (englisch).
2. ↑ RFC: 6147 – DNS64. (englisch).
3. ↑ RFC: 8106 – IPv6 Router Advertisement Options for DNS Configuration. 2017 (englisch).
4. ↑ dns64.dns.google
5. ↑ Support for IPv6-only networks
6. ↑ thomas.gelf.net
7. ↑ litech.org
8. ↑ aplrd/tayga
9. ↑ semirocket.science
10. ↑ nicmx.github.io/Jool
11. ↑ ftp.isc.org
12. ↑ doc.powerdns.com
13. ↑ github.com/NLnetLabs/unbound