Seit Jahren sollen Netze auf IPv6 umsteigen, um dem Mangel an IPv4-Adressen zu begegnen. Für die Endnutzer stellt dies ein Problem dar, da es immer noch viele ältere Geräte, Anwendungen und Dienste gibt, die in einer reinen IPv6-Umgebung nicht richtig funktionieren. Dual-Stack-Netze bieten daher das beste Nutzererlebnis, allerdings auf Kosten der IPv4-Knappheit. Während die meisten Netzbetreiber das neue IPv6 zunächst parallel zu ihrer bestehenden IPv4-Infrastruktur einführen, sind reine IPv6-Netze außerhalb des Mobilfunksektors nach wie vor unüblich. Der Dual-Stack-Ansatz gilt als notwendige Übergangsphase, die es ermöglicht, Erfahrungen mit dem IPv6-Protokoll zu sammeln und gleichzeitig die Störungen im Netzbetrieb zu minimieren.

Dual-Stack-Netze lösen jedoch nicht das Kernproblem: Die Erschöpfung der IPv4-Adressen. Ein Netzbetreiber benötigt immer noch die gleiche Menge an IPv4-Ressourcen wie bei reinen IPv4-Netzen. Noch schlimmer ist, dass eine Dual-Stack-Infrastruktur oft viele Jahre in Betrieb bleiben muss. Auch sind viele Anwendungen nach wie vor auf IPv4 angewiesen, was zu einem Henne-Ei-Problem führt: Reine IPv6-Netze scheinen bei inkompatiblen Anwendungen unpraktisch zu sein, doch die Anwendungen stützen sich weiterhin auf IPv4, weil reine IPv6-Netze selten sind.

Ein möglicher Problemlöser sind sogenannte IPv6-Mostly-Netze, die bei Bedarf die IPv4-Connectivity bereitstellen. Dies ermöglicht IPv6-fähigen Geräten, im IPv6-Only-Modus zu arbeiten, während IPv4 nahtlos an diejenigen geliefert wird, die diese Protokollversion benötigen.

Ein IPv6-Netzwerk ist einem Dual-Stack-Netzwerk sehr ähnlich, mit zwei zusätzlichen Schlüsselelementen. Zum einen bietet das Netzwerk NAT64-Funktionalität gemäß RFC 6146 [1], die es reinen IPv6-Clients ermöglicht, mit IPv4-Zielen zu kommunizieren. Zum zweiten verarbeitet die DHCPv4-Infrastruktur die DHCPv4-Option 108 gemäß RFC 8925 [2]. Bei der Verbindung mit einem IPv6-fähigen Netzwerksegment konfiguriert ein Endpunkt seinen IP-Stack auf der Grundlage seiner Fähigkeiten:

- IPv4-Only-Endpunkt: Erhält eine IPv4-Adresse über DHCPv4.

- Dual-Stack-Endpunkt (nicht nur IPv6-fähig): Dieser konfiguriert IPv6-Adressen über Stateless Address Autoconfiguration (SLAAC) und optional über DHCPv6. Zusätzlich erhält dieses Gerät eine IPv4-Adresse über DHCPv4.

- Ein ausschließlich IPv6-fähiger Endpunkt konfiguriert seine IPv6-Adressen und nimmt bei der Durchführung von DHCPv4 die Option 108 (gemäß RFC 8925) in die Parameter-Anforderungsliste auf. Der DHCP-Server gibt die Option zurück und der Endpunkt verzichtet auf die Anforderung einer IPv4-Adresse und bleibt im reinen IPv6-Modus.

Ein Netzwerksegment, das hauptsächlich auf IPv6 aufbaut, kann eine Mischung aus reinen IPv4-, Dual-Stack- und reinen IPv6-Geräten unterstützen. IPv6-Only-Endpunkte nutzen das vom Netzwerk bereitgestellte NAT64, um IPv4-Only-Ziele zu erreichen.

