IPv6-Migration: Der unterschätzte Engpass bei der Cloud-Transformation

Die Lage 2026: IPv6 ist Mehrheitsprotokoll, IPv4 ist Kostenfaktor

Zwei Entwicklungen haben die Ausgangslage in den letzten Jahren verschoben. Erstens die Nutzung: Nach Googles Messungen greifen seit Ende März 2026 erstmals mehr als 50 Prozent aller Nutzer weltweit über natives IPv6 auf Google-Dienste zu. APNIC misst mit anderer Methodik rund 42 Prozent, beide Kurven zeigen stabil nach oben. Deutschland liegt dabei seit Jahren deutlich über dem globalen Durchschnitt, weil die großen Zugangsnetze (Festnetz wie Mobilfunk) längst Dual Stack oder DS-Lite ausgerollt haben. Wer eine kundenzugewandte Anwendung betreibt, bedient sein Publikum heute überwiegend über IPv6, ob er es weiß oder nicht.

Zweitens die Kosten: Öffentliche IPv4-Adressen sind ein bewirtschaftetes Gut geworden. AWS berechnet seit Februar 2024 für jede öffentliche IPv4-Adresse 0,005 US-Dollar pro Stunde, rund 3,65 US-Dollar im Monat. Dies unabhängig davon, ob die Adresse an einer EC2-Instanz, einem Load Balancer oder einem NAT-Gateway hängt. Bei ein paar hundert Adressen über mehrere Accounts summiert sich das zu einem fünfstelligen Jahresbetrag, der in keiner Migrations-Kalkulation stand. Auf dem Transfermarkt kosten kleine Blöcke (/24 bis /22) 2026 je nach Region und Registrierungshistorie grob 20 bis 40 US-Dollar pro Adresse. Das Leasing eines /24 beginnt bei etwa 100 Euro monatlich. IPv6-Präfixe gibt es bei den RIRs dagegen praktisch zum Mitgliedsbeitrag.

Der eigentliche Engpass liegt jedoch nicht bei den öffentlichen Adressen. Er liegt im privaten Adressraum und dort trifft er die Cloud-Transformation mit voller Wucht.

Warum der private IPv4-Adressraum zuerst ausgeht

RFC 1918 stellt rund 17,9 Millionen private Adressen bereit: 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16. Das klingt nach viel, ist in einem Konzern mit Historie aber schneller aufgebraucht, als man denkt. Drei Mechanismen sorgen dafür.

Zuteilung nach Gießkanne

In den 2000er-Jahren wurden Standorten großzügig /16-Netze zugewiesen, aus denen heute vielleicht zehn Prozent genutzt werden. Zurückgeholt wird selten, weil niemand die Abhängigkeiten kennt. Auf dem Papier ist das 10er-Netz voll, real ist es leer – aber für neue Cloud-Landing-Zones steht es trotzdem nicht zur Verfügung.

Überlappung durch Zukäufe und Partner

Jede Übernahme bringt ein eigenes 10.0.0.0/8 mit, jeder Dienstleister-Anschluss ein weiteres 192.168er-Netz. Die Standardantwort ist doppeltes NAT an den Koppelpunkten. Das funktioniert, bis Anwendungen ins Spiel kommen, die Adressen im Payload transportieren, Zertifikate auf IPs ausstellen oder (typisch in der OT) fest projektierte Adressen in SPS-Programmen und Leitsystemen tragen. Spätestens beim Versuch, solche Inseln an eine gemeinsame Cloud-Plattform anzubinden, wird aus der Adressfrage ein Projektstopper.

Cloud und Container als Adressfresser

Cloud-Architekturen konsumieren privaten Adressraum in einer Größenordnung, die On-Premises-Planer unterschätzen. Jede Landing Zone braucht nicht überlappende VPC- beziehungsweise VNet-Bereiche, jede Region, jede Stage multipliziert den Bedarf. Kubernetes verschärft das Problem: Pod- und Service-CIDRs belegen pro Cluster schnell ein /16, und wer Pods direkt routbar macht (etwa mit dem VPC-CNI unter EKS), zieht diesen Bedarf in den zentralen Adressplan hinein. Viele Organisationen weichen bereits auf den Carrier-Grade-NAT-Bereich 100.64.0.0/10 aus, der eigentlich für Provider-NAT reserviert ist und kollidiert, sobald ein Carrier oder ein SD-WAN-Anbieter denselben Bereich nutzt.

