NAT64 et DNS64 : connecter les réseaux IPv6 uniquement à IPv4

L'avenir IPv6 uniquement#

La double pile — exécuter IPv4 et IPv6 simultanément — est l'approche de migration standard. Mais maintenir deux réseaux parallèles pour toujours n'est pas l'objectif. Le point final est une infrastructure IPv6 uniquement avec accès à l'IPv4 hérité uniquement lorsque nécessaire.

Cette transition se produit déjà dans les réseaux mobiles. Les grands opérateurs exécutent des piles IPv6 uniquement sur smartphones. T-Mobile, AT&T et Verizon ont éliminé IPv4 de leurs réseaux LTE/5G il y a des années. Votre téléphone a une adresse IPv6. Lorsque vous accédez à un site web IPv4 uniquement, NAT64 et DNS64 gèrent la traduction de manière transparente.

Les réseaux d'entreprise suivent le même chemin. IPv6 uniquement réduit la complexité, élimine les préoccupations d'épuisement d'adresses IPv4 et simplifie le routage. Mais l'élimination complète d'IPv4 n'est pas encore réaliste — trop de services restent IPv4 uniquement. NAT64 et DNS64 comblent cette lacune, permettant aux réseaux IPv6 uniquement d'accéder à Internet IPv4.

Comment NAT64 et DNS64 fonctionnent ensemble#

NAT64 effectue la traduction de protocole au niveau de la couche réseau. DNS64 synthétise des adresses IPv6 qui déclenchent cette traduction. Ils fonctionnent en paire — DNS64 sans NAT64 est inutile, et NAT64 sans DNS64 nécessite une configuration manuelle.

Le flux de traduction#

Voici ce qui se passe lorsqu'un client IPv6 uniquement accède à un service IPv4 uniquement :

┌─────────────────────────────────────────────────────────────────┐
│ 1. Le client interroge le DNS pour www.ipv4only.example.com    │
│    Type de requête: AAAA (adresse IPv6)                        │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 2. Le serveur DNS64 interroge le DNS en amont                  │
│    Reçoit: Enregistrement A → 198.51.100.10 (IPv4 uniquement) │
│    Aucun enregistrement AAAA n'existe                          │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 3. DNS64 synthétise l'enregistrement AAAA                       │
│    Combine préfixe NAT64 + adresse IPv4                        │
│    Résultat: 64:ff9b::198.51.100.10                            │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 4. Le client reçoit l'adresse IPv6 synthétisée                 │
│    Envoie des paquets à 64:ff9b::198.51.100.10                │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 5. La passerelle NAT64 intercepte les paquets                  │
│    Reconnaît le préfixe 64:ff9b::/96                           │
│    Extrait l'IPv4 intégré: 198.51.100.10                       │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 6. NAT64 traduit IPv6 → IPv4                                    │
│    Modifie les en-têtes de paquet                              │
│    Effectue NAT avec état (suit la session)                    │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 7. Paquet IPv4 envoyé à la destination                         │
│    Source: Adresse IPv4 de la passerelle NAT64                 │
│    Destination: 198.51.100.10                                   │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 8. Trafic de retour traduit en retour                          │
│    NAT64 recherche la session                                   │
│    Traduit IPv4 → IPv6                                          │
│    Transmet au client                                           │
└─────────────────────────────────────────────────────────────────┘

Le client ne voit que IPv6. Le service IPv4 uniquement ne voit que IPv4. NAT64 et DNS64 gèrent la traduction de manière invisible.

Le préfixe bien connu#

Le préfixe NAT64 standard est 64:ff9b::/96 (RFC 6052). Ce préfixe bien connu indique à tous « les adresses IPv4 sont intégrées ici ».

L'intégration d'adresse IPv4 fonctionne ainsi :

Adresse IPv4:    198.51.100.10
En hexa:         C6.33.64.0A
Préfixe NAT64:   64:ff9b::
Combiné:         64:ff9b::c633:640a
Étendu:          64:ff9b::198.51.100.10 (notation courante)