Der Begriff "reiner IPv6-fähiger Endpunkt" entspricht jedoch keiner strengen technischen Definition. Vielmehr beschreibt er ein Gerät, das ohne native IPv4-Konnektivität beziehungsweise IPv4-Adressen funktionieren kann und dabei die gleiche Benutzererfahrung bietet. Die gängigste Methode, dies zu erreichen, ist die Implementierung eines Übersetzers (CLAT; Customer-Side Translator), wie in "464XLAT" [3] (RFC 6877) beschrieben. Es ist bekannt, dass Geräte, die CLAT unterstützen (etwa Mobiltelefone), ohne Probleme im reinen IPv6-Modus arbeiten. In einigen Fällen kann ein Netzwerkadministrator jedoch ein Gerät auch ohne CLAT-Implementierung als IPv6-Only-fähig betrachten. Dies ist beispielsweise der Fall, wenn sämtliche auf dem Gerät ausgeführten Anwendungen dahingehend getestet wurden, dass sie in einer NAT64-Umgebung ohne IPv4-Abhängigkeiten funktionieren.

Eine effektive Möglichkeit, IPv4-Adressen ausschließlich auf Geräte zu beschränken, die diese benötigen, bietet die DHCP-Option "IPv6-Only Preferred DHCPv4" (Option 108). Die meisten CLAT-fähigen Systeme unterstützen auch diese Einstellung. Erkennt das Netz diese Option, kann es diese Geräte als reine IPv6-Geräte konfigurieren, sodass sie CLAT verwenden, um dem Netzwerk-Stack des lokalen Endpunkts IPv4-Adressen bereitzustellen.

Bestimmte Geräte, wie beispielsweise ressourcenbeschränkte eingebettete Systeme, können im reinen IPv6-Modus ohne CLAT arbeiten, wenn ihre Kommunikation auf IPv6-fähige Ziele beschränkt ist. Da diese Systeme häufig keine Unterstützung für Option 108 bieten, müssen Administratoren möglicherweise mit alternativen Methoden die Zuweisung von IPv4-Adressen verhindern. Ein Ansatz besteht darin, den IPv4-Verkehr auf der Switch-Port-Ebene zu blockieren. Dies kann entweder über statische ACL und einem Filter mit einer "deny ip any any"-Regel erfolgen oder über eine dynamische ACL via RADIUS: Kommt 802.1x-Authentifizierung zum Einsatz, kann RADIUS eine ACL bereitstellen, die den kompletten IPv4-Verkehr blockiert. Der ACL-basierte Ansatz hat jedoch einige Auswirkungen auf die Skalierbarkeit und erhöht die betriebliche Komplexität, weshalb er nur als Übergangslösung zu empfehlen ist.

IPv6-Only-Endpunkte benötigen NAT64 für den Zugang zu IPv4-Only-Zielen. Häufig entscheiden sich IT-Verantwortliche für eine Kombination von NAT44- und NAT64-Funktionen. Wenn jedoch nicht alle internen Dienste IPv6-fähig sind, muss NAT64 möglicherweise näher am Nutzer erfolgen. Verwenden interne IPv4-Only-Destinationen den RFC-1918-Adressraum, muss das bekannte Präfix "64:ff9b::/96" für NAT64 nicht zum Einsatz kommen (siehe Abschnitt 3.1 von RFC 6052).

Das Aktivieren von CLAT auf Endpunkten ist für den Betrieb von IPv4-Only-Anwendungen in IPv6-Only-Umgebungen unerlässlich. CLAT stellt eine RFC 1918-kompatible Adresse und eine IPv4-Standardroute zur Verfügung und gewährleistet so die Funktionalität auch ohne eine native IPv4-Adresse aus dem Netz. Ohne CLAT würden IPv4-Only-Anwendungen fehlschlagen, was sich negativ auf die Benutzerfreundlichkeit auswirkt und den Support-Overhead erhöht.

Unsere Empfehlungen für Netzwerkadministratoren, die die Endpunkte kontrollieren, lauten:

- CLAT und DHCPv4 Option 108: Kontrollieren Sie die Endpunktkonfiguration und aktivieren Sie CLAT auf Endpunkten, die die DHCPv4-Option 108 senden.

- Option 108 ohne CLAT können Sie dann aktivieren, wenn Sie bereit sind, IPv4-Only-Systeme und -Anwendungen zu identifizieren und zu reparieren oder, wenn für alle Anwendungen bestätigt ist, dass sie im IPv6-Only-Modus funktionieren.