Das Ergebnis: Nicht der Mangel an öffentlichen Adressen bremst die Transformation, sondern die Unmöglichkeit, konfliktfreie private Netze für neue Plattformen zu schneiden. IPv6 löst genau dieses Problem: ein einziges /48 pro Standort bietet 65.536 Subnetze, Überlappungen sind bei sauberer Präfixplanung ausgeschlossen, NAT entfällt als Strukturelement.

Die Migrationsmodelle im Vergleich

Für den Weg dorthin gibt es drei Grundmuster, die sich in Aufwand und Zielbild deutlich unterscheiden.

Dual Stack: der teure Standardweg

Beide Protokolle parallel auf jedem Segment. Das ist der kompatibelste Ansatz und für Internet-Facing-Dienste der richtige Einstieg, hat aber einen strukturellen Haken: Er löst das Adressproblem nicht, denn der IPv4-Plan muss weiterhin vollständig gepflegt werden. Firewall-Regelwerke, Monitoring und Troubleshooting verdoppeln sich, und jedes Sicherheitskonzept muss beide Pfade abdecken. Eine IPv6-Lücke in einem nur auf IPv4 getesteten Regelwerk ist ein Klassiker in Penetrationstests. Dual Stack ist ein Übergangszustand, kein Ziel. Wer ihn ohne Abschaltdatum für IPv4 einführt, betreibt ihn erfahrungsgemäß ein Jahrzehnt. Allerdings gibt es auf der anderen Seite noch diverse Gerätehersteller im Bereich Netzwerk und Sicherheit, die ohne IPv4 auf der Management-Schnittstelle oder teilweise in anderen Bereichen einfach nicht funktionieren.

IPv6-only mit NAT64/DNS64: das Zielbild für neue Plattformen

Neue Umgebungen (Landing Zones, Container-Plattformen, Backend-Segmente) werden nur noch mit IPv6 adressiert. Den Übergang zur IPv4-Welt übernimmt ein zentraler NAT64-Dienst mit DNS64: Der Resolver synthetisiert für reine IPv4-Ziele AAAA-Einträge aus dem Well-Known-Präfix 64:ff9b::/96, das NAT64-Gateway übersetzt den Verkehr. Für Clients ohne saubere DNS-Nutzung (hartkodierte IPv4-Literale, ältere SDKs) ergänzt CLAT/464XLAT die Übersetzung auf dem Endgerät (im Mobilfunk seit Jahren Massenbetrieb). Die Hyperscaler unterstützen IPv6-only-Subnetze inzwischen produktiv, inklusive NAT64/DNS64 als Managed Service. Der Gewinn: ein einziger Adressplan, keine Überlappungen, und der IPv4-Bestand schrumpft auf wenige Übersetzungspunkte zusammen.

IPv6-mostly im Access: der pragmatische Mittelweg

