NAT64 und DNS64: IPv6-Only-Netzwerke mit IPv4 verbinden

Die IPv6-Only-Zukunft#

Dual-Stack – gleichzeitiges Betreiben von IPv4 und IPv6 – ist der Standard-Migrationsansatz. Aber die Aufrechterhaltung von zwei parallelen Netzwerken für immer ist nicht das Ziel. Der Endpunkt ist eine IPv6-Only-Infrastruktur mit Legacy-IPv4-Zugriff nur bei Bedarf.

Dieser Übergang findet bereits in Mobilfunknetzen statt. Große Mobilfunkbetreiber betreiben IPv6-Only-Stacks auf Smartphones. T-Mobile, AT&T und Verizon haben IPv4 vor Jahren aus ihren LTE/5G-Netzwerken entfernt. Ihr Telefon hat eine IPv6-Adresse. Wenn Sie auf eine IPv4-only-Website zugreifen, übernehmen NAT64 und DNS64 die Übersetzung transparent.

Unternehmensnetzwerke folgen demselben Pfad. IPv6-Only reduziert Komplexität, eliminiert Bedenken hinsichtlich IPv4-Adresserschöpfung und vereinfacht das Routing. Aber eine vollständige IPv4-Eliminierung ist noch nicht realistisch – zu viele Dienste bleiben IPv4-Only. NAT64 und DNS64 überbrücken diese Lücke und ermöglichen IPv6-Only-Netzwerken den Zugriff auf das IPv4-Internet.

Wie NAT64 und DNS64 zusammenarbeiten#

NAT64 führt Protokollübersetzung auf der Netzwerkschicht durch. DNS64 synthetisiert IPv6-Adressen, die diese Übersetzung auslösen. Sie arbeiten als Paar – DNS64 ohne NAT64 ist nutzlos, und NAT64 ohne DNS64 erfordert manuelle Konfiguration.

Der Übersetzungsablauf#

Folgendes geschieht, wenn ein IPv6-Only-Client auf einen IPv4-Only-Dienst zugreift:

┌─────────────────────────────────────────────────────────────────┐
│ 1. Client fragt DNS nach www.ipv4only.example.com ab           │
│    Abfragetyp: AAAA (IPv6-Adresse)                             │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 2. DNS64-Server fragt Upstream-DNS ab                          │
│    Erhält: A-Record → 198.51.100.10 (nur IPv4)                 │
│    Kein AAAA-Record existiert                                  │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 3. DNS64 synthetisiert AAAA-Record                             │
│    Kombiniert NAT64-Präfix + IPv4-Adresse                      │
│    Ergebnis: 64:ff9b::198.51.100.10                            │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 4. Client erhält synthetisierte IPv6-Adresse                   │
│    Sendet Pakete an 64:ff9b::198.51.100.10                     │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 5. NAT64-Gateway fängt Pakete ab                                │
│    Erkennt 64:ff9b::/96-Präfix                                 │
│    Extrahiert eingebettetes IPv4: 198.51.100.10                │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 6. NAT64 übersetzt IPv6 → IPv4                                  │
│    Ändert Paket-Header                                         │
│    Führt zustandsbehaftetes NAT durch (verfolgt Sitzung)       │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 7. IPv4-Paket an Ziel gesendet                                  │
│    Quelle: NAT64-Gateway IPv4-Adresse                          │
│    Ziel: 198.51.100.10                                         │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 8. Rückverkehr zurück übersetzt                                │
│    NAT64 schlägt Sitzung nach                                  │
│    Übersetzt IPv4 → IPv6                                       │
│    Leitet an Client weiter                                     │
└─────────────────────────────────────────────────────────────────┘

Der Client sieht nur IPv6. Der IPv4-Only-Dienst sieht nur IPv4. NAT64 und DNS64 übernehmen die Übersetzung unsichtbar.

Das Well-Known-Präfix#

Das Standard-NAT64-Präfix ist 64:ff9b::/96 (RFC 6052). Dieses bekannte Präfix teilt allen mit „IPv4-Adressen sind hier eingebettet".

Die Einbettung von IPv4-Adressen funktioniert so:

IPv4-Adresse:    198.51.100.10
In Hex:          C6.33.64.0A
NAT64-Präfix:    64:ff9b::
Kombiniert:      64:ff9b::c633:640a
Erweitert:       64:ff9b::198.51.100.10 (übliche Notation)

Die letzten 32 Bits der IPv6-Adresse enthalten die IPv4-Adresse. Anwendungen sehen dies nie – es ist rein intern für die Übersetzungsinfrastruktur.

Sie können benutzerdefinierte Präfixe anstelle des Well-Known-Präfixes verwenden. Übliche Wahlmöglichkeiten sind organisationsspezifische Präfixe wie 2001:db8:64::/96. Dies ermöglicht Traffic Engineering (NAT64-Verkehr anders routen), erfordert aber Änderungen der DNS64-Konfiguration.

DNS64 Deep Dive#

DNS64 ist ein DNS-Server mit spezieller Übersetzungslogik. Er fängt AAAA-Abfragen ab und synthetisiert Antworten, wenn nur A-Records existieren.

DNS64-Logikablauf#

AAAA-Abfrage für example.com
    ↓
Upstream nach AAAA abfragen
    ↓
AAAA-Record existiert? ─ JA ─→ AAAA-Record zurückgeben (natives IPv6)
    │
    NEIN
    ↓
Upstream nach A abfragen
    ↓
A-Record existiert? ─ NEIN ─→ NXDOMAIN zurückgeben
    │
    JA
    ↓
AAAA synthetisieren = Präfix + IPv4
    ↓
Synthetisiertes AAAA zurückgeben

Wichtige Verhaltensweisen:

• Natives IPv6 bevorzugt: Wenn AAAA existiert, gibt DNS64 es unverändert zurück. Keine Synthese. NAT64 nicht beteiligt.
• IPv4-Fallback nur: Synthese erfolgt nur, wenn AAAA nicht existiert
• Cache-TTL-Erhaltung: Synthetisierte Records erben TTL vom A-Record
• DNSSEC-Komplexität: Synthese bricht DNSSEC-Validierung (später mehr dazu)

DNS64-Konfigurationsbeispiele#

BIND 9:

options {
    // ... andere Optionen ...
    dns64 64:ff9b::/96 {
        clients { any; };
        mapped { !192.168.0.0/16; !10.0.0.0/8; any; };
        exclude { 64:ff9b::/96; ::ffff:0:0/96; };
        suffix ::;
    };
};

Parameter:

• clients: Welche Clients DNS64 erhalten (normalerweise any)
• mapped: Welche IPv4-Adressen übersetzt werden (RFC 1918 private Adressen ausschließen)
• exclude: Welche IPv6-Bereiche niemals synthetisiert werden
• suffix: Passt an, wo IPv4 in Adresse eingebettet wird (erweitert)

Unbound:

server:
    module-config: "dns64 validator iterator"
 
dns64:
    dns64-prefix: 64:ff9b::/96
    dns64-synthall: no

• dns64-synthall: Ob auch synthetisiert werden soll, wenn AAAA existiert (normalerweise nein)

PowerDNS Recursor:

# In recursor.conf
enable-dns64: yes
dns64-prefix: 64:ff9b::/96

DNS64-Entdeckung#

Clients müssen wissen, welcher DNS-Server DNS64 bereitstellt. Normalerweise konfiguriert über:

Router-Advertisements (SLAAC):

# radvd.conf
interface eth0 {
    RDNSS 2001:db8::53 {
        AdvRDNSSLifetime 300;
    };
};

DHCPv6:

option dhcp6.name-servers 2001:db8::53;

Moderne Betriebssysteme akzeptieren DNS-Server sowohl von RA als auch von DHCPv6.

NAT64 Deep Dive#

NAT64 ist zustandsbehaftete Übersetzung – es pflegt Sitzungsstatus wie traditionelles NAT44. Jede Client-Verbindung erhält eine Zuordnung in der Statustabelle des NAT64-Gateways.

Zustandsbehaftete Übersetzung#

Das NAT64-Gateway verfolgt:

• IPv6-Quelladresse und Port
• IPv4-Zieladresse und Port
• Übersetzte IPv4-Quelladresse und Port
• Protokoll (TCP/UDP/ICMP)
• Sitzungs-Timer

