NAT64
Netzwerkprotokoll Aus Wikipedia, der freien Enzyklopädie
Remove ads
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.
| 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 |
Remove ads
Adressschreibweise
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.
Routing
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.
Stateful
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
- den Sender (Source host)
- den Empfänger (Destination host)
- den Sendeport (TCP/UDP; Source port)
- 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.
Remove ads
DNS64 ist eine Technik, die NAT64 ergänzt. Sie ist in RFC 6147 definiert[1] 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:
- 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
- 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
- Diese Adresse wird nun in die (evtl. für dieses Netzwerk gültige) IPv6-NAT64-Form transformiert: 64:ff9b::192.0.2.1 bzw. 64:ff9b::c000:0201
- Der DNS64-Server gibt nun dem anfragenden Host 2001:db8::1 einen AAAA-RR zurück: 64:ff9b::c000:0201
- 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.
Remove ads
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[2] 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.
Remove ads
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.
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[3] noch einen Patch. Weitere Opensource NAT64-Implementationen als Programme außerhalb des Kernels sind TAYGA für Linux (stateless)[4] und WrapSix (stateful)[5] sowie innerhalb des Kernels Jool (stateful)[6] Die Nameserversoftware BIND unterstützt DNS64.[7]
Remove ads
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
Remove ads