Réseau IPv6-Only avec NAT64/464XLAT

Les adresses IPv4 s’épuisent. L’ARIN a épuisé son pool libre en septembre 2015. Le RIPE a suivi en novembre 2019. Les adresses restantes sont soit thésaurisées par de grandes organisations, soit échangées sur un marché secondaire à 30-50 $ l’adresse. Pendant ce temps, les opérateurs mobiles — confrontés à une croissance explosive du nombre d’appareils — avaient besoin d’une voie qui ne dépende pas de l’achat d’espace IPv4 supplémentaire.

La réponse : des réseaux IPv6-only avec NAT64 comme pont. Au lieu de faire tourner une double pile (maintenir IPv4 et IPv6 en parallèle, avec toute la complexité opérationnelle que cela implique), des opérateurs comme T-Mobile, Reliance Jio et SK Telecom sont passés en IPv6-only en interne et utilisent NAT64 pour traduire lors des communications avec l’internet IPv4. Le réseau interne se simplifie radicalement : une seule famille d’adresses, un seul jeu de règles de pare-feu, une seule table de routage.

Mais l’IPv6-only casse des choses. Les applications historiques avec des adresses IPv4 codées en dur, les protocoles qui intègrent des IP dans les données applicatives, les clients VPN qui supposent IPv4 — tout cela échoue. 464XLAT résout le dernier kilomètre en ajoutant CLAT (traducteur côté client) directement sur l’appareil. Voici comment tout s’articule.

Ce qui casse en IPv6-only

NAT64 avec DNS64 gère le cas courant — les applications qui résolvent les noms d’hôtes via le DNS. Mais plusieurs catégories de trafic cassent sur un réseau IPv6-only, et les comprendre explique pourquoi CLAT existe.

Adresses IPv4 codées en dur. Toute application qui se connecte directement à une adresse IP (pas un nom d’hôte) contourne entièrement DNS64. Les clients de jeux, les firmwares IoT et les logiciels d’entreprise historiques sont les cas les plus fréquents. CLAT intercepte ces paquets IPv4 au niveau de l’appareil et les traduit en IPv6 avant qu’ils n’atteignent le réseau.

Protocoles qui intègrent des adresses dans les données. SIP (VoIP) et FTP en mode actif placent des adresses IP dans les données de la couche applicative. Une passerelle NAT64 traduit les en-têtes de paquets mais pas les données, ces protocoles voient donc des adresses IPv4 périmées et échouent. Des passerelles de niveau applicatif (ALG) peuvent aider, mais elles ajoutent de la complexité et sont souvent en retard sur les mises à jour des protocoles.

VPN et pair-à-pair. Les tunnels IPsec et WireGuard attendent typiquement une adresse IPv4 interne. Les applications pair-à-pair qui échangent des adresses IP hors bande (candidats ICE WebRTC, BitTorrent) ont aussi des difficultés. L’interface IPv4 virtuelle du CLAT résout la plupart des scénarios VPN ; le P2P nécessite généralement une double pile ou un support IPv6 au niveau du protocole.

Déploiement en pratique

Home lab et petits réseaux. Tayga et Jool sont les deux principales implémentations NAT64 open-source pour Linux. Tayga est plus simple (espace utilisateur, basé sur TUN) ; Jool est plus rapide (module noyau, supporte les modes stateful et stateless). Associez l’un ou l’autre avec un résolveur DNS64 comme BIND ou Unbound, et vous obtenez un réseau IPv6-only fonctionnel avec accès à l’internet IPv4.

Opérateurs mobiles à grande échelle. Le déploiement IPv6-only de T-Mobile couvre des centaines de millions d’appareils. Android inclut CLAT depuis la version 4.3 (2013), et iOS utilise sa propre implémentation de manière transparente. Le NAT64 côté réseau fonctionne sur du matériel de classe opérateur avec un suivi d’état de millions de traductions simultanées.

Entreprise. Les organisations avec de grandes allocations IPv4 font face à des coûts croissants à mesure que les adresses prennent de la valeur. Migrer les réseaux internes vers l’IPv6-only avec NAT64 en périphérie élimine le besoin d’adressage IPv4 interne. Les économies opérationnelles — un seul plan d’adressage, un seul jeu d’ACL, pas de NAT44 — justifient souvent l’effort de migration en moins d’un an.