464XLAT
| 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 |
464XLAT ist ein IPV4-IPv6-IPv4-Übersetzungsverfahren zur Anwendung in reinen IPv6-Netzwerken, beispielsweise bei Mobilfunk-Internetdienstanbietern.
Funktionsweise
[Bearbeiten | Quelltext bearbeiten]464XLAT beschrieben in RFC 6877[1] erlaubt Rechnern in IPv6-Netzwerken den Zugriff auf Internetdienste, die nur via IPv4 erreichbar sind.
Der Client nutzt einen SIIT-Übersetzer (CLAT) um IPv4-Pakete in IPv6 zu konvertieren. Diese Pakete werden zu einem NAT64-Übersetzer (PLAT) geschickt und zurückübersetzt. Dort können sie dann einen IPv4-Server erreichen.
Die SIIT-Übersetzung (CLAT) kann direkt auf dem Client selbst mit spezieller Software oder auf einem IPv4-fähigen (W)LAN davor erfolgen, beispielsweise einem Smartphone im Hotspot- oder Tetheringmodus. Wenn das LAN allerdings selbst via IPv4 verbunden ist, ist 464XLAT nicht notwendig. Der NAT64-Übersetzer muss in der Lage sein Server und Client (durch CLAT) zu erreichen.
Die Nutzung von NAT64 beschränkt die Verbindungen auf das Client-Server-Modell mit den Protokollen UDP, TCP und ICMP.
Es gibt (gab) CLAT-Implementationen für Android,[2] MacOS (seit Ventura), das Nokia N900[3] und Windows Phone[4] sowie Windows 10 (seit 1703, nur für Verbindungen über Mobilfunkmodem, nicht über (W)LAN).[5] CLAT kann unter Linux mit clatd[6] (basierend auf tayga[7] oder dem Kernelmodul nat46[8]), Jool[9] oder tundra[10] realisiert werden. PLAT unterscheidet sich nicht von NAT64 und erfordert damit auf Providerseite keine weiteren Maßnahmen.
Die folgende Tabelle fasst noch einmal zusammen, was in der Grafik durch farblich gekennzeichnete Paketwege skizziert wurde:
| Programm und eigener Host | Ziel (Server, anderer Host) | Übersetzung der IP-Pakete | Ort der Übersetzung(en) | Darstellung in der Grafik | DNSSEC |
|---|---|---|---|---|---|
| IPv4 | IPv4 | 464XLAT (zweimal) | CLAT und PLAT | rote Linie | OK |
| IPv4 | IPv6 | – | – | – | – |
| IPv6 | IPv4 | NAT64/DNS64 (einmal) | PLAT | blaue Linie | Konflikt |
| IPv6 | IPv6 | Ende-zu-Ende IPv6 (ohne Übersetzung) | – | grüne Linie | OK |
Vor- und Nachteile
[Bearbeiten | Quelltext bearbeiten]Da es sich bei 464XLAT um eine Ergänzung zu NAT64 mit DNS64 handelt, treffen deren Vor- und Nachteile im Wesentlichen auch auf 464XLAT zu. Im Unterschied zu NAT64 funktionieren mit 464XLAT auch Dienste, die auf IPv4-Adressen beschränkt sind (zum Beispiel URIs mit numerischen IPv4-Adressen anstelle von Namen oder Software mit veralteten, auf IPv4 beschränkten Programmierschnittstellen).
Ein zusätzlicher Nachteil zu NAT64 mit DNS64 ist die Notwendigkeit eines zusätzlichen Dienstes auf dem Client bzw. auf dem unmittelbaren Netzwerk davor (zum Beispiel auf dem Router). Zusätzlich ergeben sich Probleme daraus, den üblicherweise 20 Bytes großen IPv4-Header eines Datenpakets mit einem 40 Bytes großen IPv6-Header zu ersetzen. Ein Datenpaket wächst dadurch um 20 Bytes, was dazu führen kann, dass die Maximum Transmission Unit überschritten wird. Lösungen wie Path MTU Discovery, IP-Fragmentierung oder MSS Clamping werden notwendig.[11]
464XLAT kann Probleme (RFC 6147[12]), die sich bei DNS64/NAT64 mit der Verletzung von DNSSEC durch die Verwendung synthetischer nicht signierter AAAA-Records ergeben können, beheben, indem der signierte A-Record, also die IPv4-Adresse, verwendet wird. Dieser Fall tritt nur auf, wenn ein Server nur DNSSEC nicht aber IPv6 unterstützt und der Client die Validierung vornehmen will. Bei einer Validierung bereits im DNS64-Resolver/Cache wird das Problem auch ohne 464XLAT gelöst.
Bei Verwendung von „IPv6-mostly“ nach RFC 8925[13] kann unter bestimmten Umständen auf DNS64 verzichtet werden. Es werden dann nur 464xlat und native Verbindungswege zugelassen, DNSSEC ist dabei unbeeinträchtigt.
Praktische Anwendung
[Bearbeiten | Quelltext bearbeiten]Obwohl 464XLAT theoretisch in jedem Netzwerk, das keine IPv4- aber eine IPv6-Anbindung hat, genutzt werden kann, liegt der Schwerpunkt der Anwendung im Internetzugang via Mobilfunk. Derzeit verwendet die Deutsche Telekom 464XLAT auf aktuellen Android-Smartphones.
Im Sommer 2018 fand dazu ein Anwendertest bei der Deutschen Telekom zum ausschließlichen IPv6-Betrieb statt.[14] Dieser Test wurde erfolgreich abgeschlossen und am 29. Januar 2020 in den regulären Betrieb überführt.[15]
Ein weiteres Beispiel aus Deutschland ist das vom LRZ betriebene noch experimentell eingestufte WLAN mit der SSID eduroam-IPv6only an den Münchner Hochschulen.[16]
Mit dem Aufkommen von „IPv6-mostly“ z. B. bei der Ruhr-Universität Bochum[17] oder Google[18] verstärkt sich auch wieder der Anwendungsbereich im WLAN.
Begriffe
[Bearbeiten | Quelltext bearbeiten]SIIT[19] Stateless IP/ICMP Translation – zustandslose Übersetzung von IP-Paketen und ICMP-Paketen von IPv4 nach IPv6 und umgekehrt
PLAT provider-side translator (XLAT): Adressübersetzer beim Provider (zustandsbehaftet)
CLAT customer-side translator (XLAT): Adressübersetzer beim Kunden (zustandslos)
464 ergibt sich aus der zweifachen Übersetzung von 4 nach 6 und 6 nach 4.
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ RFC: – 464XLAT: Combination of Stateful and Stateless Translation. April 2013 (englisch).
- ↑ 464XLAT in mobile networks. (PDF; 114 kB) In: APNIC. 2015, S. 4, abgerufen am 7. November 2024 (englisch).
- ↑ code.google.com code.google.com
- ↑ Additional Internet APN settings. In: dev.windowsphone.com. 8. August 2015, archiviert vom am 18. Juni 2015; abgerufen am 7. November 2024 (englisch).
- ↑ Daniel Mark Havey: Core Network Stack Features in the Creators Update for Windows 10. In: Networking Blog. 13. Juli 2017, archiviert vom am 16. Juli 2017; abgerufen am 7. November 2024 (englisch).
- ↑ CLATD. – Daemon zur automatischen Konfiguration von CLAT unter Linux; itHub.
- ↑ Jack Wallen: TAYGA: Bridge an IPv6 Network Back to IPv4 using NAT64. In: The New Stack. 25. September 2020, abgerufen am 7. November 2024 (amerikanisches Englisch).
- ↑ nat64. In: Github. 23. Oktober 2024, abgerufen am 7. November 2024 (englisch).
- ↑ Jool is an Open Source SIIT and NAT64 for Linux
- ↑ Tundra-NAT64. In: Github. 22. Juli 2024, abgerufen am 7. November 2024.
- ↑ Johannes Spanier [Vodafone]: 464XLAT Trial in einem IPv6-only Mobilfunknetz. (PDF) IPv6 Kongress 2014, 23. Mai 2014, abgerufen am 22. August 2014 (Präsentation zum IPv6-Kongress 2014 von heise Netze, iX und DE-CIX).
- ↑ RFC: – DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. April 2011 (englisch).
- ↑ RFC: – IPv6-Only Preferred Option for DHCPv4. Oktober 2020 (englisch).
- ↑ Dusan Zivadinovic: IPv4-Dämmerung: Telekom testet IPv6-only-Kommunikation im Mobilfunk. In: heise online. 29. August 2018, abgerufen am 7. November 2024.
- ↑ Waldemar H.: Neuer IPv6-Zugang zum mobilen Internet im Netz der Telekom. In: Telekom hilf News. 8. Mai 2020, abgerufen am 7. November 2024.
- ↑ LRZ: IPv6 im MWN. In: Leibniz Rechenzentrum. Abgerufen am 7. November 2024.
- ↑ First experiences with deploying IPv6-Mostly DENOG15. Abgerufen am 29. Januar 2024 (englisch).
- ↑ Jen Linkova: Mission (Im)Possible. 27. November 2023, abgerufen am 29. Januar 2024 (englisch).
- ↑ RFC: – IP/ICMP Translation Algorithm. Juni 2016 (englisch).