Um die Verbreitung von IPv6 im Internet zu beschleunigen , wurden verschiedene Übergangsmechanismen vorgeschlagen, die diesen Prozess erleichtern sollen. Da IPv6 nicht direkt mit seinem Vorgängerprotokoll IPv4 interoperabel ist , ermöglichen diese Übergangsmechanismen die Kommunikation zwischen Hosts beider Netzwerktypen.

Um die technischen Kriterien zu erfüllen, benötigt IPv6 einen unkomplizierten Übergangsplan von IPv4. [ 1 ] Die Internet Engineering Task Force (IETF) führt Arbeitsgruppen und Diskussionen im Rahmen der IETF Internet Drafts und Request for Comments durch , um diese Übergangstechnologien zu entwickeln. Einige grundlegende IPv6-Übergangsmechanismen sind in RFC 4213 definiert.

Zustandlose IP/ICMP-Übersetzung

Stateless IP/ ICMP Translation ( SIIT ) übersetzt zwischen den Paketheader-Formaten von IPv6 und IPv4 . [ 2 ] Das SIIT-Verfahren definiert eine Klasse von IPv6-Adressen, die als IPv4-übersetzte Adressen bezeichnet werden . [3] Diese haben das Präfix ::ffff:0:0:0/96 und können als :: ffff : 0 : abcd geschrieben werden , wobei die IPv4-formatierte Adresse abcd auf einen IPv6-fähigen Knoten verweist. Das Präfix wurde so gewählt, dass die Prüfsumme den Wert Null ergibt, um Änderungen an der Prüfsumme des Transportprotokoll-Headers zu vermeiden. [ 4 ] Der Algorithmus kann in einer Lösung verwendet werden, die es IPv6-Hosts ohne fest zugewiesene IPv4-Adresse ermöglicht, mit reinen IPv4-Hosts zu kommunizieren. Details zur Adresszuweisung und zum Routing werden in der Spezifikation nicht behandelt. SIIT kann als Spezialfall der zustandslosen Netzwerkadressübersetzung betrachtet werden .

Die Spezifikation ist ein Produkt der IETF-Arbeitsgruppe NGTRANS und wurde ursprünglich im Februar 2000 von E. Nordmark von Sun Microsystems entworfen . [ 5 ] Sie wurde 2011 überarbeitet [ 6 ] und 2016 in ihrer aktuellen Fassung veröffentlicht. [ 4 ]

Tunnelbroker

Ein Tunnelbroker stellt IPv6-Konnektivität bereit, indem er IPv6-Datenverkehr in IPv4-Internet-Transitverbindungen einkapselt, typischerweise mithilfe von 6in4 . Dadurch werden IPv6-Tunnel innerhalb des IPv4-Internets eingerichtet. Die Tunnel können mit dem Tunnel Setup Protocol (TSP) [ 7 ] oder AYIYA [ 8 ] verwaltet werden .

6.

6rd wurde von Rémi Després entwickelt . [ 9 ] [ 10 ] Es handelt sich um einen Mechanismus zur schnellen Bereitstellung des IPv6-Dienstes über IPv4- Infrastrukturen von Internetdienstanbietern ( ISPs ). Er verwendet zustandslose Adresszuordnungen zwischen IPv4- und IPv6 -Adressen und überträgt IPv6- Pakete über automatische Tunnel, die dieselben optimierten Routen zwischen den Kundenknoten nutzen wie IPv4 -Pakete. [ 11 ]

Es wurde 2007 für eine frühe großflächige Implementierung eines IPv6-Dienstes mit nativen Adressen verwendet (RFC 5569 [ 12 ] ). Die Spezifikation des Protokolls im Standardisierungsprozess findet sich in RFC 5969. [ 13 ]

Transport Relay Übersetzung

Das Transport Relay Translation ( TRT )-Verfahren fungiert als Zwischengerät zwischen zwei Hosts. Die Funktion des Übersetzers besteht darin, IPv6- in IPv4-Adressen und umgekehrt zu konvertieren. TRT erreicht diese Übersetzung durch IP-Adresszuordnung und eine benutzerdefinierte IP-Adresse. [ 14 ]

