464XLAT: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
K Textersetzung - „Obsoleted by“ durch „Ersetzt durch“ |
||
| (17 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
{{IPv6- | '''{{BASEPAGENAME}}''' - IPV4-IPv6-IPv4-Übersetzungsverfahren zur Anwendung in reinen IPv6-Netzwerken, beispielsweise bei [[Mobiles Internet|Mobilfunk]]-[[Internetdienstanbieter]]n | ||
== Beschreibung == | |||
464XLAT beschrieben in <nowiki>RFC 6877</nowiki> erlaubt Rechnern in [[IPv6]]-[[Rechnernetz|Netzwerken]] den Zugriff auf [[Internetdienste]], die nur via [[IPv4]] erreichbar sind. | |||
= | ; Begriffe | ||
{| class="wikitable options big gnu" | |||
! Begriff !! Definition !! Beschreibung | |||
|- | |||
| SIIT || Stateless IP/ICMP Translation || zustandslose Übersetzung von [[IP-Paket]]en und [[Internet Control Message Protocol|ICMP-Paketen]] von IPv4 nach IPv6 und umgekehrt | |||
|- | |||
| [[PLAT]] || provider-side translator (XLAT) || Adressübersetzer beim Provider ([[Zustandsbehaftung|zustandsbehaftet]]) | |||
|- | |||
| [[CLAT]] || customer-side translator (XLAT) || Adressübersetzer beim Kunden ([[Zustandslosigkeit|zustandslos]]) | |||
|- | |||
| [[464]] || || ergibt sich aus der zweifachen Übersetzung von 4 nach 6 und 6 nach 4. | |||
|} | |||
== Funktion == | |||
Der [[Client]] nutzt einen [[Stateless IP/ICMP Translation|SIIT]]-Übersetzer (CLAT) um IPv4-Pakete in IPv6 zu konvertieren. | |||
Der [[Client]] nutzt einen [[Stateless IP/ICMP Translation|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 (Software)|Server]] erreichen. | * Diese Pakete werden zu einem [[NAT64]]-Übersetzer (PLAT) geschickt und zurückübersetzt. | ||
* Dort können sie dann einen IPv4-[[Server (Software)|Server]] erreichen. | |||
[[Datei:464xlat.svg|800px|zentriert|Illustration zu 464XLAT]] | [[Datei:464xlat.svg|800px|zentriert|Illustration zu 464XLAT]] | ||
Die [[SIIT]]-Übersetzung (CLAT) kann direkt auf dem Client selbst mit spezieller Software oder auf einem IPv4-fähigen (W)[[Local Area Network|LAN]] davor erfolgen, beispielsweise einem Smartphone im [[Hot Spot (WLAN)#Mobiler WLAN-Hotspot|Hotspot-]] oder [[Tethering (Netzwerkfreigabe)|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 [[SIIT]]-Übersetzung (CLAT) kann direkt auf dem Client selbst mit spezieller Software oder auf einem IPv4-fähigen (W)[[Local Area Network|LAN]] davor erfolgen, beispielsweise einem Smartphone im [[Hot Spot (WLAN)#Mobiler WLAN-Hotspot|Hotspot-]] oder [[Tethering (Netzwerkfreigabe)|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 [[User Datagram Protocol|UDP]], [[Transmission Control Protocol|TCP]] und [[Internet Control Message Protocol|ICMP]]. | Die Nutzung von NAT64 beschränkt die Verbindungen auf das [[Client-Server-Modell]] mit den Protokollen [[User Datagram Protocol|UDP]], [[Transmission Control Protocol|TCP]] und [[Internet Control Message Protocol|ICMP]]. | ||
Es gibt (gab) CLAT-Implementationen für [[Android (Betriebssystem)|Android]], | Es gibt (gab) CLAT-Implementationen für [[Android (Betriebssystem)|Android]], [[MacOS]] (seit Ventura), das [[Nokia Nseries#Nokia N900|Nokia N900]] | ||
und [[Microsoft Windows Phone|Windows Phone]] sowie [[Microsoft Windows 10|Windows 10]] (seit 1703, nur für Verbindungen über Mobilfunkmodem, nicht über (W)LAN). | |||
CLAT kann unter [[Linux#Linux auf dem Desktop|Linux]] mit clatd ([https://github.com/toreanderson/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 [[:Datei:464xlat.svg|Grafik]] durch farblich gekennzeichnete Paketwege skizziert wurde: | Die folgende Tabelle fasst noch einmal zusammen, was in der [[:Datei:464xlat.svg|Grafik]] durch farblich gekennzeichnete Paketwege skizziert wurde: | ||
{| class="wikitable" style="text-align:center" | {| class="wikitable big" style="text-align:center" | ||
|- | |- | ||
! Programm und eigener Host | ! Programm und eigener Host | ||
| Zeile 55: | Zeile 74: | ||
|} | |} | ||
== Vor- und Nachteile | == Bewertung == | ||
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 [[Uniform Resource Identifier#Authority (im Sinne von Zuständigkeit)|URIs]] mit numerischen IPv4-Adressen anstelle von [[Domain Name System|Namen]] oder Software mit veralteten, auf IPv4 beschränkten [[Programmierschnittstelle]]n). | ; 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 [[Uniform Resource Identifier#Authority (im Sinne von Zuständigkeit)|URIs]] mit numerischen IPv4-Adressen anstelle von [[Domain Name System|Namen]] oder Software mit veralteten, auf IPv4 beschränkten [[Programmierschnittstelle]]n). | |||
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 [[Datenpaket]]s 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 [[Maximum Segment Size#MSS Clamping|MSS Clamping]] werden notwendig. | 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 [[Datenpaket]]s 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 [[Maximum Segment Size#MSS Clamping|MSS Clamping]] werden notwendig. | |||
464XLAT kann Probleme (<nowiki>RFC 6147</nowiki | 464XLAT kann Probleme (<nowiki>RFC 6147</nowiki>), die sich bei DNS64/NAT64 mit der Verletzung von [[Domain Name System Security Extensions|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 <nowiki>RFC 8925</nowiki | Bei Verwendung von „IPv6-mostly“ nach <nowiki>RFC 8925</nowiki> 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. | 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. | 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. | 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. | 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 [[Leibniz-Rechenzentrum|LRZ]] betriebene noch experimentell eingestufte WLAN mit der SSID ''eduroam-IPv6only'' an den Münchner Hochschulen. | Ein weiteres Beispiel aus Deutschland ist das vom [[Leibniz-Rechenzentrum|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 | Mit dem Aufkommen von „IPv6-mostly“ z. B. bei der Ruhr-Universität Bochum verstärkt sich auch wieder der Anwendungsbereich im WLAN. | ||
<noinclude> | |||
== Anhang == | |||
=== Siehe auch === | |||
<div style="column-count:2"> | |||
<categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree> | |||
</div> | |||
---- | |||
{{Special:PrefixIndex/{{BASEPAGENAME}}/}} | |||
=== Dokumentation === | |||
<!-- | |||
===== RFC ===== | |||
{| class="wikitable big options col1center col3center" | |||
|- | |||
! RFC !! Titel !! Jahr !! Status | |||
|- | |||
| [https://www.rfc-editor.org/info/rfc2460 2460] || Internet Protocol, Version 6 (IPv6) Specification || 1998 || Ersetzt durch [https://www.rfc-editor.org/info/rfc8200 RFC 8200] | |||
|- | |||
| [https://www.rfc-editor.org/info/rfc8200 8200] || Internet Protocol, Version 6 (IPv6) Specification || 2017 || Updated by [https://www.rfc-editor.org/info/rfc9673 RFC 9673] | |||
|} | |||
===== Man-Page ===== | |||
===== Info-Page ===== | |||
--> | |||
=== Links === | |||
==== Weblinks ==== | |||
# https://de.wikipedia.org/wiki/464XLAT | # https://de.wikipedia.org/wiki/464XLAT | ||
[[Kategorie:IPv6/ | [[Kategorie:IPv6/Translation]] | ||
</noinclude> | |||
Aktuelle Version vom 5. Juli 2025, 10:15 Uhr
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