Les 32 derniers bits de l'adresse IPv6 contiennent l'adresse IPv4. Les applications ne voient jamais cela — c'est purement interne à l'infrastructure de traduction.

Vous pouvez utiliser des préfixes personnalisés au lieu du préfixe bien connu. Les choix courants incluent des préfixes spécifiques à l'organisation comme 2001:db8:64::/96. Cela permet l'ingénierie du trafic (router le trafic NAT64 différemment) mais nécessite des changements de configuration DNS64.

Plongée profonde DNS64#

DNS64 est un serveur DNS avec une logique de traduction spéciale. Il intercepte les requêtes AAAA et synthétise des réponses lorsque seuls des enregistrements A existent.

Flux logique DNS64#

Requête AAAA pour example.com
    ↓
Interroger en amont pour AAAA
    ↓
Enregistrement AAAA existe? ─ OUI ─→ Retourner enregistrement AAAA (IPv6 natif)
    │
    NON
    ↓
Interroger en amont pour A
    ↓
Enregistrement A existe? ─ NON ─→ Retourner NXDOMAIN
    │
    OUI
    ↓
Synthétiser AAAA = préfixe + IPv4
    ↓
Retourner AAAA synthétisé

Comportements clés :

• IPv6 natif préféré : Si AAAA existe, DNS64 le retourne inchangé. Aucune synthèse. NAT64 non impliqué.
• Repli IPv4 uniquement : La synthèse se produit uniquement lorsque AAAA n'existe pas
• Préservation du TTL du cache : Les enregistrements synthétisés héritent du TTL de l'enregistrement A
• Complexité DNSSEC : La synthèse casse la validation DNSSEC (plus à ce sujet plus tard)

Exemples de configuration DNS64#

BIND 9 :

options {
    // ... other options ...
    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 ::;
    };
};

Paramètres :

• clients : Quels clients obtiennent DNS64 (généralement any)
• mapped : Quelles adresses IPv4 traduire (exclure adresses privées RFC 1918)
• exclude : Quelles plages IPv6 ne jamais synthétiser
• suffix : Personnalise où IPv4 s'intègre dans l'adresse (avancé)

Unbound :

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

• dns64-synthall : Synthétiser même lorsque AAAA existe (généralement non)

PowerDNS Recursor :

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

Découverte DNS64#

Les clients doivent savoir quel serveur DNS fournit DNS64. Généralement configuré via :

Annonces de routeur (SLAAC) :

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

DHCPv6 :

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

Les systèmes d'exploitation modernes acceptent les serveurs DNS à la fois depuis RA et DHCPv6.

Plongée profonde NAT64#

NAT64 est une traduction avec état — il maintient l'état de session comme le NAT44 traditionnel. Chaque connexion client obtient un mappage dans la table d'état de la passerelle NAT64.

Traduction avec état#

La passerelle NAT64 suit :

• Adresse et port source IPv6
• Adresse et port destination IPv4
• Adresse et port source IPv4 traduits
• Protocole (TCP/UDP/ICMP)
• Minuteurs de session

Entrée de table de session:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Côté client IPv6             │  Côté serveur IPv4
━━━━━━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━━
2001:db8:100::45:1234        │  203.0.113.5:6789
  (client IPv6:port)         │    (NAT IPv4:port)
                             │        ↕
                             │  198.51.100.10:80
                             │  (destination IPv4:port)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Protocole: TCP
État: ESTABLISHED
Délai d'expiration: 7440 secondes

Lorsque le trafic de retour arrive à 203.0.113.5:6789, NAT64 recherche la session et traduit vers 2001:db8:100::45:1234.

Traduction de protocole#

NAT64 traduit plus que les adresses — il convertit entre les formats de paquets IPv4 et IPv6 :

Paquet IPv6 :

[ En-tête IPv6 | En-tête TCP/UDP/ICMP | Charge utile ]

Traduit en IPv4 :

[ En-tête IPv4 | En-tête TCP/UDP/ICMP | Charge utile ]

La traduction inclut :

• TTL/Hop Limit : Décrémenté et copié
• Fragmentation : Fragmentation IPv6 → fragmentation IPv4 (avec considérations MTU)
• ICMP : ICMPv6 → ICMPv4 (mappage de type de message)
• Sommes de contrôle : Recalculées pour les nouveaux en-têtes de protocole