Die Adresse lautet beispielsweise fec0:0:0:1:: / 64 , wenn Pakete von einer IPv6-Adresse ( fec0:0:0:1:: /64 ) an eine IPv4-Adresse ( 10.1.1.1 ) übertragen werden sollen . Die Pakete werden zunächst über ein IPv6/TCP-Protokoll zum Übersetzer und anschließend vom Übersetzer über ein IPv4/TCP-Protokoll zum IPv4-Host geleitet. [ 15 ]

TRT verwendet eine ähnliche Operation wie die DNS-Übersetzung zwischen AAAA- und A-Einträgen, die als DNS ALG bekannt ist . [ 16 ]

NAT64

NAT64 und DNS64

NAT64 ist ein Mechanismus, der es IPv6-Hosts ermöglicht, mit IPv4-Servern zu kommunizieren. Der NAT64-Server ist der Endpunkt für mindestens eine IPv4-Adresse und ein 32-Bit-IPv6-Netzwerksegment, z. B. 64:ff9b:: / 96 . [ 3 ] Der IPv6-Client bettet die IPv4-Adresse, mit der er kommunizieren möchte, in diese Bits ein und sendet seine Pakete an die resultierende Adresse. Der NAT64-Server erstellt daraufhin eine NAT -Zuordnung zwischen der IPv6- und der IPv4-Adresse, wodurch die Kommunikation ermöglicht wird. [ 17 ] NAT64 wird typischerweise in Verbindung mit DNS64 verwendet.

DNS64

DNS64 beschreibt einen DNS-Server , der bei der Anfrage nach den AAAA-Einträgen einer Domain , aber dem Vorfinden von A-Einträgen , die AAAA-Einträge aus den A-Einträgen synthetisiert. Der erste Teil der synthetisierten IPv6-Adresse verweist auf einen IPv6/IPv4-Übersetzer, der zweite Teil enthält die IPv4-Adresse aus dem A-Eintrag. Bei diesem Übersetzer handelt es sich üblicherweise um einen NAT64-Server. Die Spezifikation von DNS64 im Standardisierungsprozess findet sich in RFC 6147. [ 18 ]

Dieser Übergangsmechanismus weist zwei bemerkenswerte Probleme auf:

  • Dies funktioniert nur in Fällen, in denen DNS verwendet wird, um die Adresse des Remote-Hosts zu ermitteln; werden IPv4-Literale verwendet, kommt der DNS64-Server nicht zum Einsatz.
  • Da der DNS64-Server Datensätze zurückgeben muss, die nicht vom Domaininhaber angegeben wurden, schlägt die DNSSEC- Validierung gegen den Stammserver in Fällen fehl, in denen der DNS-Server, der die Übersetzung durchführt, nicht der Server des Domaininhabers ist.
Der DNS-Resolver 2606:4700:4700:64 synthetisiert AAAA-Einträge für ipv6test.google.com zu einer NAT64-Adresse: 64:ff9b::<original-ipv4> $ nslookup ipv6test.google.com 2606:4700:4700::64Nicht autorisierte Antwort : Kanonischer Name von ipv6test.google.com = ipv6test.l.google.com. Name : ipv6test.l.google.com Adresse : 64:ff9b::8efa:c3e4
Implementierungen

ISATAP

ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) ist ein IPv6-Übergangsmechanismus, der dazu dient, IPv6-Pakete zwischen Dual-Stack-Knoten über einem IPv4-Netzwerk zu übertragen.

Im Gegensatz zu 6over4 (einem älteren, ähnlichen Protokoll, das IPv4-Multicast verwendet) nutzt ISATAP IPv4 als virtuelle Nonbroadcast Multiple-Access Network (NBMA)-Datenverbindungsschicht, sodass es nicht die zugrunde liegende IPv4-Netzwerkinfrastruktur benötigt, um Multicast zu unterstützen.

464XLAT

464XLAT [ 21 ] ermöglicht es Clients in reinen IPv6-Netzwerken, auf reine IPv4-Internetdienste zuzugreifen. [ 22 ] [ 23 ] Es erweitert NAT64 um einen zusätzlichen Übersetzungsschritt von IPv4 zu IPv6, wodurch reine IPv4-Clients oder -Anwendungen über reine IPv6-Verbindungen kommunizieren können.

Der Client verwendet einen SIIT-Übersetzer, um Pakete von IPv4 in IPv6 zu konvertieren. Diese werden dann an einen NAT64- Übersetzer gesendet, der sie von IPv6 wieder in IPv4 übersetzt und an einen reinen IPv4-Server weiterleitet.

