464XLAT
464XLAT - IPV4-IPv6-IPv4-Übersetzungsverfahren zur Anwendung in reinen IPv6-Netzwerken, beispielsweise bei Mobilfunk-Internetdienstanbietern
Beschreibung
464XLAT beschrieben in RFC 6877 erlaubt Rechnern in IPv6-Netzwerken den Zugriff auf Internetdienste, die nur via IPv4 erreichbar sind.
- Begriffe
| Begriff | Definition | Beschreibung |
|---|---|---|
| SIIT | 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. |
Funktion
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, MacOS (seit Ventura), das Nokia N900 und Windows Phone sowie Windows 10 (seit 1703, nur für Verbindungen über Mobilfunkmodem, nicht über (W)LAN).
CLAT kann unter Linux mit clatd (CLATD-Daemon zur automatischen Konfiguration von CLAT unter Linux; itHub. (basierend auf tayga oder dem Kernelmodul nat46), Jool oder tundra 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 |
Bewertung
- Vor- und Nachteile
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.
464XLAT kann Probleme (RFC 6147), 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 kann unter bestimmten Umständen auf DNS64 verzichtet werden.
- Es werden dann nur 464xlat und native Verbindungswege zugelassen, DNSSEC ist dabei unbeeinträchtigt.
Anwendung
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. Dieser Test wurde erfolgreich abgeschlossen und am 29.
- Januar 2020 in den regulären Betrieb überführt.
Ein weiteres Beispiel aus Deutschland ist das vom LRZ betriebene noch experimentell eingestufte WLAN mit der SSID eduroam-IPv6only an den Münchner Hochschulen.
Mit dem Aufkommen von „IPv6-mostly“ z. B. bei der Ruhr-Universität Bochum verstärkt sich auch wieder der Anwendungsbereich im WLAN.
Anhang
Siehe auch
Dokumentation
Links
Weblinks