IPv6-Implementierung in der ITGix AWS Landing Zone

Da die Einführung von IPv6 weiter zunimmt, benötigen Unternehmen, die Workloads auf AWS ausführen, zunehmend Netzwerkarchitekturen, die sowohl IPv4- als auch IPv6-Datenverkehr unterstützen. AWS bietet zwar native IPv6-Funktionen, doch deren Integration in ein bestehendes Unternehmensnetzwerk erfordert eine sorgfältige Planung, um Sicherheit, Skalierbarkeit und betriebliche Konsistenz zu gewährleisten.

Vor kurzem bat uns einer unserer Kunden, die IPv6-Unterstützung für seine AWS-Umgebung zu aktivieren. Da die Infrastruktur bereits auf der ITGix AWS Landing Zone aufgebaut war, haben wir die bestehende Hub-and-Spoke-Netzwerkarchitektur erweitert, um Dual-Stack-Konnektivität (IPv4 und IPv6) zu unterstützen, ohne dabei die zentralisierten Designprinzipien zu verändern.

Vor der Einführung von IPv6 basierte die Umgebung auf einer zentralisierten Hub-and-Spoke-Architektur, die auf dem AWS Transit Gateway, einer gemeinsam genutzten AWS Network Firewall und einer dedizierten Egress-VPC aufbaute. Dieser Ansatz bietet mehrere Vorteile, darunter eine Kostenoptimierung durch den Einsatz einer einzigen Firewall und einer festen Anzahl von NAT-Gateways für den ausgehenden IPv4-Datenverkehr. Außerdem zentralisiert er die Netzwerkverwaltung in einem AWS-Konto für gemeinsam genutzte Dienste, ermöglicht die gemeinsame Nutzung von Ressourcen über den AWS Resource Access Manager (AWS RAM) und erlaubt die einheitliche Bereitstellung und Verwaltung des gesamten Netzwerkstacks mithilfe von Terraform.

Das folgende Diagramm veranschaulicht die ursprüngliche Hub-and-Spoke-Netzwerkarchitektur, bevor die IPv6-Unterstützung eingeführt wurde:

IPv6-Unterstützung hinzufügen

Die ITGix AWS Landing Zone unterstützt nun sowohl den reinen IPv4- als auch den Dual-Stack-Internetausgang (IPv4/IPv6), wobei die bestehende zentralisierte Hub-and-Spoke-Netzwerkarchitektur beibehalten wird.

Derzeit unterstützen wir keinen nativen IPv6-only-Internetausgang. Der Hauptgrund dafür ist, dass die AWS-Netzwerkdienste nicht darauf ausgelegt sind, eine zentralisierte IPv6-NAT-Übersetzung in derselben Weise bereitzustellen wie für IPv4. AWS NAT-Gateways unterstützen NAT64, wodurch IPv6-Clients mit IPv4-Diensten kommunizieren können, bieten jedoch keine native IPv6-zu-IPv6-Übersetzung. Ebenso ermöglichen „Egress-Only“-Internet-Gateways zwar ausgehende IPv6-Konnektivität, führen jedoch keine Netzwerkadressübersetzung (NAT) durch. Folglich würde die Aufrechterhaltung eines zentralisierten IPv6-Internetzugangs mit einer gemeinsam genutzten Netzwerk-Firewall maßgeschneiderte NAT-Appliances erfordern, was die betriebliche Komplexität erheblich erhöhen würde.

Stattdessen konzentriert sich unsere Implementierung auf das gängigste Bereitstellungsmodell in Unternehmen: die Unterstützung von nativem IPv4 sowie Dual-Stack-IPv4/IPv6-Konnektivität für Workloads und Internet-Ziele, die sowohl IPv4- als auch IPv6-Endpunkte veröffentlichen.

Warum IPv6 das Netzwerkmodell verändert

Im Gegensatz zu IPv4 wurde IPv6 mit einem praktisch unbegrenzten Adressraum konzipiert, wodurch NAT als Standard-Bereitstellungsmodell überflüssig wurde. Anstatt auf private Adressbereiche und Adressübersetzung zurückzugreifen, erhalten IPv6-Workloads in der Regel global routbare Adressen, wobei die Sicherheit durch zustandsorientierte Firewalls anstelle von NAT gewährleistet wird.