Pool d'adressage#

NAT64 a besoin d'adresses IPv4 pour les connexions sortantes. Les petits déploiements utilisent une seule adresse IPv4 avec surcharge de port (comme les routeurs domestiques). Les déploiements plus importants utilisent des pools.

# Petit: IPv4 unique
Pool NAT64: 203.0.113.5/32
Clients max: ~65 000 sessions simultanées
 
# Grand: Pool IPv4
Pool NAT64: 203.0.113.0/24
Clients max: ~16 millions de sessions simultanées

Les préoccupations d'épuisement d'adresses s'appliquent — NAT64 fait face aux mêmes limitations de port que NAT44.

Options d'implémentation#

Plusieurs implémentations logicielles NAT64 existent, de légères à classe opérateur.

TAYGA : espace utilisateur léger#

TAYGA est un démon NAT64 simple en espace utilisateur pour Linux. Bon pour petits déploiements et tests.

Installation :

apt-get install tayga
 
# Create TUN interface
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

Configuration (/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

Démarrer et router :

systemctl start tayga
 
# Route NAT64 prefix through TAYGA
ip route add 64:ff9b::/96 dev nat64
ip route add 192.168.255.0/24 dev nat64
 
# Enable forwarding
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv4.ip_forward=1

Avantages : Simple, léger, configuration facile Inconvénients : Performance limitée (espace utilisateur), pas de clustering, fonctionnalités minimales

Jool : module noyau#

Jool implémente NAT64 comme module noyau Linux, offrant de meilleures performances.

Installation :

# Add repository (Debian/Ubuntu)
apt-get install linux-headers-$(uname -r)
apt-get install jool-dkms jool-tools
 
# Load module
modprobe jool

Configuration :

# Create NAT64 instance
jool instance add "default" --netfilter --pool6 64:ff9b::/96
 
# Add IPv4 address pool
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
 
# Enable
jool -i "default" global update enabled true

Routage :

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

Avantages : Hautes performances (espace noyau), développement actif, bonne documentation Inconvénients : Complexité du module noyau, problèmes de compatibilité occasionnels avec mises à jour noyau

NAT64 de fournisseur cloud#

Les principales plateformes cloud offrent du NAT64 géré :

AWS (NAT64 via Egress-Only Internet Gateway) :

AWS ne fournit pas de NAT64 natif, mais vous pouvez déployer Jool ou TAYGA sur des instances EC2. Quelques AMI tiers existent.

Alternative : Utilisez double pile avec réseaux internes IPv6 uniquement et IPv4 pour accès externe.

Google Cloud Platform :

GCP fournit Cloud NAT avec support NAT64 (beta) :

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

Azure :

Azure supporte IPv6 mais n'offre pas de NAT64 géré. Déployez le vôtre en utilisant des VM Linux avec Jool ou TAYGA.

Avantages (services gérés) : Pas de maintenance, évolutif, surveillance intégrée Inconvénients : Spécifique au cloud, moins de flexibilité de configuration, coût potentiel

NAT64 classe opérateur#

Les déploiements de télécommunications et grands FAI utilisent des solutions commerciales :

• Cisco ASR avec CGv6
• Juniper MX Series avec service NAT64
• A10 Thunder CGN
• F5 BIG-IP avec module CGNAT

Ceux-ci gèrent des millions de sessions simultanées avec haute disponibilité, journalisation pour conformité légale et politiques de trafic sophistiquées.

464XLAT : activation des applications IPv4 uniquement#

NAT64/DNS64 fonctionne de manière transparente pour les applications double pile. Mais certaines applications codent en dur des adresses IPv4 ou utilisent des protocoles que DNS64 ne peut pas intercepter. 464XLAT résout cela.

Comment fonctionne 464XLAT#

464XLAT ajoute la traduction côté client (CLAT) avant NAT64 (PLAT) :

┌─────────────┐      ┌──────────────┐      ┌──────────────┐
│  App IPv4   │      │              │      │              │
│             │      │ Réseau IPv6  │      │ Serveur IPv4 │
│ 192.0.0.10  │      │ uniquement   │      │198.51.100.10 │
└──────┬──────┘      └──────────────┘      └──────────────┘
       │                                            │
   CLAT (local)                                PLAT (FAI)
   NAT46: IPv4→IPv6                           NAT64: IPv6→IPv4
       │                                            │
       └──────────── Réseau IPv6 ──────────────────┘

Étapes :

1. L'app envoie un paquet IPv4 à 192.0.0.10 (interface virtuelle CLAT)
2. CLAT traduit IPv4 → IPv6 en utilisant un préfixe local (ex: 64:ff9b::c000:0a)
3. Le paquet IPv6 traverse le réseau vers PLAT (passerelle NAT64)
4. PLAT traduit IPv6 → IPv4
5. Le paquet IPv4 atteint la destination

L'app voit la connectivité IPv4 locale. Le réseau est IPv6 uniquement. La traduction se produit aux deux extrémités.

464XLAT sur mobile#

Android et iOS implémentent CLAT automatiquement lorsqu'ils sont connectés à des réseaux IPv6 uniquement avec NAT64 :

CLAT Android :

• Détecte NAT64 en interrogeant ipv4only.arpa (retourne AAAA synthétisé si NAT64 existe)
• Crée l'interface clat4 avec adresses 192.0.0.0/29
• Route le trafic des apps IPv4 via CLAT
• Traduit vers IPv6 en utilisant le préfixe NAT64 détecté

CLAT iOS :

• Mécanisme de détection similaire
• Transparent pour les apps et utilisateurs

C'est pourquoi les apps IPv4 uniquement fonctionnent sur T-Mobile, AT&T et autres réseaux mobiles IPv6 uniquement.

Linux 464XLAT avec Clatd#

Pour les systèmes Linux sur réseaux IPv6 uniquement :

# Install
apt-get install clatd
 
# Configure /etc/clatd.conf
clat-v4-addr=192.0.0.1
clat-v6-addr=2001:db8:1234:5678::1
plat-prefix=64:ff9b::/96
 
# Start
systemctl enable --now clatd
 
# Verify
ip addr show clat
ping -4 8.8.8.8  # Devrait fonctionner même sur réseau IPv6 uniquement

Utilisez 464XLAT quand :

• Vous avez des applications IPv4 uniquement qui ne peuvent pas être mises à jour
• Les applications contournent le DNS (IP codées en dur)
• Vous avez besoin d'un support IPv4 transparent sur infrastructure IPv6 uniquement

Scénarios de déploiement#

NAT64/DNS64 convient à des cas d'usage spécifiques. Comprendre quand le déployer évite les erreurs architecturales.

Scénario 1 : réseaux mobiles#

Situation : Opérateur 5G/LTE avec des millions d'abonnés, adresses IPv4 limitées

Solution : Réseau IPv6 uniquement avec NAT64/DNS64 + 464XLAT

Avantages :

• Élimine IPv4 du réseau radio et du cœur
• Routage simplifié (protocole unique)
• Évolue sans contraintes d'adresses IPv4
• Supporte les apps héritées via 464XLAT

Implémentation :

• PLAT (NAT64) dans le cœur opérateur
• DNS64 sur serveurs DNS opérateur
• CLAT sur combinés (automatique)

C'est l'architecture mobile dominante à l'échelle mondiale.

Scénario 2 : réseaux d'entreprise IPv6 uniquement#

Situation : Nouveau centre de données, voulez IPv6 uniquement pour éviter la complexité double pile

Solution : Réseau interne IPv6 uniquement, NAT64 pour accéder aux services IPv4 externes

Avantages :

• Adressage simplifié (pas de DHCP IPv4, NAT, etc.)
• Architecture moderne
• Force les applications à supporter IPv6

Défis :

• Certaines apps d'entreprise restent IPv4 uniquement
• Les interfaces de gestion sont souvent IPv4 uniquement
• Compatibilité matériel hérité

Recommandation : Double pile généralement plus facile pour l'entreprise. IPv6 uniquement a du sens pour environnements greenfield, cloud natifs.

Scénario 3 : microservices cloud natifs#

Situation : Cluster Kubernetes, services communiquent en interne via IPv6

Solution : Cluster IPv6 uniquement avec NAT64 pour dépendances API IPv4 externes

Avantages :

• Maillage de services simplifié
• Pas d'épuisement d'adresses IPv4 dans grands clusters
• IPv6 natif pour réseau conteneur

Implémentation :

• Mode IPv6 uniquement Kubernetes
• Passerelle NAT64 pour sortie
• DNS64 via DNS cluster (CoreDNS le supporte)

# CoreDNS ConfigMap with 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
    }