Hosts, auf denen 464XLAT arbeitet, müssen das von NAT64 verwendete IPv6-Präfix (PREF64) ermitteln. Der Netzwerkadmin sollte die First-Hop-Router so konfigurieren, dass sie PREF64-Informationen in Router Advertisements [4] (RA; RFC 8781) aufnehmen, selbst wenn das Netzwerk DNS64 bereitstellt (damit Hosts DNS64-basierte Präfix-Erkennung nutzen können, RFC 7050). Dies ist erforderlich, da Hosts oder einzelne Anwendungen möglicherweise eine benutzerdefinierte DNS-Konfiguration haben (oder sogar einen lokalen DNS-Server betreiben) und die vom Netzwerk bereitgestellten DNS64-Informationen ignorieren, sodass sie die RFC-7050-Methode zur Erkennung von PREF64 nicht verwenden können. In Ermangelung von PREF64-Informationen in Router Advertisements (RA) wären solche Systeme nicht in der Lage, CLAT auszuführen, was zu Konnektivitätsproblemen bei allen IPv4-Only-Anwendungen führt, die auf dem betroffenen Gerät laufen. Da ein solches Device nicht in der Lage wäre, den vom Netzwerk bereitgestellten DNS64 zu verwenden, wäre auch der Zugang zu IPv4-Only-Zielen gestört. Alle gängigen Betriebssysteme unterstützen derzeit die DHCPv4-Option 108 und aktivieren CLAT gemäß RFC 8781 automatisch. Daher kann das Bereitstellen von PREF64-Informationen in RAs die Auswirkungen einer benutzerdefinierten DNS-Konfiguration auf diesen Systemen zuverlässig reduzieren. Der Empfang von PREF64-Informationen in RAs beschleunigt auch die Startzeit von CLAT, sodass eine IPv4-Adresse und eine Standardroute für Anwendungen viel schneller verfügbar werden.

DNS64 mit NAT64 ermöglicht es Endpunkten, die nur IPv6 nutzen, auf Ziele zuzugreifen, die nur IPv4 nutzen. Dies bringt aber einige Nachteile mit sich. So sorgt die DNSSEC-Inkompatibilität dafür, dass DNS64-Antworten bei der DNSSEC-Validierung fehlschlagen. Zudem bleiben Endpunkte oder Anwendungen, die mit benutzerdefinierten Resolvern konfiguriert sind, in Sachen DNS64 außen vor. Auch ergeben sich zusätzliche Anforderungen an die Anwendung: Um DNS64 nutzen zu können, müssen die Applikationen IPv6-fähig sein und DNS nutzen, also keine IPv4-Literale verwenden. Viele Programme erfüllen dies nicht und scheitern daher, wenn der Endpunkt keine IPv4-Adresse beziehungsweise native IPv4-Konnektivität hat.

Wenn das Netz PREF64 in RAs bereitstellt und alle Endpunkte garantiert CLAT aktivieren, ist DNS64 unnötig und Sie sollten es nicht einschalten. Verfügen jedoch einige reine IPv6-Geräte möglicherweise nicht über CLAT-Unterstützung, muss das Netz DNS64 bereitstellen, es sei denn, diese Endpunkte benötigen garantiert niemals reine IPv4-Ziele. Dies gilt zum Beispiel in spezialisierten Netzsegmenten, die ausschließlich mit IPv6-fähigen Zielen kommunizieren.

IPv6-Mostly-Netzwerke bieten erhebliche Vorteile gegenüber herkömmlichen Dual-Stack-Modellen, bei denen Endpunkte sowohl IPv4- als auch IPv6-Adressen haben. Da wäre zunächst die drastische Reduzierung des IPv4-Adressverbrauchs durch IPv6-Mostly. Diese Reduzierung hängt von den Fähigkeiten der Endgeräte ab (DHCPv4 Option 108 und CLAT-Unterstützung). In realen Szenarien, wie beispielsweise bei Wi-Fi-Konferenzen, können 60 bis 70 Prozent der Endpunkte den reinen IPv6-Betrieb unterstützen, was die Größe der IPv4-Subnetze um bis zu 75 Prozent reduziert.

Die Verwaltung von Dual-Stack-Netzwerken bedeutet den gleichzeitigen Betrieb von zwei Netzwerkebenen, was die Komplexität, die Kosten und die Fehleranfälligkeit erhöht. IPv6-Mostly ermöglicht die Abschaffung von IPv4 an vielen Endpunkten, was den Betrieb vereinfacht und die Zuverlässigkeit des gesamten Netzwerks verbessert. Zudem verringert sich die Abhängigkeit von DHCPv4. Da immer mehr Geräte nahtlos im reinen IPv6-Modus arbeiten, nimmt die Bedeutung des DHCPv4-Dienstes deutlich ab. Dies ermöglicht es, die DHCPv4-Infrastruktur zu verkleinern oder mit weniger strengen Service Level Objectives (SLOs) zu betreiben und so die Kosten und die Ressourcenzuweisung zu optimieren.