Dieser architektonische Unterschied wirkt sich unmittelbar auf zentralisierte Netzwerkkonzepte in AWS aus.

Wenn eine Workload einen nativen, ausschließlich IPv6-basierten Internet-Ausgang benötigt, kann das zentralisierte Hub-and-Spoke-Modell die Internetkonnektivität nicht mehr auf dieselbe Weise bereitstellen wie bei IPv4. Stattdessen muss jede Anwendungs-VPC ein eigenes „Egress-Only“-Internet-Gateway bereitstellen. Zwar fallen für diese Gateways keine zusätzlichen Kosten an, doch dieser Ansatz macht es unmöglich, den Internet-Ausgang über eine gemeinsame Netzwerk-Firewall zu zentralisieren. Um eine gleichwertige Datenverkehrsprüfung aufrechtzuerhalten, müsste daher in jeder VPC eine AWS Network Firewall bereitgestellt werden, was sowohl die Komplexität der Infrastruktur als auch die Betriebskosten erhöhen würde.

IPv6-Adressierung in AWS

Bei der Konzeption einer Dual-Stack-Umgebung sollten zudem einige AWS-spezifische Besonderheiten der IPv6-Adressierung berücksichtigt werden:

• Von AWS verwaltete Global Unicast-Adressen (GUA): Standardmäßig weist AWS IPv6-CIDR-Blöcke aus seinem eigenen Global Unicast-Adressen-Pool (GUA) zu. Anders als bei IPv4 können Kunden diese Präfixe nicht frei wählen, es sei denn, sie nutzen „Bring Your Own IP“ (BYOIP).
• Eindeutige lokale Adressen (ULA): AWS hat kürzlich die Unterstützung für private IPv6-Adressen vom Typ „Unique Local Address“ (ULA) über den AWS IP Address Manager (IPAM) eingeführt. ULAs sind für die interne Kommunikation und bestimmte Netzwerkszenarien vorgesehen. Sie sind kein Ersatz für das herkömmliche IPv4-Modell mit privaten Adressen und NAT, das für die Internetanbindung verwendet wird.

Was wir tatsächlich unterstützen:

Verkehrsfluss auf einen Blick

Das folgende Diagramm veranschaulicht, wie der ausgehende und eingehende Datenverkehr durch die Landing-Zone-Netzwerkarchitektur fließt. Der ausgehende Internetverkehr wird über das Transit-Gateway zur Inspection-VPC (Netzwerk-Firewall) geleitet, von dort zur Egress-VPC und schließlich nach außen – wobei NAT64 die IPv6→IPv4-Übersetzung übernimmt und nativer IPv6-Verkehr ins Internet bewusst verworfen wird. Der eingehende Datenverkehr gelangt über das eigene Internet-Gateway der Spoke-VPC zu einem Dual-Stack-ALB und wird auf dem Rückweg innerhalb der VPC weitergeleitet.

IPv6-Implementierung

Die zentralisierte Netzwerkimplementierung der AWS Landing Zone weist Netzwerkkomponenten und Routingtabellen automatisch CIDR-Blöcke für die Dual-Stack-Unterstützung (IPv4 + IPv6) zu. Außerdem übernimmt sie das für diese Dual-Stack-Konfiguration erforderliche Routing auf allen Ebenen: in den Spoke-VPCs, im Transit Gateway, in der Netzwerk-Firewall, in der Egress-VPC sowie auf dem gesamten Rückweg zu den Anwendungen.

VPCs

Jede VPC erhält einen IPv6-CIDR. Dieser wird von Amazon automatisch ausgewählt und bereitgestellt, sobald die IPv6-Unterstützung aktiviert ist – wir geben IPv6-CIDR-Blöcke nicht auf dieselbe Weise weiter wie bei IPv4; sie werden von AWS generiert.

Subnetze

Jedes Subnetz erhält zudem eine IPv6-CIDR-Adresse.

Subnetz-Routingtabellen

Die Subnetz-Routingtabellen enthalten Routen sowohl für IPv4 als auch für IPv6.

Netzwerk-Firewall

Die Firewall wird mit einer Dual-Stack -IP-Konfiguration bereitgestellt.