Sitzungstabelleneintrag:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
IPv6 Client-Seite          │  IPv4 Server-Seite
━━━━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━━
2001:db8:100::45:1234      │  203.0.113.5:6789
  (Client IPv6:Port)       │    (NAT IPv4:Port)
                           │        ↕
                           │  198.51.100.10:80
                           │  (Ziel IPv4:Port)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Protokoll: TCP
Status: ESTABLISHED
Timeout: 7440 Sekunden

Wenn Rückverkehr bei 203.0.113.5:6789 ankommt, schlägt NAT64 die Sitzung nach und übersetzt zurück zu 2001:db8:100::45:1234.

Protokollübersetzung#

NAT64 übersetzt mehr als nur Adressen – es konvertiert zwischen IPv4- und IPv6-Paketformaten:

IPv6-Paket:

[ IPv6-Header | TCP/UDP/ICMP-Header | Nutzdaten ]

Übersetzt zu IPv4:

[ IPv4-Header | TCP/UDP/ICMP-Header | Nutzdaten ]

Übersetzung beinhaltet:

• TTL/Hop Limit: Dekrementiert und kopiert
• Fragmentierung: IPv6-Fragmentierung → IPv4-Fragmentierung (mit MTU-Überlegungen)
• ICMP: ICMPv6 → ICMPv4 (Nachrichtentypzuordnung)
• Prüfsummen: Neu berechnet für neue Protokollheader

Adressierungs-Pool#

NAT64 benötigt IPv4-Adressen für ausgehende Verbindungen. Kleine Bereitstellungen verwenden eine einzelne IPv4-Adresse mit Port-Overloading (wie Heimrouter). Größere Bereitstellungen verwenden Pools.

# Klein: Einzelne IPv4
NAT64-Pool: 203.0.113.5/32
Max Clients: ~65.000 gleichzeitige Sitzungen
 
# Groß: IPv4-Pool
NAT64-Pool: 203.0.113.0/24
Max Clients: ~16 Millionen gleichzeitige Sitzungen

Bedenken hinsichtlich Adresserschöpfung gelten – NAT64 hat dieselben Port-Einschränkungen wie NAT44.

Implementierungsoptionen#

Es existieren mehrere NAT64-Software-Implementierungen, von leichtgewichtig bis Carrier-Grade.

TAYGA: Leichtgewichtiger Userspace#

TAYGA ist ein einfacher Userspace-NAT64-Daemon für Linux. Gut für kleine Bereitstellungen und Tests.

Installation:

apt-get install tayga
 
# TUN-Schnittstelle erstellen
ip tuntap add name nat64 mode tun
ip link set nat64 up
ip addr add 192.168.255.1/24 dev nat64
ip addr add 2001:db8:ffff::1/96 dev nat64

Konfiguration (/etc/tayga.conf):

tun-device nat64
ipv4-addr 192.168.255.1
ipv6-addr 2001:db8:ffff::1
prefix 64:ff9b::/96
dynamic-pool 192.168.255.0/24
data-dir /var/lib/tayga

Starten und routen:

systemctl start tayga
 
# NAT64-Präfix durch TAYGA routen
ip route add 64:ff9b::/96 dev nat64
ip route add 192.168.255.0/24 dev nat64
 
# Weiterleitung aktivieren
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv4.ip_forward=1

Vorteile: Einfach, leichtgewichtig, einfache Einrichtung Nachteile: Begrenzte Leistung (Userspace), kein Clustering, minimale Funktionen

Jool: Kernel-Modul#

Jool implementiert NAT64 als Linux-Kernel-Modul und bietet bessere Leistung.

Installation:

# Repository hinzufügen (Debian/Ubuntu)
apt-get install linux-headers-$(uname -r)
apt-get install jool-dkms jool-tools
 
# Modul laden
modprobe jool

Konfiguration:

# NAT64-Instanz erstellen
jool instance add "default" --netfilter --pool6 64:ff9b::/96
 
# IPv4-Adress-Pool hinzufügen
jool -i "default" pool4 add --tcp 203.0.113.5 1024-65535
jool -i "default" pool4 add --udp 203.0.113.5 1024-65535
jool -i "default" pool4 add --icmp 203.0.113.5 1024-65535
 
# Aktivieren
jool -i "default" global update enabled true