Der Client-Übersetzer kann entweder direkt auf dem Client oder auf einem Zwischengerät implementiert werden und wird als CLAT (Customer-side transLATor) bezeichnet. RFC  7335 spezifiziert ein spezielles IPv4-Präfix 192.0.0.0/29, das von der IANA für IPv4-Übergangsszenarien reserviert ist und als IPv4 Service Continuity Prefix bekannt ist . Dieses war ursprünglich speziell für DS-Lite vorgesehen, wird aber mittlerweile für alle Übergangsmechanismen mit ähnlicher Funktionsweise verwendet. Die CLAT-Implementierung kann Adressen dieses Präfixes für die interne Nummerierung nutzen, obwohl Pakete mit diesen Adressen niemals über das Netzwerk versendet werden.

Der NAT64-Übersetzer, auch PLAT (providerseitiger Übersetzer) genannt, muss sowohl den Server als auch den Client (über CLAT) erreichen können. Der PLAT ist identisch mit dem eigenständigen NAT64-Übersetzer; seitens des Anbieters sind keine Änderungen erforderlich, um 464XLAT zu unterstützen. Die Verwendung von NAT64 beschränkt Verbindungen auf ein Client-Server-Modell mit UDP, TCP und ICMP.

Wenn DNS64 in einem reinen IPv6-Netzwerk verwendet wird, initiieren die meisten Anwendungen, die eine Verbindung zu einem reinen IPv4-Dienst benötigen, bereits nativ Verbindungen über IPv6 zum NAT64-Präfix. Das bedeutet, dass 464XLAT nur für Anwendungen erforderlich ist, die IPv6 nicht unterstützen, IPv4 bevorzugen oder fest codierte IPv4-Adressen verwenden.

Implementierungen
  • T-Mobile US nutzt seit einiger Zeit ausschließlich IPv6 mit dem Router 464XLAT. [ 24 ]
  • Orange Polska begann im September 2013 mit einem reinen IPv6-Dienst (CLAT/NAT64/DNS) und migrierte bis Januar 2015 alle ADSL- , VDSL- und FTTH- Gateways. [ 25 ]
  • Telstra hat im Februar 2020 seine Mobilfunkdienste auf IPv6 und 464XLAT umgestellt. [ 26 ]
  • Android enthält seit Jelly Bean 4.3, das im Jahr 2013 veröffentlicht wurde, eine native Implementierung von CLAT. [ 27 ]
  • Windows 10 verfügt seit dem Creators Update 2017 über eine native WWAN-Implementierung von 464XLAT für Desktop- und Mobilgeräte . [ 28 ]
  • Windows 11 (Version 26H1 und älter) ist wie Windows 10 auf die WWAN-Schnittstelle beschränkt. Erweiterte CLAT-Unterstützung für andere Netzwerkgeräte wurde in den Windows Insider Canary Builds (>=29599.1000) hinzugefügt. Die Implementierung entspricht den Standards RFC 7050 (ipv4only.arpa DNS-Abfrage), RFC 8781 (PREF64) und RFC 8925 (DHCP Option 108). [ 29 ] .
  • macOS bietet ab Ventura, das im Jahr 2022 veröffentlicht wurde, native CLAT-Unterstützung. [ 30 ]
  • iOS verfügt seit Version 12.0, die 2018 veröffentlicht wurde, über eine native CLAT-Implementierung. [ 31 ] Darüber hinaus verlangt Apple, dass alle im App Store eingereichten Apps auch in reinen IPv6-Netzwerken funktionieren. [ 32 ]
  • clatd ist eine CLAT-Implementierung für Linux . [ 33 ]
  • NetworkManager ab Version 1.58 (Stand: 17.06.2026) verwendet eine BPF-basierte CLAT-Implementierung [ 34 ] [ 35 ].
  • Das Linux-Betriebssystem OpenWRT für Router bietet optionale Unterstützung für CLAT über das Paket 464xlat. [ 36 ]
  • FreeBSD implementiert NAT64 CLAT seit Version 12.1. [ 37 ]

Dual-Stack Lite (DS-Lite)

DS-Lite

