NAT64 und DNS64 sind Übergangstechniken, mit denen IPv6-only Clients IPv4-only Services erreichen können. NAT64 übernimmt die eigentliche Protokoll- und Adressübersetzung zwischen IPv6 und IPv4, während DNS64 dafür sorgt, dass IPv6-only Clients für IPv4-Hosts eine „synthetische“ AAAA-Antwort erhalten. In der Praxis ist das ein sehr bewährtes Muster für IPv6-only WLANs, neue Campus-Segmente oder Container/Cloud-Umgebungen, in denen du IPv6 sauber ausrollen willst, aber noch IPv4-Ziele im Internet oder im Rechenzentrum existieren.
Grundidee: DNS64 liefert die „IPv6-Adresse“, NAT64 übersetzt den Traffic
IPv6-only Clients können keine A-Records direkt nutzen. DNS64 nimmt deshalb einen IPv4 A-Record und erzeugt daraus eine AAAA-Adresse, indem er das IPv4-Ziel in ein NAT64-Präfix einbettet. NAT64 erkennt dieses Präfix, extrahiert die IPv4-Adresse und übersetzt die Verbindung stateful in Richtung IPv4.
Adressbildung mit NAT64-Präfix
- DNS64: erzeugt synthetische AAAA-Records
- NAT64: übersetzt IPv6→IPv4 (und Rückrichtung stateful)
- Wichtig: Für DNS-Traffic brauchst du eine funktionierende DNS64-Instanz (separat vom Router)
Wichtige Begriffe: WKP, Stateful Prefix, Pool und State
NAT64 kann ein eigenes Prefix nutzen oder das Well-Known Prefix (WKP) 64:ff9b::/96. Stateful NAT64 benötigt außerdem einen IPv4-Pool (oder ein Interface) für die Übersetzungsadresse(n). Da IPv6 deutlich größer ist als IPv4, entsteht ein Zustand (State), der IPv6-Quelle/Port auf IPv4-Quelle/Port abbildet.
- WKP:
64:ff9b::/96(häufiger Standard für DNS64/NAT64) - Stateful Prefix: Präfix, an dem NAT64 „NAT64-Ziele“ erkennt
- IPv4 Pool: öffentliche/geroutete IPv4-Adressen für Übersetzung (PAT möglich)
- State: Rücktraffic aus IPv4 ist nur möglich, wenn vorher ein State aus IPv6→IPv4 aufgebaut wurde
Topologie-Pattern: IPv6-only LAN, IPv4 WAN, NAT64 am Border
Das typische Design ist ein Border Router (BR) mit IPv6 auf der LAN-Seite und IPv4 auf der WAN/Server-Seite. Der BR muss das NAT64-Prefix ins IPv6-Netz „sichtbar“ machen, damit Clients die synthetischen AAAA-Ziele überhaupt routen können.
- LAN: IPv6-only Clients (z. B. 2001:db8:10::/64)
- WAN/Server: IPv4-only Ziele (z. B. 198.51.100.0/24)
- DNS: DNS64 Resolver (liefert synthetische AAAA-Records)
Designentscheidung: Wo läuft DNS64?
DNS64 ist typischerweise ein DNS-Resolver (z. B. BIND/Unbound) und nicht „einfach NAT am Router“. Der Resolver muss das gleiche NAT64-Präfix verwenden, das am NAT64-Router konfiguriert ist. Clients müssen diesen DNS64-Resolver nutzen (DHCPv6 oder RDNSS).
- DNS64 Präfix muss identisch zum NAT64-Präfix sein
- Clients müssen den DNS64 Resolver als DNS-Server bekommen
- Split-DNS möglich: intern andere Zonen, extern DNS64
Schritt-für-Schritt: Stateful NAT64 auf IOS XE (Beispielkonfiguration)
Das folgende Beispiel zeigt ein praxistaugliches Grundsetup. Passe Interfaces, Prefixe und IPv4-Pool an deine Umgebung an. Das Ziel ist: IPv6-only Clients dürfen NAT64-States erzeugen, und der Router übersetzt über einen IPv4-Pool per PAT.
1) IPv6 Routing aktivieren und Interfaces konfigurieren
ipv6 unicast-routing
interface GigabitEthernet0/1
description LAN IPv6-only
ipv6 address 2001:db8:10::1/64
no shutdown
interface GigabitEthernet0/0
description WAN/IPv4-to-Servers
ip address 198.51.100.2 255.255.255.0
no shutdown
2) NAT64 Prefix festlegen (WKP oder eigenes Prefix)
nat64 prefix stateful 64:ff9b::/963) IPv4 Pool definieren (für stateful NAT64/PAT)
nat64 v4 pool NAT64-POOL 198.51.100.64 198.51.100.954) IPv6 ACL als „Wer darf State erzeugen?“
Stateful NAT64 sollte nicht „alles“ aus dem IPv6-Netz übersetzen, ohne Kontrolle. Die ACL ist ein einfaches Guardrail, um nur definierte Quellnetze zuzulassen.
ipv6 access-list NAT64-V6-ALLOWED
permit ipv6 2001:db8:10::/64 any
deny ipv6 any any5) NAT64 Mapping Rule (v6→v4) binden: ACL + Pool
nat64 v6v4 list NAT64-V6-ALLOWED pool NAT64-POOL overload6) NAT64 auf Interfaces aktivieren (Translation-Pfad definieren)
Je nach Plattform/Release wird NAT64 „interface-basiert“ aktiviert. Das Muster bleibt: LAN-Seite und WAN-Seite für NAT64 aktivieren, damit Pakete in den NAT64-Forwarding-Pfad gelangen.
interface GigabitEthernet0/1
nat64 enable
interface GigabitEthernet0/0
nat64 enable
7) Routing: NAT64 Prefix ins IPv6-LAN bringen und IPv4 Default setzen
IPv6-only Clients müssen das NAT64-Prefix erreichen können. Häufig wird es per statischer Route oder per IGP angekündigt. Auf der IPv4-Seite brauchst du einen Default/Return ins IPv4-Netz.
! IPv6: Route zum NAT64 Prefix auf den NAT64 Router (wenn nicht lokal)
! In vielen Designs genügt die lokale Konfiguration am BR; alternativ im IGP announcen.
! IPv4: Default ins WAN/Upstream
ip route 0.0.0.0 0.0.0.0 198.51.100.1
DNS64 Integration: Client-Auflösung korrekt machen
Damit IPv6-only Clients IPv4-Ziele finden, muss DNS64 aktiv sein und synthetische AAAA-Records liefern. Der DNS64-Resolver muss das NAT64-Präfix nutzen, das du am Router gesetzt hast (z. B. 64:ff9b::/96).
- Clients erhalten DNS64 Resolver per DHCPv6/RDNSS
- DNS64 synthesisiert AAAA aus A (nur wenn AAAA fehlt)
- IPv4-lokale Ausnahmen (z. B. interne Legacy-Apps) ggf. über Split-DNS
DHCPv6 Beispiel: DNS64 Resolver verteilen
ipv6 dhcp pool LAN-V6
dns-server 2001:db8:53::64
domain-name example.local
interface GigabitEthernet0/1
ipv6 dhcp server LAN-V6
Typische Stolperfallen bei NAT64/DNS64
Die häufigsten Fehler sind nicht „NAT64 kaputt“, sondern Inkonsistenzen im Präfix, falsches DNS oder fehlende Return-Routen. Diese Punkte solltest du als feste Checkliste führen.
- DNS64 nutzt anderes Präfix als NAT64 → synthetische Ziele werden nicht übersetzt
- IPv6 Routing zum NAT64 Prefix fehlt → Clients erreichen die synthetischen AAAA nicht
- IPv4 Return fehlt (Default/Route) → Sessions brechen in Rückrichtung
- ACL zu restriktiv → keine States werden aufgebaut
- Applikationen mit eingebetteten IPv4-Adressen (ALGs nötig) → Sonderfälle prüfen
Troubleshooting: State, Prefix und Übersetzungen sichtbar machen
Beim Debugging willst du schnell beweisen: (1) kommt IPv6-Traffic am Router an, (2) wird ein NAT64-State erzeugt, (3) geht IPv4-Traffic raus, (4) kommt Rücktraffic zurück und matcht den State.
State/Statistiken prüfen
show nat64 statistics
show nat64 prefix stateful
show nat64 translationsRouting und Pfad prüfen
show ipv6 route 64:ff9b::/96
show ip route 0.0.0.0
show interfaces | include drops|errorPraxis-Test: DNS64 und Connectivity getrennt prüfen
! 1) DNS64 Test: liefert AAAA für IPv4-only Host?
! (auf einem Client: nslookup/dig; hier nur Konzept)
! 2) Connectivity Test: Ping/Trace auf synthetische AAAA (Client-Seite)
! Wenn das geht, aber TCP nicht: MTU/MSS/ALG prüfen
Betriebs- und Security-Best-Practices
NAT64 ist ein kritischer Übergangspunkt. Saubere Policies und Observability verhindern, dass der NAT64-Router zum Single Point of Failure oder zur „Blackbox“ wird.
- ACL/Prefix-Scopes: nur definierte IPv6-Quellen dürfen NAT64 nutzen
- Monitoring: aktive Translations, Drops, CPU/Memory, Interface Errors
- MTU/MSS: bei Problemen mit Web/Apps MSS-Clamping prüfen
- Dokumentation: NAT64 Prefix, DNS64 Resolver, Ausnahmen (Split-DNS)
Konfiguration speichern
Router# copy running-config startup-config::contentReference[oaicite:0]{index=0}
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)
Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.
Was ich (je nach Paket) umsetze
-
Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)
-
Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)
-
Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation
-
Optional Security: Basic ACLs und SSH-Hardening
-
Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)
Sie erhalten
-
✅ Packet Tracer .pkt Datei
-
✅ Saubere Konfigurations-Notizen pro Gerät
-
✅ Verifikations-Checkliste + erwartete Outputs
-
✅ Kurze Dokumentation (wie die Topologie funktioniert)
Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.
Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.