In Campus- und Client-Netzen erlaubt die DHCP-Option 108 („IPv6-only preferred"), fähige Endgeräte ohne IPv4-Adresse zu betreiben, während Altgeräte weiter IPv4 beziehen. So lässt sich der IPv4-Verbrauch im Access drastisch senken, ohne einen Stichtag für jedes Gerät zu erzwingen. Für Unternehmensnetze mit heterogenem Gerätepark ist das derzeit der realistischste Weg, den Bestand abzuschmelzen.

RFC 8950 (IPv4 prefixes with IPv6 next-hops) ist super cool, wird aber nur von einer Handvoll Geräten und Betriebssystemen unterstützt. Daher vergleichen wir das hier noch nicht.

Die OT-Perspektive: wo IPv4 bleibt und warum das in Ordnung ist

In Produktionsnetzen gelten andere Gesetze. Feldbusse und Industrieprotokolle wie PROFINET arbeiten auf Ebene der Zelle teils ohne IP oder mit fest projektierten IPv4-Adressen. Gerätelebenszyklen von 15 bis 25 Jahren verbieten die Annahme, dass dort flächig IPv6 einzieht. Der Fehler wäre, daraus abzuleiten, dass IPv6 „für die OT irrelevant" sei. Richtig geschnitten ist es umgekehrt ein Entlastungswerkzeug: Die Zelle bleibt IPv4 und wird (ganz im Sinne von IEC 62443) als abgeschlossene Zone mit lokal eindeutigen, gern sogar standortweit identischen Adressen betrieben. Die Konnektivität nach oben, also Richtung Site-Aggregation, Datenplattform und Cloud, läuft über IPv6. Damit verschwindet das notorische Problem identischer Maschinennetze in Serienanlagen: Statt pro Linie ein NAT-Konstrukt zu pflegen, terminiert ein Edge-Gateway die Zelle und spricht nach oben mit einer eindeutigen IPv6-Adresse. Der Adresskonflikt, der bislang jede zentrale Datenanbindung verkompliziert hat, ist damit strukturell beseitigt ohne ein einziges Feldgerät anzufassen.

Was jetzt konkret zu tun ist

Aus Projekten lässt sich ein wiederkehrender Fahrplan ableiten, der die Migration vom Cloud-Programm entkoppelt, statt sie hineinzupressen:

1. Adressinventur vor Architektur. Ein belastbares IPAM aufbauen, reale Nutzung messen (nicht Zuteilungen zählen) und Überlappungen dokumentieren. Ohne dieses Bild ist jede Zieldiskussion Spekulation.
2. Globalen IPv6-Präfixplan festlegen. Provider-unabhängigen Adressraum (PI) beim RIR beantragen, ein hierarchisches Schema definieren (z. B. Region → Standort → Zone → Funktion) und Reserven großzügig einplanen. Der Plan ist ein Architekturdokument, kein Nebenprodukt. Umnummerieren ist bei IPv6 zwar einfacher, aber nicht kostenlos. Bevorzugter Merksatz: Bei Ipv6 immer in 4-bit-Schritten (binär) das nächste Netz bestimmen wegen der guten Lesbarkeit / Merkbarkeit.
3. Internet-Kante zuerst. Öffentliche Dienste, DNS, Mail und CDN-Anbindungen Dual Stack fähig machen. Das ist risikoarm, sofort messbar und beendet den Zustand, dass die Mehrheit der eigenen Kunden über Übersetzungsinfrastruktur Dritter zugreift.
4. Neue Cloud-Plattformen IPv6-only planen. Jede neue Landing Zone und jedes neue Cluster als IPv6-only mit NAT64/DNS64 auslegen und IPv4 nur noch als Ausnahme mit Begründung zulassen. So wächst das Problem nicht weiter, während der Bestand schrittweise folgt.
5. Sicherheitsbetrieb nachziehen. Firewall-Policies, IDS-Regeln, Logging und Geo-/Reputationslisten auf IPv6 erweitern, ICMPv6 korrekt behandeln (nicht pauschal blocken: Neighbor Discovery und PMTUD brauchen es) und First-Hop-Security wie RA-Guard im Access aktivieren. Ein IPv6, das „einfach so mitläuft", ist die größte reale Gefahr der Migration.
6. Skills und Betriebsprozesse aufbauen. Troubleshooting, Kapazitätsplanung und Change-Prozesse müssen IPv6 als Normalfall behandeln. Die Technik ist selten das Hindernis, das über zwei Jahrzehnte antrainierte IPv4-Denken in NAT-Kaskaden ist es.

Fazit

Die Cloud-Transformation scheitert nicht an fehlenden IPv4-Adressen im Internet, sondern an einem privaten Adressraum, der für die Plattform-Ära nie gedacht war. Dual NAT, CGN-Space und Adress-Broker kaufen Zeit, aber keine Struktur – und diese Zeit wird mit jeder Landing Zone, jedem Cluster und jedem Zukauf teurer. IPv6 ist dabei kein Modernisierungsprojekt neben der Cloud-Strategie, sondern deren Voraussetzung: ein konfliktfreier, planbarer Adressraum, auf dem sich Segmentierung, Zero Trust und zentrale Datenanbindung sauber aufbauen lassen. Wer den Präfixplan aufstellt, bevor die dritte Landing Zone kollidiert, führt die Migration als Architekturentscheidung durch. Alle anderen führen sie später trotzdem durch, nur unter Zeitdruck und zu schlechteren Konditionen.