Die Dual-Stack-Lite- Technologie benötigt keine IPv4-Adresse für Kundengeräte (CPE) zur Bereitstellung des Internetzugangs. [ 38 ] Das CPE verteilt private IPv4-Adressen an die LAN-Clients gemäß den Netzwerkanforderungen im lokalen Netzwerk. Es kapselt IPv4-Pakete in IPv6-Pakete ein und übermittelt diese über seine globale IPv6-Verbindung an den Carrier-Grade-NAT- Router (CGN) des Internetdienstanbieters (ISP), der über eine globale IPv4-Adresse verfügt. Das ursprüngliche IPv4-Paket wird wiederhergestellt, einer Adressübersetzung unterzogen und anschließend an das öffentliche IPv4-Internet weitergeleitet. Der Carrier-Grade-NAT-Router identifiziert Datenflüsse eindeutig, indem er das verwendete Protokoll (z. B. UDP, SCTP), die öffentliche IPv6-Adresse des Kunden, die private IPv4-Adresse des Kundenknotens, gegebenenfalls die Portnummer des Kundenknotens (z. B. bei UDP oder TCP) sowie gegebenenfalls die IPv4-Adresse und Portnummer des Upstream-Knotens als Sitzung protokolliert.

Lightweight 4over6 erweitert DS-Lite, indem es die NAT-Funktionalität von der ISP-Seite auf die CPE verlagert und somit die Implementierung von Carrier-Grade-NAT überflüssig macht. [ 39 ] Dies wird durch die Zuweisung eines Portbereichs für eine gemeinsam genutzte IPv4-Adresse an jedes CPE erreicht. Durch die Verlagerung der NAT-Funktionalität auf das CPE kann der ISP die Menge der für jeden Teilnehmer zu verfolgenden Statusinformationen reduzieren, was die Skalierbarkeit der Übersetzungsinfrastruktur verbessert.

V4-via-v6-Routing

V4-via-v6 -Routing [ 40 ] ist eine Technik, bei der IPv4-Adressen ausschließlich Endgeräten und IPv6-Adressen nur Zwischenroutern zugewiesen werden. IPv4-Routen werden wie gewohnt propagiert, ohne Paketübersetzung oder -kapselung, sondern mit einem IPv6-Next-Hop. V4-via-v6 reduziert den Verwaltungsaufwand, da dem Kernnetzwerk nur IPv6-Adressen zugewiesen werden müssen. Es ist jedoch weiterhin erforderlich, dass das Kernnetzwerk IPv4-Pakete weiterleiten kann.

V4-via-v6 ist für das Border Gateway Protocol (BGP) [ 41 ] und das Babel-Routing-Protokoll [ 42 ] definiert . Es wurde im Bird Internet-Routing-Daemon [ 43 ] und in babeld [ 44 ] implementiert .

KARTE

Mapping of Address and Port (MAP) ist ein Cisco- Vorschlag für den IPv6-Übergang , der die A+P- Portadressübersetzung mit dem Tunneln von IPv4-Paketen über das interne IPv6- Netzwerk eines Internetdienstanbieters kombiniert. [ 45 ] MAP-T [ 46 ] und MAP-E [ 47 ] wurden im Juli 2015 in den Standardisierungsprozess aufgenommen, und Sky Italia hat MAP-T bereits im Jahr 2021 in seine Internetdienste integriert. [ 48 ]

Entwurfsvorschläge

Folgende Mechanismen werden von der IETF noch diskutiert oder wurden verworfen:

4.

IPv4 Residual Deployment (4rd) ist ein experimenteller Mechanismus [ 49 ] zur Unterstützung der verbleibenden Bereitstellung von IPv4-Diensten in IPv6- Netzwerken. Wie 6rd verwendet er zustandslose Adresszuordnungen zwischen IPv6 und IPv4 . Er unterstützt eine Erweiterung der IPv4-Adressierung basierend auf Transportschichtports. Es handelt sich dabei um eine zustandslose Variante des A+P- Modells.

Veraltete Mechanismen

Diese Mechanismen wurden von der IETF als veraltet eingestuft:

NAT-PT

Die Netzwerkadressübersetzung/Protokollübersetzung ( NAT-PT ) ist in RFC 2766 definiert, wurde jedoch aufgrund zahlreicher Probleme durch RFC 4966 ersetzt und als veraltet eingestuft. Sie wird typischerweise in Verbindung mit einer DNS -Anwendungsgateway- Implementierung (DNS-ALG) verwendet.