Routing:

ip route add 64:ff9b::/96 via 2001:db8::1

Vorteile: Hohe Leistung (Kernel-Space), aktive Entwicklung, gute Dokumentation Nachteile: Kernel-Modul-Komplexität, gelegentliche Kompatibilitätsprobleme mit Kernel-Updates

Cloud-Provider NAT64#

Große Cloud-Plattformen bieten verwaltetes NAT64:

AWS (NAT64 über Egress-Only-Internet-Gateway):

AWS bietet kein natives NAT64, aber Sie können Jool oder TAYGA auf EC2-Instanzen bereitstellen. Einige Drittanbieter-AMIs existieren.

Alternative: Verwenden Sie Dual-Stack mit IPv6-Only-internen Netzwerken und IPv4 für externen Zugriff.

Google Cloud Platform:

GCP bietet Cloud NAT mit NAT64-Unterstützung (Beta):

# NAT64-Subnetz erstellen
gcloud compute networks subnets create nat64-subnet \
  --network=my-network \
  --region=us-central1 \
  --range=10.0.0.0/24 \
  --enable-nat64
 
# Cloud NAT konfigurieren
gcloud compute routers nats create my-nat64 \
  --router=my-router \
  --region=us-central1 \
  --enable-nat64 \
  --nat64-prefix=64:ff9b::/96

Azure:

Azure unterstützt IPv6, bietet aber kein verwaltetes NAT64. Stellen Sie Ihr eigenes mit Linux-VMs mit Jool oder TAYGA bereit.

Vorteile (verwaltete Dienste): Keine Wartung, skalierbar, integrierte Überwachung Nachteile: Cloud-spezifisch, weniger Konfigurationsflexibilität, potenzielle Kosten

Carrier-Grade NAT64#

Telekommunikations- und große ISP-Bereitstellungen verwenden kommerzielle Lösungen:

• Cisco ASR mit CGv6
• Juniper MX Series mit NAT64-Service
• A10 Thunder CGN
• F5 BIG-IP mit CGNAT-Modul

Diese verarbeiten Millionen gleichzeitiger Sitzungen mit hoher Verfügbarkeit, Protokollierung für rechtliche Compliance und ausgefeilten Verkehrsrichtlinien.

464XLAT: IPv4-Only-Anwendungen ermöglichen#

NAT64/DNS64 funktioniert transparent für Dual-Stack-Anwendungen. Aber einige Apps hardcodieren IPv4-Adressen oder verwenden Protokolle, die DNS64 nicht abfangen kann. 464XLAT löst dies.

Wie 464XLAT funktioniert#

464XLAT fügt clientseitige Übersetzung (CLAT) vor NAT64 (PLAT) hinzu:

┌─────────────┐      ┌──────────────┐      ┌──────────────┐
│  IPv4-App   │      │              │      │              │
│             │      │ IPv6-Only-   │      │ IPv4-Server  │
│ 192.0.0.10  │      │ Netzwerk     │      │198.51.100.10 │
└──────┬──────┘      └──────────────┘      └──────────────┘
       │                                            │
   CLAT (lokal)                                PLAT (ISP)
   NAT46: IPv4→IPv6                           NAT64: IPv6→IPv4
       │                                            │
       └──────────── IPv6-Netzwerk ────────────────┘

Schritte:

1. App sendet IPv4-Paket an 192.0.0.10 (CLAT virtuelle Schnittstelle)
2. CLAT übersetzt IPv4 → IPv6 mit lokalem Präfix (z.B. 64:ff9b::c000:0a)
3. IPv6-Paket durchquert Netzwerk zu PLAT (NAT64-Gateway)
4. PLAT übersetzt IPv6 → IPv4
5. IPv4-Paket erreicht Ziel

Die App sieht lokale IPv4-Konnektivität. Das Netzwerk ist IPv6-Only. Übersetzung erfolgt an beiden Enden.

464XLAT auf Mobilgeräten#

Android und iOS implementieren CLAT automatisch, wenn mit IPv6-Only-Netzwerken mit NAT64 verbunden:

Android CLAT:

• Erkennt NAT64 durch Abfrage von ipv4only.arpa (gibt synthetisiertes AAAA zurück, wenn NAT64 existiert)
• Erstellt clat4-Schnittstelle mit 192.0.0.0/29-Adressen
• Routet IPv4-App-Verkehr durch CLAT
• Übersetzt zu IPv6 mit erkanntem NAT64-Präfix

iOS CLAT:

• Ähnlicher Erkennungsmechanismus
• Transparent für Apps und Benutzer

Deshalb funktionieren IPv4-Only-Apps in T-Mobile-, AT&T- und anderen IPv6-Only-Mobilfunknetzen.

Linux 464XLAT mit Clatd#

Für Linux-Systeme in IPv6-Only-Netzwerken:

# Installieren
apt-get install clatd
 
# /etc/clatd.conf konfigurieren
clat-v4-addr=192.0.0.1
clat-v6-addr=2001:db8:1234:5678::1
plat-prefix=64:ff9b::/96
 
# Starten
systemctl enable --now clatd
 
# Überprüfen
ip addr show clat
ping -4 8.8.8.8  # Sollte auch in IPv6-Only-Netzwerk funktionieren

Verwenden Sie 464XLAT, wenn:

• Sie IPv4-Only-Anwendungen haben, die nicht aktualisiert werden können
• Anwendungen DNS umgehen (hardcodierte IPs)
• Sie transparente IPv4-Unterstützung auf IPv6-Only-Infrastruktur benötigen

Bereitstellungsszenarien#

NAT64/DNS64 passt zu spezifischen Anwendungsfällen. Das Verständnis, wann es bereitgestellt werden sollte, vermeidet architektonische Fehler.

Szenario 1: Mobilfunknetze#

Situation: 5G/LTE-Betreiber mit Millionen von Teilnehmern, begrenzte IPv4-Adressen

Lösung: IPv6-Only-Netzwerk mit NAT64/DNS64 + 464XLAT

Vorteile:

• Eliminiert IPv4 aus Funknetzwerk und Core
• Vereinfachtes Routing (einzelnes Protokoll)
• Skaliert ohne IPv4-Adressbeschränkungen
• Unterstützt Legacy-Apps über 464XLAT

Implementierung:

• PLAT (NAT64) im Carrier-Core
• DNS64 auf Carrier-DNS-Servern
• CLAT auf Handsets (automatisch)

Dies ist die dominante Mobile-Architektur weltweit.

Szenario 2: Unternehmens-IPv6-Only-Netzwerke#

Situation: Neues Rechenzentrum, möchte IPv6-Only, um Dual-Stack-Komplexität zu vermeiden

Lösung: IPv6-Only-internes Netzwerk, NAT64 für Zugriff auf externe IPv4-Dienste

Vorteile:

• Vereinfachte Adressierung (kein IPv4-DHCP, NAT usw.)
• Moderne Architektur
• Zwingt Anwendungen, IPv6 zu unterstützen

Herausforderungen:

• Einige Unternehmensanwendungen bleiben IPv4-Only
• Verwaltungsschnittstellen oft IPv4-Only
• Legacy-Hardware-Kompatibilität

Empfehlung: Dual-Stack normalerweise einfacher für Unternehmen. IPv6-Only macht Sinn für Greenfield-, Cloud-native Umgebungen.

Szenario 3: Cloud-Native-Microservices#

Situation: Kubernetes-Cluster, Dienste kommunizieren intern über IPv6

Lösung: IPv6-Only-Cluster mit NAT64 für externe IPv4-API-Abhängigkeiten

Vorteile:

• Vereinfachtes Service-Mesh
• Keine IPv4-Adresserschöpfung in großen Clustern
• Natives IPv6 für Container-Networking

Implementierung:

• Kubernetes IPv6-Only-Modus
• NAT64-Gateway für Egress
• DNS64 über Cluster-DNS (CoreDNS unterstützt es)

# CoreDNS ConfigMap mit DNS64
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
        dns64 64:ff9b::/96
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

Wachsender Anwendungsfall, da IPv6 zum Standard in Container-Orchestrierung wird.

Einschränkungen und Fallstricke#

NAT64/DNS64 ist nicht perfekt. Das Verstehen von Einschränkungen verhindert Bereitstellungsfehler.

1. DNSSEC bricht#