Die Variable HOME_NET wird zudem sowohl um das IPv4-Supernetz-CIDR (10.0.0.0/8, das alle VPCs abdeckt) als auch um die einzelnen IPv6-CIDRs erweitert. Die IPv6-CIDRs müssen einzeln aufgeführt werden, da AWS jeder VPC einen eigenen, nicht zusammenhängenden, global eindeutigen IPv6-Block zuweist, anstatt diese aus einem einzigen privaten Adressbereich abzuzweigen. Im Gegensatz zu IPv4 – wo 10.0.0.0/8 jede VPC abdeckt – gibt es also kein einziges IPv6-Supernetz, das alle VPCs abdeckt, ohne dabei auch Adressraum einzuschließen, der uns nicht gehört.

Um IPv6 zu unterstützen, benötigen wir außerdem entsprechende Firewall-Regeln für beide Adressfamilien. Beispielsweise muss der Datenverkehr zum AWS IMDS (Instance Metadata Service) sowohl für IPv4 als auch für IPv6 zugelassen werden:

# Allow access to IMDS for instance credentials #
pass tcp $HOME_NET any -> 169.254.169.254 80 (msg:"Allow IMDS (instance metadata)"; sid:10000; rev:1;)
# IPv6 IMDS endpoint (link-local, consistent across all VPCs)
pass tcp $HOME_NET any -> fd00:ec2::254 80 (msg:"Allow IMDS IPv6 (instance metadata)"; sid:10009; rev:1;)

Transit-Gateway-Routing

Leiten Sie den Datenverkehr von einer beliebigen VPC so weiter, dass er von der Netzwerk-Firewall geprüft wird (das Beispiel zeigt die dev-VPC → inspection-VPC; derselbe Ansatz gilt auch für Staging und Prod).

Leiten Sie den von der Netzwerk-Firewall geprüften Datenverkehr an die Egress-VPC weiter und die Antworten aus der Egress-VPC zurück an die Spoke-VPC, von der die Anfrage stammt – wobei sowohl reiner IPv4- als auch Dual-Stack-IPv4/IPv6-Datenverkehr verarbeitet wird.

Egress-VPC (Datenverkehr ins Internet) – Dual-Stack IPv4/IPv6

Die Routingtabelle in der Egress-VPC leitet den Datenverkehr ins Internet weiter und leitet die Antworten aus dem Internet zurück zum Transit-Gateway, wobei sowohl Fälle mit ausschließlich IPv4 als auch Dual-Stack-Fälle (IPv4/IPv6) berücksichtigt werden.

NAT64 und DNS64

Eine der wichtigsten Komponenten unserer Dual-Stack-Implementierung ist die Unterstützung von NAT64 und DNS64, wodurch Workloads, die in Dual-Stack-Subnetzen ausgeführt werden, mit reinen IPv4-Internetdiensten kommunizieren können.

Die Route 64:ff9b::/96 → NAT-Gateway (wie im vorherigen Diagramm dargestellt) dient genau diesem Zweck.

Da IPv4 und IPv6 unterschiedliche Protokollstacks verwenden, kann ein IPv6-Client nicht direkt mit einem reinen IPv4-Endpunkt kommunizieren. Obwohl die Verbreitung von IPv6 weiter zunimmt, sind viele öffentliche APIs, Software-Repositorys und Dienste von Drittanbietern nach wie vor nur über IPv4 verfügbar. AWS löst dieses Interoperabilitätsproblem durch die Kombination von DNS64, das vom Amazon VPC DNS Resolver bereitgestellt wird, mit NAT64, das vom AWS NAT Gateway implementiert wird.

So funktioniert DNS64

Wenn eine Anwendung eine DNS-Abfrage durchführt, folgt der Amazon VPC DNS Resolver einem von zwei Pfaden:

1. Wenn das Ziel einen AAAA-Eintrag veröffentlicht, gibt der Resolver die native IPv6-Adresse zurück.
2. Wenn nur ein A-Eintrag vorhanden ist, generiert der Resolver eine synthetische IPv6-Adresse, indem er die IPv4-Adresse in das bekannte Präfix 64:ff9b::/96 einbettet.

Beispielsweise wird eine IPv4-Adresse von 93.184.216.34 wie folgt übersetzt:

64:ff9b::5db8:d822

wobei 5db8 die hexadezimale Darstellung von 93.184.216.34 ist.

Aus Sicht der Anwendung kommuniziert diese mit einer Standard-IPv6-Adresse und ist sich überhaupt nicht bewusst, dass die Übersetzung später im Netzwerkstack stattfindet.

So funktioniert NAT64

Wenn der Datenverkehr das AWS NAT Gateway erreicht, führt NAT64 die Protokollübersetzung durch:

1. Das NAT-Gateway erkennt das Präfix 64:ff9b::/96.
2. Es extrahiert die eingebettete IPv4-Zieladresse.
3. Es führt Source-NAT unter Verwendung der öffentlichen IPv4-Adresse des NAT-Gateways durch.
4. Das Paket wird über das Internet-Gateway an das IPv4-Internet weitergeleitet.
5. Der Rückverkehr wird anhand des Verbindungsstatus verfolgt, wieder in IPv6 umgewandelt und an die ursprüngliche Workload weitergeleitet.

Dieser Vorgang ist für die Anwendung völlig transparent, sodass IPv6-fähige Workloads auf reine IPv4-Dienste zugreifen können, ohne dass Änderungen an der Anwendung erforderlich sind.

Routing-Verhalten

Unsere Implementierung schränkt den nativen IPv6-Internetzugang bewusst ein.

Die einzige konfigurierte IPv6-Ausgangsroute lautet:

64:ff9b::/96 → NAT Gateway (NAT64)

Es gibt nein ::/0 Route die auf ein „Egress-Only“-Internet-Gateway oder ein Internet-Gateway verweisen. Infolgedessen wird nativer IPv6-Internetverkehr am VPC-Router blockiert, während die IPv6-zu-IPv4-Kommunikation über DNS64 und NAT64 weiterhin funktioniert.

Testen der Ausgangsverbindungen im zentralisierten Netzwerk

Um die Implementierung zu überprüfen, haben wir eine Amazon EC2 -Instanz in einem Dual-Stack-Subnetz gestartet und die ausgehende Konnektivität mithilfe von AWS Systems Manager (SSM) überprüft.

Da das Subnetz für Dual-Stack-Netzwerke konfiguriert ist, erhält die Instanz bei Aktivierung der automatischen IPv6-Adresszuweisung sowohl eine IPv4- als auch eine IPv6-Adresse. AWS stellt innerhalb eines Dual-Stack-Subnetzes keine reinen IPv6-Instanzen bereit – für reine IPv6-Netzwerke ist ein reines IPv6-Subnetz erforderlich.

Eine Test-EC2-Instanz bereitstellen

Erstellen Sie eine Amazon EC2-Instanz in einem Dual-Stack-Subnetz und:

• Fügen Sie die von der Landing Zone vorgeschriebenen Ressourcen-Tags hinzu.
• Aktivieren Sie die AWS Systems Manager (SSM) -Verbindung für den Fernzugriff.
• Konfigurieren Sie die Instanz so, dass beim Start automatisch eine IPv6-Adresse zugewiesen wird.

DNS64-Konfiguration.

Stellen Sie sicher, dass die der Instanz zugewiesene Sicherheitsgruppe auch über eine IPv6-Ausgangsregel verfügt.

Stellen Sie sicher, dass die erstellte Instanz über eine IPv6-Adresse verfügt.

Rufen Sie die Instanz über SSM auf.

• Falls der SSM-Agent nicht verbunden ist, stellen Sie sicher, dass in der Sicherheitsgruppe (SG) ausgehende Regeln vorhanden sind, die zumindest Port 443 zulassen.
• Richten Sie einen VPC-Endpunkt für SSM und SSM-Nachrichten ein (stellen Sie sicher, dass dieser IPv6-Unterstützung bietet, damit wir auch diesen Teil testen können)

• Diese Endpunkte müssen im Shared-Services-Konto erstellt werden, da es nicht zulässig ist, VPC-Endpunkte in einer gemeinsam genutzten VPC anzulegen (daher können wir sie nicht direkt im Entwicklerkonto erstellen).