NAPT-PT

Netzwerkadress-Port-Übersetzung + Protokollübersetzung (NAT + Protocol Translation , ebenfalls in RFC 2766 beschrieben ) ist zwar nahezu identisch mit NAT-PT, fügt aber zusätzlich zur Adressübersetzung auch eine Portübersetzung hinzu. Dies dient primär dazu, zu verhindern, dass zwei Hosts auf der einen Seite des Mechanismus denselben freigegebenen Port auf der anderen Seite verwenden, was zu Anwendungsinstabilität und Sicherheitslücken führen könnte. Dieser Mechanismus gilt laut RFC 4966 als veraltet.

Implementierungen

  • CLATD , eine CLAT/SIIT-DC Edge Relay-Implementierung für Linux
  • TAYGA , eine zustandslose NAT64-Implementierung für Linux
  • Jool , eine SIIT- und zustandsbehaftete NAT64-Implementierung für Linux
  • naptd , NAT-PT auf Benutzerebene
  • Address Family Transition Router (AFTR) , eine DS-Lite-Implementierung
  • Microsoft Forefront Unified Access Gateway , eine eingestellte Reverse-Proxy- und VPN-Lösung, die DNS64 und NAT64 implementiert
  • BIND , der Berkeley Internet Name Domain DNS-Server, implementiert DNS64 seit Version 9.8
  • PF (Firewall) , der OpenBSD -Paketfilter, unterstützt seit Version 5.1 die IP-Versionsübersetzung und beinhaltet NAT64.

Siehe auch