Bei der herkömmlichen Einführung von IPv6 waren neben Dual-Stack-Netzwerken auch separate Netzwerke erforderlich. IPv6-Mostly bietet auch hier erhebliche Verbesserungen, indem es als erstes die Skalierbarkeit erhöht: Separate reine IPv6-Netzwerke verdoppeln die Anzahl der SSIDs in drahtlosen Umgebungen, was zu einer Überlastung des Kanals und zu Leistungseinbußen führt. IPv6-Mostly erfordert keine zusätzlichen SSIDs. Außerdem können IPv4- und IPv6-Geräte in denselben verkabelten VLANs koexistieren, sodass keine zusätzlichen VLANs erforderlich sind.

Beim Troubleshooting erhalten Sie wiederum eine verbesserte Sichtbarkeit: Der vom User gewählte Rückgriff auf Dual-Stack-Netzwerke kann Probleme mit dem reinen IPv6-Betrieb verschleiern und die Meldung und Lösung von Problemen erschweren. IPv6-Mostly zwingt die Benutzer, sich mit allen Problemen auseinanderzusetzen, was die Identifizierung verbessert und die Behebung von Problemen für eine reibungslosere langfristige Migration ermöglicht. Schließlich gestattet IPv6-Mostly eine schrittweise Migration der Geräte auf Basis einzelner Segmente. Devices werden erst dann zu IPv6-Only, wenn sie mit diesem Modus vollständig kompatibel sind.

Das Migrieren der Endpunkte zu IPv6 ändert die Netzwerkdynamik grundlegend, da das IPv4-Sicherheitsnetz wegfällt. Dies gilt auch für den Maskierungseffekt von Happy Eyeballs [5]. IPv6-Konnektivitätsprobleme treten nun viel deutlicher zutage, auch solche, die sich zuvor in Dual-Stack-Umgebungen verbargen. Sie sollten auf Probleme sowohl an den Endpunkten als auch in der Netzwerkinfrastruktur vorbereitet sein, selbst wenn das Dual-Stack-Netzwerk problemlos läuft. Schauen wir uns daher einige Überlegungen zum Rollout an.

Bei begrenzter Kontrolle über die Endpunktkonfiguration ist ein Rollout pro Subnetz erforderlich, bei dem Sie die Option-108-Verarbeitung in DHCP schrittweise aktivieren. Wenn die Kontrolle über den Endpunkt vorhanden ist, ist ein Rollout pro Gerät möglich (zumindest für Betriebssysteme mit konfigurierbarer Option 108). Hierbei ist zu beachten, dass einige Betriebssysteme die Option-108-Unterstützung bedingungslos aktivieren und in dem Moment, in dem sie auf der Serverseite läuft, nur noch IPv6 verwenden. Daher empfehlen wir Ihnen, bei der DHCP-Server-seitigen Aktivierung die Option-108-Verarbeitung einzuschalten. Einige Betriebssysteme schalten automatisch auf IPv6-Only um. Ein Rollback in diesem Stadium betrifft das gesamte Subnetz. Auf den Endpunkten aktivieren Sie Option 108, wobei ein Rollback pro Gerät möglich ist. Für ein schnelles Rollback sollten Sie mit einem minimalen Option-108-Wert (300 Sekunden) beginnen und diesen erhöhen, wenn sich das IPv6-lastige Netz als zuverlässig erweist.

CLAT erfordert entweder ein dediziertes IPv6-Präfix oder eine dedizierte IPv6-Adresse. Derzeit verwenden alle Implementierungen SLAAC für den Erwerb von CLAT-Adressen. Um die CLAT-Funktionalität innerhalb von IPv6-Netzsegmenten zu ermöglichen, müssen die First-Hop-Router daher eine Prefix Information Option (PIO) bekanntgeben, die ein global routbares, SLAAC-geeignetes Präfix enthält, bei dem das Flag "Autonomous Address-Configuration" auf den Wert "Null" gesetzt ist.