• Stellen Sie sicher, dass die Sicherheitsgruppe des VPC-Endpunkts eingehende Anfragen von der Dev-VPC sowohl über IPv4- als auch über IPv6-Adressen zulässt.

IPv6-Konnektivität testen

Überprüfen Sie, ob der DNS-Resolver Ziele, die nur über IPv4-Adressen verfügen, mithilfe von DNS64 in 64:ff9b:: umwandelt (checkip.amazonaws.com verfügt derzeit ausschließlich über eine IPv4-Adresse).

[root@ip-10-3-1-74 ~]# dig +short AAAA checkip.amazonaws.com
checkip.check-ip.aws.a2z.com.
64:ff9b::3ff:146d
64:ff9b::22f1:8ae0
64:ff9b::6c83:f08a
64:ff9b::6c84:4594
64:ff9b::3f21:dea9
64:ff9b::3411:3ca
64:ff9b::3431:50c4
64:ff9b::36ab:255b

Derselbe Test, jedoch auf einer Domain, die auch über eine IPv6-Adresse verfügt (wir können deren IPv6-Adresse erfolgreich abrufen, ohne dass DNS64 diese synthetisieren muss)

[root@ip-10-3-1-74 ~]# dig +short AAAA www.google.com
2001:4860:4826:7700::
2001:4860:482a:7700::
2001:4860:4827:7700::
2001:4860:4829:7700::
2001:4860:482c:7700::
2001:4860:482b:7700::
2001:4860:482d:7700::
2001:4860:4828:7700::

NAT64 – vollständiger IPv6->IPv4-Roundtrip über die Inspektions-VPC (und Firewall) + Egress-NAT

[root@ip-10-3-1-74 ~]# curl -6 -v --connect-timeout 8 https://checkip.amazonaws.com
* Host checkip.amazonaws.com:443 was resolved.
* IPv6: 64:ff9b::3411:3ca, 64:ff9b::3431:50c4, 64:ff9b::6c84:4594, 64:ff9b::3ff:146d, 64:ff9b::22f1:8ae0, 64:ff9b::36ab:255b, 64:ff9b::6c83:f08a, 64:ff9b::3f21:dea9
* IPv4: (none)
*   Trying [64:ff9b::3411:3ca]:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*   subject: CN=checkip.amazonaws.com
*   start date: Nov  3 00:00:00 2025 GMT
*   expire date: Dec  2 23:59:59 2026 GMT
*   issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   subjectAltName: "checkip.amazonaws.com" matches cert's "checkip.amazonaws.com"
* SSL certificate verified via OpenSSL.
* Established connection to checkip.amazonaws.com (64:ff9b::3411:3ca port 443) from 2a05:d014:ad1:7401:c49d:5ba9:619c:68f5 port 59300
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://checkip.amazonaws.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: checkip.amazonaws.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.17.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: checkip.amazonaws.com
> User-Agent: curl/8.17.0
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200
< date: Mon, 03 Aug 2026 13:14:44 GMT
< content-type: text/plain;charset=UTF-8
< content-length: 13
< server: nginx
< vary: Origin
< vary: Access-Control-Request-Method
< vary: Access-Control-Request-Headers
<
3.73.200.135
* Connection #0 to host checkip.amazonaws.com:443 left intact

Wir sehen, dass die Antwort „3.73.200.135“ zurückgegeben hat, was die IPv4-Adresse eines der NAT-Gateways ist. Dies belegt im Wesentlichen, dass, obwohl wir eine IPv6-Anfrage gesendet haben, der Empfänger unsere Anfrage über die IPv4-Adresse des NAT-Gateways erhalten und die Antwort anschließend über denselben Pfad zurückgesendet hat. NAT64 übernahm die Rückübersetzung von IPv4 nach IPv6 und zurück zu dem Rechner, von dem die Anfrage stammt.

Natives IPv6 ins Internet – der Datenverkehr wird verworfen (dies ist zu erwarten, da wir zwar „IPv4-only“ sowie Dual-Stack-IPv6/IPv4 unterstützen, jedoch keine reinen IPv6-Ziele)