Cas d'usage croissant à mesure qu'IPv6 devient standard dans l'orchestration de conteneurs.

Limitations et pièges#

NAT64/DNS64 n'est pas parfait. Comprendre les limitations évite les échecs de déploiement.

1. DNSSEC casse#

DNS64 synthétise des enregistrements AAAA qui n'existent pas dans la zone faisant autorité. Les signatures DNSSEC ne couvrent pas ces enregistrements synthétiques, donc la validation échoue.

Solutions :

• Désactiver la validation DNSSEC sur le résolveur DNS64 (pas idéal)
• Utiliser un DNS64 qui supporte la gestion DNSSEC RFC 6147 (implémentation limitée)
• Accepter que les domaines IPv4 uniquement signés DNSSEC ne valideront pas

C'est le plus grand défi opérationnel avec DNS64.

2. Adresses IPv4 codées en dur#

Les applications avec IP codées en dur contournent le DNS, donc DNS64 ne voit jamais la requête. NAT64 ne peut pas aider car il ne reconnaît que le préfixe NAT64.

Solutions :

• Déployer 464XLAT (gère tout le trafic IPv4)
• Mettre à jour les applications pour utiliser des noms DNS
• Utiliser des passerelles de couche application (rare, complexe)

3. Littéraux IPv4 dans les URL#