Referenzen

  1. ^ Partridge, C.; Kastenholz, F. (Dezember 1994). Technische Kriterien für die Auswahl von IP der nächsten Generation (IPng) . IETF . doi : 10.17487/RFC1726 . RFC 1726 .
  2. F. Baker , X. Li, C. Bao und K. Yin (April 2011). Framework for IPv4/IPv6 Translation . Internet Engineering Task Force . doi : 10.17487/RFC6144 . ISSN 2070-1721 . RFC 6144 . Informativ.
  3. ^ a b C. Bao; C. Huitema ; M. Bagnulo; M. Boucadair; X. Li (Oktober 2010). IPv6 Addressing of IPv4/IPv6 Translators . Internet Engineering Task Force . doi : 10.17487/RFC6052 . ISSN 2070-1721 . RFC 6052 . Vorgeschlagener Standard. Aktualisiert RFC  4291 .
  4. ^ abC. Bao; X. Li; F. Baker; T. Anderson; F. Gont (June 2016). Stateless IP/ICMP Translation Algorithm. IETF. doi:10.17487/RFC7915. RFC7915.
  5. ^E. Nordmark (February 2000). Stateless IP/ICMP Translation Algorithm (SIIT). Network Working Group. doi:10.17487/RFC2765. RFC2765.Obsolete. Obsoleted by RFC 6145.
  6. ^X. Li; C. Bao; F. Baker (April 2011). IP/ICMP Translation Algorithm. Internet Engineering Task Force. doi:10.17487/RFC6145. ISSN 2070-1721. RFC6145.Obsolete. Obsoleted by RFC 7915. Updated by RFC 6791 and 7757.
  7. ^M. Blanchet; F. Parent (February 2010). IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP). IETF. doi:10.17487/RFC5572. ISSN 2070-1721. RFC5572.Experimental. Independent Submission.
  8. ^A. Durand; P. Fasano; I. Guardini; D. Lento (January 2001). IPv6 Tunnel Broker. Network Working Group. doi:10.17487/RFC3053. RFC3053.Informational.
  9. ^RFC 5569. IETF. doi:10.17487/RFC5569.
  10. ^"IETF RFC 5569 - IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)".
  11. ^"IPv6 Rapid Deployment"(PDF).
  12. ^Despres, R. (January 2010). IPv6 Rapid Deployment on IPv4 Infrastructures (6rd). IETF. doi:10.17487/RFC5569. RFC5569.
  13. ^Troan, O. (August 2010). IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) – Protocol Specification. IETF. doi:10.17487/RFC5969. RFC5969.
  14. ^ J. Hagino; K. Yamamoto (Juni 2001). Ein IPv6-zu-IPv4-Transport-Relay-Übersetzer . Network Working Group. doi : 10.17487/RFC3142 . RFC 3142 .Informativ.
  15. ^ Shanmugaraja, P. „Design and Implementation of Transport Relay Translator and its security Mitigations“ . researchgate.net . Research Gate . Abgerufen am 28. Juni 2024 .
  16. ^ P. Srisuresh; G. Tsirtsis; P. Akkiraju; A. Heffernan (September 1999). DNS extensions to Network Address Translators (DNS_ALG) . Network Working Group. doi : 10.17487/RFC2694 . RFC 2694 .Informativ.
  17. ^ M. Bagnulo; P. Matthews; I. van Beijnum (April 2011). Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers . Internet Engineering Task Force . doi : 10.17487/RFC6146 . ISSN 2070-1721 . RFC 6146 . Vorgeschlagener Standard.
  18. ^ Bagnulo, M.; Sullivan, A.; Matthews, P.; van Beijnum, I. (April 2011). DNS64: DNS-Erweiterungen für die Netzwerkadressübersetzung von IPv6-Clients zu IPv4-Servern . IETF . doi : 10.17487/RFC6147 . RFC 6147 .
  19. ^ "README.DNS64" . GitHub . Archiviert vom Original am 07.04.2024 . Abgerufen am 07.04.2024 .
  20. ^ „Technitium DNS Server“ . Technitium.com . Abgerufen am 06.03.2026 .{{cite web}}: CS1 maint: url-status ( link )
  21. ^ M. Mawatari; M. Kawashima; C. Byrne (April 2013). 464XLAT: Kombination von zustandsbehafteter und zustandsloser Übersetzung . Internet Engineering Task Force . doi : 10.17487/RFC6877 . ISSN 2070-1721 . RFC 6877 . Informativ.
  22. ^ Žorž, Jan (3. April 2013). „Video: 464XLAT Live Demo at World IPv6 Congress in Paris“ . Internet Society . Archiviert vom Original am 13. September 2017. Abgerufen am 5. August 2013 .
  23. ^ „464XLAT – Eine Lösung zur Bereitstellung von IPv4-Diensten über ein reines IPv6-Netzwerk“ . T-Mobile USA . Archiviert vom Original am 12. November 2020. Abgerufen am 5. August 2013 .
  24. ^ „Fallstudie: T-Mobile US setzt ausschließlich auf IPv6 mit 464XLAT“ . Internet Society . 13. Juni 2014. Archiviert vom Original am 4. Februar 2024. Abgerufen am 15. Januar 2023 .
  25. ^ Twardowska, Marta (6. Januar 2015). „Orange Polska hat mit SoftAtHome die weltweit erste innovative IPv6-Lösung auf den Markt gebracht“ . Business Wire . Archiviert vom Original am 15. Januar 2023. Abgerufen am 15. Januar 2023 .
  26. ^ „Telstra IPv6 Wireless Enablement – ​​IPv6 Single Stack“ . 6. Februar 2020. Archiviert vom Original am 12. Juni 2023. Abgerufen am 12. Juni 2023 .
  27. ^ Drown, Dan. „Was ist Android CLAT?“ . Dans Notizen . Archiviert vom Original am 17. Dezember 2022 . Abgerufen am 15. Januar 2023 .
  28. ^ Havey, Daniel; Balasubramanian, Praveen (14. Februar 2019). „Kernfunktionen des Netzwerk-Stacks im Creators Update für Windows 10“ . Microsoft Networking Blog . Archiviert vom Original am 1. Februar 2023. Abgerufen am 15. Januar 2023 .
  29. ^ „Ankündigung der öffentlichen Vorschau von Windows CLAT“ . Microsoft Networking Blog . Abgerufen am 10. Juni 2026 .
  30. ^ „Twitter“ . Abgerufen am 27. Juni 2022 .
  31. ^ "[v6ops] iOS12 IPv6-only" . Abgerufen am 5. November 2018 .
  32. ^ van Beijnum, Iljitsch (16.06.2015). „Apple an iOS-Entwickler: IPv6-basierter Mobilfunkdienst kommt bald, bereitet eure Apps vor“ . Ars Technica . Archiviert vom Original am 28.06.2016 . Abgerufen am 2. Juli 2016 .
  33. ^ Anderson, Tore (20. Mai 2019). "clatd" . GitHub . Archiviert vom Original am 17. Dezember 2022. Abgerufen am 15. Januar 2023 .
  34. ^ Strodl, Mary (12. Januar 2025). „Unterstützung für CLAT mithilfe eines BPF-Programms hinzufügen“ . GitLab . Abgerufen am 6. Februar 2025 .
  35. ^ "NEWS · 1.57.2-dev · NetworkManager / NetworkManager · GitLab" . GitLab . Abgerufen am 17.06.2026 .
  36. ^ „OpenWrt Wiki-Paket: 464xlat“ . OpenWrt . Abgerufen am 1. April 2024 .
  37. ^ Baoi, Danilo G. (19. Juni 2021). „FreeBSD 12.1-RELEASE Release Notes“ . FreeBSD . Archiviert vom Original am 15. Januar 2023. Abgerufen am 15. Januar 2023 .
  38. ^ A. Durand; R. Droms; J. Woodyatt; Y. Lee (August 2011). Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion . Internet Engineering Task Force . doi : 10.17487/RFC6333 . ISSN 2070-1721 . RFC 6333 . Vorgeschlagener Standard.
  39. ^ Y. Cui; Q. Sun; M. Boucadair; T. Tsou; Y. Lee; I. Farrer (Juli 2015). Lightweight 4over6: Eine Erweiterung der Dual-Stack Lite-Architektur . Internet Engineering Task Force . doi : 10.17487/RFC7596 . ISSN 2070-1721 . RFC 7596 . Vorgeschlagener Standard.
  40. ^ Chroboczek, Juliusz; Kumari, Warren; Høiland-Jørgensen, Toke (Jan 2025). IPv4 routes with an IPv6 next hop . IETF . ID draft-chroboczek-intarea-v4-via-v6-03.
  41. ^ Le Faucheur, François; Rosen, Eric (Mai 2009). Werbung für IPv4-Netzwerkschicht-Erreichbarkeitsinformationen mit einem IPv6-Next-Hop . IETF . doi : 10.17487/RFC5549 . RFC 5549 .
  42. ^ Chroboczek, Juliusz (Mai 2022). Pv4-Routen mit einem IPv6-Next-Hop im Babel-Routing-Protokoll . IETF . doi : 10.17487/RFC9229 . RFC 9229 .
  43. ^ Rammhold, Andreas (15. Dezember 2020). „[RFC] Babel: Unterstützung für v4viav6 hinzufügen“ . BIRD Internet Routing Daemon . Archiviert vom Original am 29.12.2022 . Abgerufen am 15.01.2023 .
  44. ^ Chroboczek, Juliusz (5. Mai 2022). „[Babel-Benutzer] ANNOUNCE: babeld-1.12“ . Debian Alioth Lists . Archiviert vom Original am 29.12.2022 . Abgerufen am 15.01.2023 .
  45. ^ Mark Townsley (24. September 2012). „Zuordnung von Adresse und Port“ (PDF) . Cisco. Archiviert (PDF) vom Original am 29.12.2022 . Abgerufen am 25.09.2012 .
  46. ^ X. Li; C. Bao; O. Troan; S. Matsushima; T. Murakami (Juli 2015). W. Dec (Hrsg.). Mapping of Address and Port using Translation (MAP-T) . Internet Engineering Task Force . doi : 10.17487/RFC7599 . ISSN 2070-1721 . RFC 7599 . Vorgeschlagener Standard.
  47. ^ W. Dec; X. Li; C. Bao; S. Matsushima; T. Murakami (Juli 2015). O. Troan; T. Taylor (Hrsg.). Mapping of Address and Port with Encapsulation (MAP-E) . Internet Engineering Task Force . doi : 10.17487/RFC7597 . ISSN 2070-1721 . RFC 7597 . Vorgeschlagener Standard.
  48. ^ Patterson, Richard (Mai 2021). „IPv6-Only with MAP-T“ . RIPE NCC Open House . Archiviert vom Original am 21. Februar 2023. Abgerufen am 1. August 2023 .
  49. ^ R. Despres; R. Penno; Y. Lee; G. Chen; M. Chen (Juli 2015). S. Jiang (Hrsg.). IPv4 Residual Deployment via IPv6 - A Stateless Solution (4. Auflage) . Internet Engineering Task Force . doi : 10.17487/RFC7600 . ISSN 2070-1721 . RFC 7600 . Experimental.