[root@ip-10-3-1-74 ~]# curl -6 -v --connect-timeout 5 https://www.google.com
* Host www.google.com:443 was resolved.
* IPv6: 2001:4860:4828:7700::, 2001:4860:482d:7700::, 2001:4860:482b:7700::, 2001:4860:482c:7700::, 2001:4860:4829:7700::, 2001:4860:4827:7700::, 2001:4860:482a:7700::, 2001:4860:4826:7700::
* IPv4: (none)
*   Trying [2001:4860:4828:7700::]:443...
*   Trying [2001:4860:482d:7700::]:443...
*   Trying [2001:4860:482b:7700::]:443...
*   Trying [2001:4860:482c:7700::]:443...
*   Trying [2001:4860:4829:7700::]:443...
*   Trying [2001:4860:4827:7700::]:443...
*   Trying [2001:4860:482a:7700::]:443...
*   Trying [2001:4860:4826:7700::]:443...
* Connection timed out after 5001 milliseconds
* closing connection #0
curl: (28) Connection timed out after 5001 milliseconds

(Es kommt zu einem Timeout, da die EC2-Instanz über Router Advertisement weiterhin eine Standardroute ::/0 erhält; sie sendet daher eine TCP-SYN-Anfrage, die jedoch vom Dev-VPC-Router verworfen wird, da die Subnetz-Routingtabelle keine Route für ::/0 enthält.)

Ost-West-Verkehr (VPC-zu-VPC über Transit Gateway)

VPC to VPC traffic fully supports native IPv6. Unlike internet egress, there is no NAT64 or address translation involved – workloads talk to each other using their real IPv6 GUAs, and the Transit Gateway routes the traffic between VPCs using the per-VPC /56 routes present in the spoke route tables (<remote VPC /56> → TGW).

Dazu muss der Isolationsmodus deaktiviert werden, damit die VPCs über Routen zueinander verfügen. Standardmäßig ist der Datenverkehr zwischen VPCs auf der Ebene des Transit-Gateways deaktiviert, um eine Isolation zwischen Entwicklungs-, Staging- und Produktionsumgebungen zu gewährleisten, es sei denn, es ist ausdrücklich erforderlich, dass diese miteinander kommunizieren können. Der Isolationsmodus funktioniert so, dass der für andere VPCs bestimmte Datenverkehr verworfen wird.

Der Isolationsmodus kann mit dem Feature-Flag deaktiviert werden:

disable_environment_isolation = false  // set to true to disable isolation mode

Verbindung zwischen VPCs testen

Von einer EC2-Instanz in der Dev-VPC in einem privaten Subnetz aus soll ein Nginx-Testserver in der Staging-VPC erreicht werden – natives IPv6, kein NAT64.

[root@ip-10-3-1-74 ~]# curl -6 -v http://[2a05:d014:1a5b:c800:5b1e:2a7c:9f43:1d2e]/
* Trying [2a05:d014:1a5b:c800:5b1e:2a7c:9f43:1d2e]:80...
* Connected to 2a05:d014:1a5b:c800:5b1e:2a7c:9f43:1d2e (2a05:d014:1a5b:c800:5b1e:2a7c:9f43:1d2e) port 80
* using HTTP/1.x
> GET / HTTP/1.1
> Host: [2a05:d014:1a5b:c800:5b1e:2a7c:9f43:1d2e]
> User-Agent: curl/8.17.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: nginx/1.28.0
< Date: Wed, 05 Aug 2026 08:11:47 GMT
< Content-Type: text/plain
< Content-Length: 84
< Connection: keep-alive
<
Hello from staging-vpc (ip-10-4-1-88 / 2a05:d014:1a5b:c800:5b1e:2a7c:9f43:1d2e)
* Connection #0 to host 2a05:d014:1a5b:c800:5b1e:2a7c:9f43:1d2e left intact

Ingress-Konnektivität (Internet zu Workloads)

Im Gegensatz zur ausgehenden Internetverbindung unterstützt die eingehende Verbindung alle Bereitstellungsmodelle:

• Nur IPv4
• Dual-Stack (IPv4/IPv6)
• Nur IPv6

Die Unterstützung von IPv6-Eingangsverkehr erfordert nur minimale Änderungen an der Standardarchitektur der ITGix AWS Landing Zone. Der Datenfluss bleibt unverändert:

Internet-Gateway → Application Load Balancer (öffentliches Subnetz) → Workload (privates Subnetz)