Les apps web passant http://192.0.2.1/api dans les URL ou configuration. Les navigateurs n'effectuent pas de recherches DNS pour les littéraux IP, donc DNS64 ne synthétise pas.

Solutions :

• Utiliser des noms d'hôte au lieu de littéraux IP
• Proxies de couche application qui réécrivent les littéraux
• 464XLAT

4. FTP et autres ALG#

Les protocoles qui intègrent des adresses IP dans les données d'application (mode actif FTP, SIP, etc.) échouent souvent via NAT64. L'adresse dans la charge utile ne correspond pas à l'en-tête de paquet.

Solution :

• Utiliser le mode passif FTP (pas d'adresses intégrées)
• Déployer NAT64 conscient du protocole avec support ALG (complexe)
• Passer aux protocoles modernes qui n'intègrent pas d'IP

5. Problèmes de fragmentation#

Les différences de MTU de chemin entre IPv4 et IPv6 peuvent causer des problèmes de fragmentation. IPv6 a un MTU minimum de 1280 octets ; IPv4 autorise 576 octets.

Solution :

• Assurer que le MTU est cohérent dans l'infrastructure
• Activer Path MTU Discovery (PMTUD)
• Surveiller et alerter sur les messages ICMP Packet Too Big

6. DNS inverse#

Les enregistrements PTR pour les adresses traduites NAT64 n'existeront pas. Les applications qui nécessitent du DNS inverse (certains serveurs mail, contrôles d'accès) peuvent échouer.

Solution :

• Créer des enregistrements PTR pour le pool NAT64
• Configurer les services pour ne pas exiger de DNS inverse
• Utiliser IPv6 nativement où le DNS inverse importe

Surveillance et dépannage#

NAT64/DNS64 ajoute des couches de traduction qui peuvent obscurcir les problèmes. Une surveillance appropriée est essentielle.

Vérification DNS64#

Testez si DNS64 fonctionne :

# Query for known IPv4-only domain
dig AAAA ipv4.google.com @2001:db8::53
 
# Devrait retourner AAAA synthétisé avec préfixe NAT64
# Exemple: 64:ff9b::8.8.8.8