Da es sich um ein IPv6-spezifisches Konzept handelt, werden IPv6-Erweiterungsheader in Dual-Stack-Netzen häufig vernachlässigt oder sogar explizit durch Sicherheitsrichtlinien verboten. Die Probleme, die das Blockieren von Erweiterungsheadern verursacht, verschleiert Happy Eyeballs – sie kommen jedoch zum Vorschein, wenn es kein IPv4 gibt, auf das sich zurückgreifen lässt. Das Netz sollte zumindest die Erweiterungsheader "Fragment Header" und "ESP Header" (für IPSec-Verkehr wie etwa VPN) zulassen.

In IPv6-Netzen treten meist versteckte Probleme auf, weil das IPv4-Sicherheitsnetz wegfällt. Während Implementierungsfehler sehr unterschiedlich sind, konzentrieren wir uns hier auf Konfiguration, Topologie oder Designentscheidungen. Es ist wichtig anzumerken, dass diese Probleme in Dual-Stack-Netzwerken wahrscheinlich bereits vorhanden sind, aber aufgrund des IPv4-Fallbacks unbemerkt bleiben.

In der Vergangenheit galt das Deaktivieren von IPv6 als schneller Workaround bei Problemen, sorgte jedoch für Geräte ohne IPv6. Ebenso kann die IT-Abteilung IPv6 in der Annahme deaktiviert oder gefiltert haben, dass es nicht weit verbreitet ist. Solche Devices, die die Option 108 anfordern, können sich in einem IPv6-lastigen Netzwerk nicht verbinden, da sie keine IPv4-Adressen erhalten und IPv6 deaktiviert ist. Sie müssen demnach sicherstellen, dass auf Ihren Endpunkten IPv6 eingeschaltet ist, bevor Sie das Netzwerk in den IPv6-lastigen Modus migrieren.

Erweitern Sie Ihr Netzwerk, ermöglicht es NAT44 von IPv4 den Endpunkten, die Konnektivität auf nachgelagerte Systeme auszudehnen, ohne dass das vorgelagerte Netzwerk davon Kenntnis hat oder eine Genehmigung erteilt. Dies führt allerdings zu Problemen bei IPv6, sofern die Endpunkte keine IPv4-Adressen haben.

Für die genannten Probleme bieten sich folgende Lösungen an:

- DHCPv6-PD zur Zuweisung von Präfixen an Endpunkte. Bietet nachgelagerten Systemen IPv6-Adressen und native Konnektivität.

- Aktivieren der CLAT-Funktion auf dem Endpunkt. Dieses Szenario ähnelt der in Abschnitt 4.1 von RFC 6877 beschriebenen drahtgebundenen Netzwerkarchitektur. Die nachgelagerten Systeme erhalten IPv4-Adressen und ihr IPv4-Verkehr wird vom Endpunkt in IPv6 übersetzt. Dieser Ansatz führt allerdings dazu, dass die nachgelagerten Systeme nur IPv4 verwenden und nicht von der Ende-zu-Ende-IPv6-Konnektivität profitieren. Um trotzdem die Vorteile von IPv6 zu nutzen, kombinieren Sie dies mit IPv6-Präfix-Delegation.

- Überbrückung und ND-Proxy: Der Endpunkt überbrückt den IPv6-Verkehr und verbirgt sämtliche nachgeschalteten Geräte hinter seiner MAC-Adresse. Dies kann jedoch zu Skalierbarkeitsproblemen führen, da eine einzelne MAC-Adresse vielen IPv6-Adressen zugeordnet wird.

Im Gegensatz zu IPv4, wo Endgeräte in der Regel über eine einzige IPv4-Adresse pro Schnittstelle verfügen, verwenden IPv6-Endgeräte von Natur aus mehrere Adressen: Die "Link-local"-Adresse, eine temporäre (üblich bei mobilen Geräten zum Schutz der Privatsphäre), eine stabile zur langfristigen Identifizierung und eine CLAT-Adresse. Endpunkte mit Containern, Namespaces oder ND-Proxy-Funktionen können sogar noch mehr Adressen haben.