Der Hauptgrund dafür ist, dass der Application Load Balancer (ALB) die Verbindung zum Client beendet und eine separate Verbindung zum Backend-Ziel herstellt. Dadurch sind die Verbindung zum Client und die Verbindung zur Workload voneinander unabhängig.

Das bedeutet, dass ein für Dual-Stack oder IPv6 konfigurierter ALB IPv6-Client-Verbindungen akzeptieren kann, selbst wenn die Backend-Workload selbst nur über eine IPv4-Adresse verfügt. Der ALB übernimmt die Protokollübersetzung transparent, sodass bestehende Anwendungen IPv6-Eingangsverkehr unterstützen können, ohne dass die Rechenressourcen über IPv6-Adressen verfügen müssen.

Auch der Antwortverkehr folgt dem Standard-VPC-Routingmodell. Da sich sowohl der ALB als auch die Workload innerhalb derselben VPC befinden, nutzt der Rückverkehr die lokale VPC-Route, anstatt die zentralisierte Netzwerkinfrastruktur zu durchlaufen. Folglich durchlaufen der eingehende Datenverkehr und die entsprechenden Antworten niemals den zentralisierten Ausgangspfad.

10.3.0.0/16 -> local
2a05:d014:ad1:7400::/56 -> local

ALBs müssen im Dual-Stack-Modus konfiguriert werden

Der ALB wird mit A- und AAAA-Einträgen unter seinem DNS-Namen angelegt.

IPv4 (A)

dig test123-612930072.eu-central-1.elb.amazonaws.com A

; <<>> DiG 9.20.26 <<>> test123-612930072.eu-central-1.elb.amazonaws.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50976
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;test123-612930072.eu-central-1.elb.amazonaws.com. IN A

;; ANSWER SECTION:
test123-612930072.eu-central-1.elb.amazonaws.com. 57 IN A 52.59.38.209

;; Query time: 7 msec
;; SERVER: 10.18.12.1#53(10.18.12.1) (UDP)
;; WHEN: Tue Aug 04 15:14:20 EEST 2026
;; MSG SIZE  rcvd: 93

IPv6 (AAAA)

dig test123-612930072.eu-central-1.elb.amazonaws.com AAAA

; <<>> DiG 9.20.26 <<>> test123-612930072.eu-central-1.elb.amazonaws.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60875
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;test123-612930072.eu-central-1.elb.amazonaws.com. IN AAAA

;; ANSWER SECTION:
test123-612930072.eu-central-1.elb.amazonaws.com. 60 IN AAAA 2a05:d014:ad1:7405:6957:a7d8:5190:f0be

;; Query time: 37 msec
;; SERVER: 10.18.12.1#53(10.18.12.1) (UDP)
;; WHEN: Tue Aug 04 15:15:17 EEST 2026
;; MSG SIZE  rcvd: 105

Die Sicherheitsgruppen des ALB müssen auch IPv6-Datenverkehr umfassen

Eingehend

Ausgehend

Die DNS-Einträge für unsere Anwendungen müssen sowohl IPv4-Einträge (A) als auch IPv6-Einträge (AAAA) enthalten.

IPv4

dig testipv6.dev.lz.itgix.eu A

; <<>> DiG 9.20.26 <<>> testipv6.dev.lz.itgix.eu A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57431
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;testipv6.dev.lz.itgix.eu.      IN      A

;; ANSWER SECTION:
testipv6.dev.lz.itgix.eu. 60    IN      A       52.59.38.209

;; Query time: 255 msec
;; SERVER: 10.18.12.1#53(10.18.12.1) (UDP)
;; WHEN: Tue Aug 04 15:15:40 EEST 2026
;; MSG SIZE  rcvd: 69

IPv6

dig testipv6.dev.lz.itgix.eu AAAA

; <<>> DiG 9.20.26 <<>> testipv6.dev.lz.itgix.eu AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55190
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;testipv6.dev.lz.itgix.eu. IN AAAA

;; ANSWER SECTION:
testipv6.dev.lz.itgix.eu. 60 IN AAAA 2a05:d014:ad1:7405:6957:a7d8:5190:f0be