Si vous n'obtenez pas d'enregistrement AAAA, DNS64 ne fonctionne pas.

Test de connectivité NAT64#

Utilisez le domaine de test spécial ipv4only.arpa :

# From IPv6-only client
ping6 ipv4only.arpa
 
# Devrait recevoir réponse via NAT64
# Le domaine se résout en 192.0.0.170, synthétisé en 64:ff9b::192.0.0.170

Si le ping échoue, la passerelle NAT64 n'est pas joignable ou ne traduit pas.

Inspection de la table de session#

Vérifiez l'état de session NAT64 :

Jool :

jool -i "default" session display
 
# Shows active sessions
# Recherchez: client IPv6, IPv4 traduit, destination

TAYGA :

cat /var/lib/tayga/dynamic.map
 
# Shows address mappings

Des comptes de session élevés indiquent une utilisation intensive ou des problèmes potentiels (fuites de connexion).

Analyse de trafic#

Capturez le trafic avant et après traduction :

# Capture IPv6 traffic to NAT64 prefix
tcpdump -i eth0 -n 'ip6 and dst net 64:ff9b::/96'
 
# Capture translated IPv4 traffic
tcpdump -i eth1 -n 'ip and src 203.0.113.5'
 
# Comparez pour vérifier la traduction

Recherchez :