DNS64 synthetisiert AAAA-Records, die nicht in der autoritativen Zone existieren. DNSSEC-Signaturen decken diese synthetischen Records nicht ab, sodass die Validierung fehlschlägt.

Lösungen:

• DNSSEC-Validierung auf DNS64-Resolver deaktivieren (nicht ideal)
• DNS64 verwenden, das RFC 6147 DNSSEC-Handling unterstützt (begrenzte Implementierung)
• Akzeptieren, dass DNSSEC-signierte IPv4-Only-Domains nicht validieren

Dies ist die größte betriebliche Herausforderung mit DNS64.

2. Hardcodierte IPv4-Adressen#

Anwendungen mit hardcodierten IPs umgehen DNS, sodass DNS64 die Abfrage nie sieht. NAT64 kann nicht helfen, weil es nur das NAT64-Präfix erkennt.

Lösungen:

• 464XLAT bereitstellen (verarbeitet allen IPv4-Verkehr)
• Anwendungen aktualisieren, um DNS-Namen zu verwenden
• Application-Layer-Gateways verwenden (selten, komplex)

3. IPv4-Literale in URLs#

Web-Apps, die http://192.0.2.1/api in URLs oder Konfiguration übergeben. Browser führen keine DNS-Lookups für IP-Literale durch, sodass DNS64 nicht synthetisiert.

Lösungen:

• Hostnamen statt IP-Literale verwenden
• Application-Layer-Proxys, die Literale umschreiben
• 464XLAT

4. FTP und andere ALGs#

Protokolle, die IP-Adressen in Anwendungsdaten einbetten (FTP Active Mode, SIP usw.), schlagen oft durch NAT64 fehl. Die Adresse in der Nutzlast stimmt nicht mit dem Paket-Header überein.

Lösung:

• FTP Passive Mode verwenden (keine eingebetteten Adressen)
• Protokoll-bewusstes NAT64 mit ALG-Unterstützung bereitstellen (komplex)
• Zu modernen Protokollen wechseln, die keine IPs einbetten

5. Fragmentierungsprobleme#

Path-MTU-Unterschiede zwischen IPv4 und IPv6 können Fragmentierungsprobleme verursachen. IPv6 hat eine minimale MTU von 1280 Bytes; IPv4 erlaubt 576 Bytes.

Lösung:

• Sicherstellen, dass MTU über Infrastruktur konsistent ist
• Path MTU Discovery (PMTUD) aktivieren
• ICMP Packet Too Big-Nachrichten überwachen und alarmieren

6. Reverse-DNS#

PTR-Records für NAT64-übersetzte Adressen werden nicht existieren. Anwendungen, die Reverse-DNS erfordern (einige Mailserver, Zugriffskontrollen), können fehlschlagen.

Lösung:

• PTR-Records für NAT64-Pool erstellen
• Dienste konfigurieren, kein Reverse-DNS zu erfordern
• IPv6 nativ verwenden, wo Reverse-DNS wichtig ist

Überwachung und Fehlerbehebung#

NAT64/DNS64 fügt Übersetzungsschichten hinzu, die Probleme verschleiern können. Ordnungsgemäße Überwachung ist essentiell.

DNS64-Verifizierung#

Testen Sie, ob DNS64 funktioniert:

# Abfrage für bekannte IPv4-Only-Domain
dig AAAA ipv4.google.com @2001:db8::53
 
# Sollte synthetisiertes AAAA mit NAT64-Präfix zurückgeben
# Beispiel: 64:ff9b::8.8.8.8

Wenn Sie keinen AAAA-Record erhalten, funktioniert DNS64 nicht.

NAT64-Konnektivitätstest#

Verwenden Sie die spezielle Test-Domain ipv4only.arpa:

# Von IPv6-Only-Client
ping6 ipv4only.arpa
 
# Sollte Antwort über NAT64 erhalten
# Die Domain löst zu 192.0.0.170 auf, synthetisiert zu 64:ff9b::192.0.0.170

Wenn Ping fehlschlägt, ist das NAT64-Gateway nicht erreichbar oder übersetzt nicht.

Sitzungstabellen-Inspektion#

Überprüfen Sie NAT64-Sitzungsstatus:

Jool:

jool -i "default" session display
 
# Zeigt aktive Sitzungen
# Suchen nach: Client IPv6, übersetztes IPv4, Ziel