;; Query time: 58 msec
;; SERVER: 10.18.12.1#53(10.18.12.1) (UDP)
;; WHEN: Tue Aug 04 15:15:43 EEST 2026
;; MSG SIZE rcvd: 81

Testen Sie die IPv6-Eingangsverbindungen aus dem Internet (mit „curl -6“ wird IPv6 erzwungen, sodass wir die AAAA-Einträge des ALB ansprechen (Dual-Stack-ALB in einem öffentlichen Subnetz))

$ curl -6 -v https://testipv6.dev.lz.itgix.eu/
*   Trying [2a05:d014:ad1:7405:6957:a7d8:5190:f0be]:443...
* Connected to testipv6.dev.lz.itgix.eu (2a05:d014:ad1:7405:6957:a7d8:5190:f0be) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=testipv6.dev.lz.itgix.eu
*  start date: Aug  1 00:00:00 2026 GMT
*  expire date: Aug 31 23:59:59 2027 GMT
*  subjectAltName: host "testipv6.dev.lz.itgix.eu" matched cert's "testipv6.dev.lz.itgix.eu"
*  issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M03
*  SSL certificate verify ok.
* Established connection to testipv6.dev.lz.itgix.eu (2a05:d014:ad1:7405:6957:a7d8:5190:f0be) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://testipv6.dev.lz.itgix.eu/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: testipv6.dev.lz.itgix.eu]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.17.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: testipv6.dev.lz.itgix.eu
> User-Agent: curl/8.17.0
> Accept: */*
>
* Request completely sent off
< HTTP/2 200
< date: Wed, 05 Aug 2026 08:18:03 GMT
< content-type: text/plain
< content-length: 64
< server: nginx/1.28.0
<
Hello over native IPv6 via dualstack ALB (backend ip-10-3-2-57)
* Connection #0 to host testipv6.dev.lz.itgix.eu left intact

Zusammenfassung

Die ITGix AWS Landing Zone bietet nun umfassende IPv6-Unterstützung und ermöglicht den IPv6-Eingangsverkehr aus dem Internet, die Ost-West-Kommunikation zwischen VPCs sowie den Dual-Stack-Ausgangsverkehr ins Internet, wobei die Vorteile unserer zentralisierten Hub-and-Spoke-Netzwerkarchitektur erhalten bleiben. Unternehmen können weiterhin eine gemeinsam genutzte AWS Network Firewall, ein zentralisiertes AWS Transit Gateway und einen gemeinsamen Satz von NAT-Gateways nutzen, ohne ihr bestehendes Netzwerkmodell neu gestalten zu müssen.

Die einzige Einschränkung betrifft den nativen IPv6-only-Internetausgang. AWS bietet derzeit keinen Mechanismus für ein zentralisiertes Source-NAT für nativen IPv6-Datenverkehr an, und der von Amazon zugewiesene IPv6-CIDR-Block für jede VPC bleibt an diese VPC gebunden. Daher ist ein zentralisierter nativer IPv6-Internetausgang derzeit ohne den Einsatz zusätzlicher Infrastruktur nicht praktikabel.

In der Praxis hat diese Einschränkung für die meisten Umgebungen kaum Auswirkungen. Workloads können weiterhin sowohl auf reine IPv4- als auch auf Dual-Stack-Internetdienste zugreifen – und zwar über ein zentralisiertes, von der Firewall geprüftes DNS64/NAT64. Für Workloads, die eine native IPv6-Internetverbindung benötigen, bleibt eine Bereitstellung pro VPC unter Verwendung eines „Egress-Only“-Internet-Gateways eine unterstützte Option.

Der vielleicht größte Vorteil besteht darin, dass die gesamte Lösung mithilfe von Terraform vollständig automatisiert ist. Dual-Stack-VPCs, die Zuweisung von IPv6-CIDR-Adressen, die Subnetzkonfiguration, das Routing über das AWS Transit Gateway, die Richtlinien der AWS Network Firewall sowie der DNS64/NAT64-Ausgangspfad werden allesamt als „Infrastructure as Code“ verwaltet. Die Aktivierung von IPv6 für eine neue AWS-Umgebung wird somit zu einer einfachen Konfigurationsänderung und muss nicht mehr als Neugestaltung des Netzwerks betrachtet werden.