Dies stellt eine Herausforderung für Netz-infrastrukturgeräte wie Switches, drahtlose Zugangspunkte und so weiter dar, die MAC-Adressen auf IPv6-Adressen abbilden, oft mit Begrenzungen, um eine Ressourcenerschöpfung oder DoS-Angriffe zu verhindern. Wird die Anzahl der IP-Adressen pro MAC überschritten, verhalten sich die Infrastrukturgeräte in den verschiedenen Implementierungen unterschiedlich, was zu inkonsistenten Konnektivitätsverlusten führt. Während einige Systeme neue Adressen ablehnen, löschen andere ältere Einträge, wodurch zuvor funktionierende Adressen ihre Verbindung verlieren. In all diesen Fällen erhalten Endpunkte und Anwendungen keine explizite Signalisierung, dass die Adresse unbrauchbar geworden ist.

Durch das Zuweisen von Präfixen an Endpunkte über DHCP-PD lässt sich dieses Problem und die damit verbundenen Skalierbarkeitsprobleme zwar beseitigen, aber dies unterstützen nicht alle Geräte. Sie sollten daher sicherstellen, dass die eingesetzten Infrastrukturgeräte eine ausreichende Anzahl von IPv6-Adressen zulassen, die sich der MAC-Adresse eines Clients zuordnen lassen, und sollten auf Ereignisse achten, die darauf hinweisen, dass das Limit erreicht ist (zum Beispiel Syslog-Meldungen).

Da der grundlegende IPv6-Header 20 Byte länger ist als der IPv4-Header, kann der Übergang von IPv4 zu IPv6 dazu führen, dass die Pakete die Pfad-MTU auf der IPv6-Seite überschreiten. In diesem Fall erzeugt NAT64 IPv6-Pakete mit Fragment-Headers. Gemäß RFC 6145 fragmentiert der Übersetzer standardmäßig IPv4-Pakete so, dass sie in 1280-Byte-IPv6-Pakete passen. Das bedeutet, dass alle IPv4-Pakete, die größer als 1260 Byte sind, fragmentieren oder verworfen werden, wenn das DF-Bit gesetzt ist).

Sie sollten die Pfad-MTU auf der IPv6-Seite (vom Übersetzer zu den reinen IPv6-Hosts) maximieren, um die Fragmentierung zu minimieren. NAT64-Geräte sollten Sie so konfigurieren, dass sie beim Fragmentieren von IPv4-Paketen die tatsächliche Pfad-MTU auf der IPv6-Seite verwenden.

Eine weitere häufige Ursache von IPv6-Fragmentierung ist die Verwendung von Protokollen wie DNS und RADIUS, bei denen die Serverantwort als ein einziges UDP-Datagramm gesendet werden muss. Sicherheitsrichtlinien müssen IPv6-Fragmente für zulässigen UDP-Verkehr erlauben, wenn Antworten in Form einzelner Datagramme erforderlich sind. IPv6-Fragmente für zulässigen TCP-Verkehr sollten Sie gestatten, es sei denn, die Netz-infrastruktur führt zuverlässig eine TCP-MSS-Bereitstellung durch.

In IPv6-Netzen ohne PREF64 in RAs verlassen sich Hosts auf DNS64, um das NAT64-Präfix für den CLAT-Betrieb zu ermitteln. Endpunkte oder Anwendungen, die mit benutzerdefinierten DNS-Resolvern konfiguriert sind (wie öffentliches oder unternehmenseigenes DNS), können das vom Netzwerk bereitgestellte DNS64 umgehen, was das Erkennen des NAT64-Präfixes verhindert und die CLAT-Funktionalität behindert.

Wenn möglich, sollten Sie PREF64 in RAs innerhalb von IPv6-lastigen Netzwerken einbauen, um die Abhängigkeit von DNS64 zu minimieren. Sie müssen sich der Möglichkeit von CLAT-Fehlern bewusst sein, wenn Endpunkte benutzerdefinierte Resolver in Umgebungen ohne PREF64 verwenden.

IPv6-Mostly bietet in der Praxis die beste Benutzererfahrung und verbraucht dabei möglichst wenig IPv4-Ressourcen. Andererseits erhöht sich dadurch die Komplexität herkömmlicher Dual-Stack-Netze und es werden keine direkten Einsparungen bei den IPv4-Ressourcen erzielt, da IPv4 immer noch überall notwendig ist, um ältere Geräte zu unterstützen. In den kommenden Jahren dürfte der Umfang des nativen IPv4-Verkehrs in solchen Netzen jedoch so weit zurückgehen, dass es sinnvoll wäre, IPv4 überhaupt nicht mehr einzusetzen.