TAYGA:

cat /var/lib/tayga/dynamic.map
 
# Zeigt Adresszuordnungen

Hohe Sitzungszahlen weisen auf starke Nutzung oder potenzielle Probleme hin (Verbindungslecks).

Verkehrsanalyse#

Erfassen Sie Verkehr vor und nach Übersetzung:

# IPv6-Verkehr zu NAT64-Präfix erfassen
tcpdump -i eth0 -n 'ip6 and dst net 64:ff9b::/96'
 
# Übersetzten IPv4-Verkehr erfassen
tcpdump -i eth1 -n 'ip and src 203.0.113.5'
 
# Vergleichen, um Übersetzung zu überprüfen

Suchen nach:

• Pakete, die bei NAT64 ankommen, aber nicht übersetzt werden
• Übersetzung erfolgt, aber Pakete werden nicht weitergeleitet
• Asymmetrisches Routing (Rückverkehr erreicht NAT64 nicht)

Häufige Probleme#

Symptom: DNS64 gibt synthetisiertes AAAA zurück, aber Verbindung schlägt fehl

Ursachen:

• NAT64-Gateway nicht erreichbar
• Firewall blockiert NAT64-Präfix
• Routing-Problem (Pakete zu NAT64-Präfix gehen falsche Richtung)

Debug:

traceroute6 64:ff9b::198.51.100.1
# Sollte zu NAT64-Gateway routen

Symptom: Einige Sites funktionieren, andere nicht

Ursachen:

• Sites mit nativem IPv6 funktionieren (NAT64 nicht beteiligt)
• IPv4-Only-Sites mit speziellen Anforderungen schlagen fehl
• Fragmentierung oder MTU-Probleme

Debug:

# Mit verschiedenen MTUs testen
ping6 -M do -s 1400 64:ff9b::198.51.100.1

Symptom: Verbindungen langsam oder Timeout

Ursachen:

• NAT64-Gateway überlastet
• Sitzungstabelle voll
• Asymmetrisches Routing

Debug:

# NAT64-CPU und Sitzungszahl prüfen
# Verbindungsaufbauzeit überwachen
time curl -6 http://ipv4-only-site.example.com

Sicherheitsüberlegungen#

NAT64 führt Sicherheitsimplikationen jenseits von typischem NAT ein.

Adressraum-Scanning#

Das NAT64-Präfix macht IPv4-Adressen in IPv6 vorhersehbar. Angreifer können 64:ff9b::/96 scannen, um zu entdecken, auf welche IPv4-Dienste Sie zugreifen.

Minderung: Verwenden Sie netzwerkspezifische NAT64-Präfixe statt Well-Known-Präfix, um Exposition zu begrenzen.

Umgehung von Zugriffskontrollen#

IPv4-Zugriffskontrollen (Firewall-Regeln, ACLs) berücksichtigen möglicherweise nicht NAT64-übersetzten Verkehr, der von unerwarteten IPv6-Quellen ankommt.

Minderung: Sicherheitsrichtlinien auf NAT64-Gateway anwenden, nicht nur auf Endpunkte.

NAT64 als Angriffsverstärker#

Angreifer in IPv6-Only-Netzwerken können NAT64 verwenden, um Angriffe gegen IPv4-Ziele zu starten, möglicherweise IPv4-basiertes Rate-Limiting oder Blacklists zu umgehen.

Minderung:

• NAT64-Sitzungen pro Quelle rate-limitieren
• Alle NAT64-Übersetzungen für Missbrauchsuntersuchung protokollieren
• Dieselben Sicherheitsrichtlinien wie IPv4-NAT anwenden

DNS64-Cache-Vergiftung#

Wenn der DNS64-Server kompromittiert ist, können Angreifer bösartige AAAA-Records synthetisieren, die auf vom Angreifer kontrollierte IPv4-Adressen über NAT64 zeigen.

Minderung:

• DNS64-Server sichern (wie jede DNS-Infrastruktur)
• DNSSEC wo möglich verwenden (trotz Kompatibilitätsproblemen)
• DNS64 auf ungewöhnliche Synthesemuster überwachen

Wann NAT64/DNS64 vs. Dual-Stack verwenden#