• Paquets arrivant à NAT64 mais ne sont pas traduits
• Traduction se produisant mais paquets non transmis
• Routage asymétrique (trafic de retour n'atteint pas NAT64)

Problèmes courants#

Symptôme : DNS64 retourne AAAA synthétisé, mais connexion échoue

Causes :

• Passerelle NAT64 inaccessible
• Pare-feu bloquant le préfixe NAT64
• Problème de routage (paquets vers préfixe NAT64 vont dans mauvaise direction)

Débogage :

traceroute6 64:ff9b::198.51.100.1
# Devrait router vers passerelle NAT64

Symptôme : Certains sites fonctionnent, d'autres non

Causes :

• Sites avec IPv6 natif fonctionnent (pas de NAT64 impliqué)
• Sites IPv4 uniquement avec exigences spéciales échouent
• Problèmes de fragmentation ou MTU

Débogage :

# Test with different MTUs
ping6 -M do -s 1400 64:ff9b::198.51.100.1

Symptôme : Connexions lentes ou expiration de délai

Causes :

• Passerelle NAT64 surchargée
• Table de session pleine
• Routage asymétrique

Débogage :

# Check NAT64 CPU and session count
# Surveiller le temps d'établissement de connexion
time curl -6 http://ipv4-only-site.example.com

Considérations de sécurité#

NAT64 introduit des implications de sécurité au-delà du NAT typique.

Scan d'espace d'adressage#

Le préfixe NAT64 rend les adresses IPv4 prévisibles en IPv6. Les attaquants peuvent scanner 64:ff9b::/96 pour découvrir quels services IPv4 vous accédez.

Atténuation : Utiliser des préfixes NAT64 spécifiques au réseau au lieu du préfixe bien connu, limitant l'exposition.

Contournement des contrôles d'accès#

Les contrôles d'accès IPv4 (règles pare-feu, ACL) peuvent ne pas tenir compte du trafic traduit NAT64 arrivant de sources IPv6 inattendues.

Atténuation : Appliquer les politiques de sécurité à la passerelle NAT64, pas seulement aux points de terminaison.

NAT64 comme amplificateur d'attaque#

Les attaquants sur réseaux IPv6 uniquement peuvent utiliser NAT64 pour lancer des attaques contre des cibles IPv4, contournant potentiellement la limitation de taux ou les listes noires basées sur IPv4.

Atténuation :

• Limiter le taux des sessions NAT64 par source
• Journaliser toutes les traductions NAT64 pour enquête sur abus
• Appliquer les mêmes politiques de sécurité que NAT IPv4

Empoisonnement de cache DNS64#

Si le serveur DNS64 est compromis, les attaquants peuvent synthétiser des enregistrements AAAA malveillants pointant vers des adresses IPv4 contrôlées par l'attaquant via NAT64.

Atténuation :

• Sécuriser les serveurs DNS64 (comme toute infrastructure DNS)
• Utiliser DNSSEC où possible (malgré les problèmes de compatibilité)
• Surveiller DNS64 pour modèles de synthèse inhabituels

Quand utiliser NAT64/DNS64 vs. double pile#

Cadre de décision :

┌─────────────────────────────────────────────────┐
│ Pouvez-vous exécuter double pile?               │
└─────────────────────┬───────────────────────────┘
                      │
          ┌───────────┴──────────┐
          │                      │
         OUI                    NON
          │                      │
          ▼                      ▼
   ┌─────────────┐     ┌─────────────────────┐
   │ Utiliser    │     │ Pourquoi pas?       │
   │ double pile │     │                     │
   │             │     │ • Épuisement IPv4   │
   │ (plus       │     │ • Simplification    │
   │  simple,    │     │   architecturale    │
   │  moins de   │     │ • Réseau mobile     │
   │  problèmes) │     │ • Cloud natif       │
   └─────────────┘     └──────────┬──────────┘
                                  │
                                  ▼
                         ┌────────────────────┐
                         │ Utiliser NAT64/    │
                         │ DNS64              │
                         │                    │
                         │ Ajouter 464XLAT si:│
                         │ • Apps IPv4 uniqt  │
                         │ • IP codées dur    │
                         └────────────────────┘

NAT64/DNS64 a du sens quand :

• L'épuisement d'adresses IPv4 est une contrainte réelle
• Vous construisez une nouvelle infrastructure (greenfield)
• Réseau mobile ou architecture cloud native
• Les avantages opérationnels de la pile unique l'emportent sur la complexité de traduction

La double pile a du sens quand :

• Les adresses IPv4 sont disponibles
• Infrastructure mixte héritée et moderne
• La compatibilité est la plus haute priorité
• Familiarité de l'équipe avec la double pile

L'avenir de NAT64#

L'adoption de NAT64 croît à mesure que les réseaux IPv6 uniquement deviennent plus courants :

Tendances :

• Opérateurs mobiles presque universellement déployés
• Fournisseurs cloud ajoutant options NAT64 gérées
• IoT et edge computing utilisant IPv6 uniquement + NAT64
• Centres de données expérimentant IPv6 uniquement pour coût/simplicité

Défis restants :

• Compatibilité DNSSEC toujours non résolue élégamment
• Problèmes de protocole de couche application persistent
• L'expertise opérationnelle se développe encore

Long terme : À mesure qu'Internet IPv4 rétrécit et qu'IPv6 devient omniprésent, l'utilisation de NAT64 peut diminuer — la plupart des destinations auront IPv6 natif, ne nécessitant aucune traduction. Mais c'est dans des années. Pour l'instant, NAT64/DNS64 est la technologie clé permettant les réseaux IPv6 uniquement.

Commencer petit et tester#

Ne déployez pas NAT64/DNS64 en production sans tests approfondis :

1. Environnement de laboratoire : Configurez TAYGA ou Jool sur réseau de test
2. Configurer DNS64 : Utilisez BIND ou Unbound
3. Tester les applications : Vérifiez que vos apps spécifiques fonctionnent via traduction
4. Surveiller les performances : Mesurez la latence et la surcharge de débit
5. Documenter les problèmes : Notez quelles apps ou services ont des problèmes
6. Planifier les solutions de contournement : Double pile pour services problématiques, 464XLAT pour autres

Seulement après des tests réussis devriez-vous considérer un déploiement en production, et même alors, commencez avec des réseaux ou segments d'utilisateurs non critiques.

NAT64/DNS64 est puissant mais ajoute de la complexité. Utilisez-le où il résout de vrais problèmes, pas parce que c'est une technologie nouvelle.

Articles connexes#

• Stratégies de migration IPv6 - Choisir la bonne approche de migration
• Déploiement IPv6 double pile - Exécuter IPv4 et IPv6 ensemble
• Configuration DNS IPv6 - Configurer le DNS pour IPv6

Questions fréquemment posées#