Entscheidungsrahmen:

┌─────────────────────────────────────────────────┐
│ Können Sie Dual-Stack betreiben?               │
└─────────────────────┬───────────────────────────┘
                      │
          ┌───────────┴──────────┐
          │                      │
         JA                    NEIN
          │                      │
          ▼                      ▼
   ┌─────────────┐     ┌─────────────────────┐
   │ Verwenden   │     │ Warum nicht?        │
   │ Sie         │     │                     │
   │ Dual-Stack  │     │ • IPv4-Erschöpfung  │
   │             │     │ • Architektonische  │
   │ (einfacher, │     │   Vereinfachung     │
   │  weniger    │     │ • Mobilfunknetz     │
   │  Probleme)  │     │ • Cloud-native      │
   └─────────────┘     └──────────┬──────────┘
                                  │
                                  ▼
                         ┌────────────────────┐
                         │ Verwenden Sie      │
                         │ NAT64/DNS64        │
                         │                    │
                         │ Fügen Sie 464XLAT  │
                         │ hinzu, wenn:       │
                         │ • IPv4-Only-Apps   │
                         │ • Hardcodierte IPs │
                         └────────────────────┘

NAT64/DNS64 macht Sinn, wenn:

• IPv4-Adresserschöpfung eine echte Einschränkung ist
• Sie neue Infrastruktur aufbauen (Greenfield)
• Mobilfunknetz oder Cloud-native Architektur
• Betriebliche Vorteile von Single-Stack die Übersetzungskomplexität überwiegen

Dual-Stack macht Sinn, wenn:

• IPv4-Adressen verfügbar sind
• Gemischte Legacy- und moderne Infrastruktur
• Kompatibilität höchste Priorität ist
• Team-Vertrautheit mit Dual-Stack

Die Zukunft von NAT64#

Die NAT64-Akzeptanz wächst, da IPv6-Only-Netzwerke häufiger werden:

Trends:

• Mobilfunkbetreiber fast universell bereitgestellt
• Cloud-Provider fügen verwaltete NAT64-Optionen hinzu
• IoT und Edge Computing verwenden IPv6-Only + NAT64
• Rechenzentren experimentieren mit IPv6-Only für Kosten/Einfachheit

Verbleibende Herausforderungen:

• DNSSEC-Kompatibilität noch nicht elegant gelöst
• Application-Layer-Protokollprobleme bestehen fort
• Betriebliche Expertise entwickelt sich noch

Langfristig: Wenn das IPv4-Internet schrumpft und IPv6 allgegenwärtig wird, könnte die NAT64-Nutzung abnehmen – die meisten Ziele haben natives IPv6 und erfordern keine Übersetzung. Aber das dauert noch Jahre. Momentan ist NAT64/DNS64 die Schlüsseltechnologie, die IPv6-Only-Netzwerke ermöglicht.

Klein anfangen und testen#

Stellen Sie NAT64/DNS64 nicht in Produktion ohne gründliche Tests bereit:

1. Laborumgebung: TAYGA oder Jool in Testnetzwerk einrichten
2. DNS64 konfigurieren: BIND oder Unbound verwenden
3. Anwendungen testen: Überprüfen Sie, dass Ihre spezifischen Apps durch Übersetzung funktionieren
4. Leistung überwachen: Latenz- und Durchsatz-Overhead messen
5. Probleme dokumentieren: Notieren Sie, welche Apps oder Dienste Probleme haben
6. Workarounds planen: Dual-Stack für problematische Dienste, 464XLAT für andere

Erst nach erfolgreichen Tests sollten Sie Produktionsbereitstellung erwägen, und selbst dann, beginnen Sie mit nicht-kritischen Netzwerken oder Benutzersegmenten.

NAT64/DNS64 ist leistungsstark, fügt aber Komplexität hinzu. Verwenden Sie es, wo es echte Probleme löst, nicht weil es neuartige Technologie ist.

Verwandte Artikel#

• IPv6-Migrationsstrategien - Auswahl des richtigen Migrationsansatzes
• Dual-Stack-IPv6-Bereitstellung - IPv4 und IPv6 zusammen betreiben
• IPv6-DNS-Konfiguration - DNS für IPv6 einrichten

Häufig gestellte Fragen#