Auteur Sujet: Article d'avril 2012 sur le 464XLAT, développé à l'origine sur un Nokia N900 ! (Lu 5961 fois)

vivien · « **le:** 14 avril 2021 à 08:13:50 »

Traduction de l'article 464XLAT -- A Solution for Providing IPv4 Services Over and IPv6-only Network qui date d'avril 2012, mais qui est quand même intéressant.
Depuis cet article 464XLAT est stable, supporté par presque tous les systèmes d'exploitation et utilisé industriellement. Un opérateur mobile en Inde revendique plus de 500 millions de clients IPv6 only, avec du 464XLAT.

464XLAT - Une solution pour fournir des services IPv4 sur un réseau IPv6 only

Énoncé du problème

Comme indiqué dans le draft-arkko-ipv6-only-experience, les réseaux IPv6 only, même avec du NAT64 / DNS64, ne peuvent pas atteindre la parité de niveau de service avec les réseaux traditionnels IPv4 only. Certaines applications et services ne fonctionnent tout simplement pas correctement sur IPv6. IPv4 est requis en raison des mauvaises pratiques de programmation qui font référence a des API réseau spécifiques IPv4 au lieu d'API indépendantes du protocole IP, utilisent des IPv4 littérales au lieu d'utiliser des noms DNS FQDN. Tous les scénarios de défaillance ci-dessus sont évitables et devront être résolus pour que les applications prospèrent dans la nouvelle réalité Internet où il existe des clients IPv4 only, IPv6 only et des clients double pile (IPv4+IPv6).

Une enquête sur l'état de préparation d'IPv6 sur l'Android Market a montré qu'environ 85% des applications étaient compatibles IPv6, tandis qu'environ 15% ne fonctionnaient pas sur des réseaux exclusivement IPv6. Les données sont ici. La plupart des applications qui ont échoué utilisent une communication peer-to-peer (Skype, Google Hangouts, Tango, ...).

Historique de 464XLAT

L'opérateur T-Mobile aux USA prend en charge une implémentation bêta du service IPv6 GSM et UMTS depuis février 2010. En essayant de résoudre certaines limitations de l'IPv6 only, certains utilisateurs précoces d'IPv6 à l'esprit technique ont commencés à expérimenter la traduction locale d'IPv4 en IPv6 sur le smartphone Nokia N900 en août 2010. Cela a permis à diverses applications de fonctionner correctement sur des réseaux IPv6 only qui, autrement, nécessiteraient IPv4. Cette même idée et ce même code ont maintenant été portés sur Android et soumis au projet Android Open Source. Au même moment au Japon, JPIX et NEC ont travaillé sur la même solution de réseau d'accès IPv6 only, avec des adresses IPv4 partagées dans le cœur.

La proposition de solution 464XLAT

La RFC 6877 est maintenant publiée !

This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation.

Le diagramme de Dan Drown :

Proof of Concept

Le but de cette section est de fournir suffisamment d'informations pour que divers opérateurs de réseau puissent reproduire, tester et déployer 464XLAT.

Android + CLAT sur un réseau UMTS IPv6 only avec DNS64 / NAT64

Le combiné mobile est un téléphone Nexus S exécutant le logiciel CLAT
- Le logiciel CLAT découvre le Pref64 à l'aide de draft-ietf-behave-nat64-discovery-heuristic
- Le réseau mobile fournit l'interface WAN du combiné avec un préfixe IPv6 /64, un /96 de cet espace est utilisé pour le mappage vers les adresses IPv4
- L'interface CLAT fournit la route requise et l'interface au niveau du système d'exploitation IPv4 pour que les applications IPv4 only fonctionnent correctement
Le réseau mobile utilisé est le T-Mobile (aux USA) IPv6 Beta
- Le réseau est conforme à la 3GPP Release 7 et permet la mise en place d'un PDP IPv6
- Le réseau dispose de services NAT64 et DNS64 avec état, le serveur DNS fourni est activé DNS64.
- Pour NAT64, le préfixe spécifique au réseau est utilisé pour des raisons d'ingénierie du trafic. Le préfixe well known n'est pas utilisé.
- Aucune modification n'a été nécessaire pour le réseau T-Mobile USA IPv6-only + NAT64 / DNS64 existant pour prendre en charge l'architecture 464XLAT. La traduction sans état RFC6145 sur le combiné était la seule modification nécessaire.
Résultats :
- Sur test-ipv6.com, le combiné obtient un score de 10/10 pour IPv4 et 10/10 pour la connectivité IPv6, auparavant le score était de 7/10 pour IPv4 car les connexions littérales IPv4 ont échoué.
- Skype, Netflix et d'autres applications qui étaient autrement interrompues sur un réseau IPv6 only fonctionnent désormais correctement. Notez la colonne H dans les données
- L'interface rmnet0 est IPv6 only et l'interface CLAT a IPv4 et IPv6
- CLAT sur l'appareil permet d'obtenir des scores 10/10 pour IPv4 et IPv6 sur test-ipv6.com
- Skype effectue un appel réussi, la signalisation des adresses IPv4 fonctionne car l'application peut se lier à l'adresse IPv4 CLAT
- Google Talk Video Chat fonctionne correctement malgré la signalisation des littéraux IPv4, l'interface CLAT autorise cette application alors qu'elle serait autrement interrompue sur IPv6 only
- Netflix se connecte et lit la vidéo correctement

Un Cisco ASR 1000 utilisé pour la mise en œuvre publique du CLAT et LITNET de Linux NAT64 + BIND DNS64 en tant que PLAT

La configuration du Cisco ASR 1000 CLAT est ici
- CLAT dispose d'un réseau IPv4 only avec 1 PC Windows 7 (autres scénarios également décrits ci-dessous pour la double pile et l'utilisation de DNS64)
- CLAT est configuré pour transférer tout le trafic IPv4 vers le LITNET NAT64, il n'y a pas eu de coordination avec LITNET pour prendre en charge ce test.
- CLAT transmet tout le trafic IPv6 sans aucune modification.
- Tout le trafic IPv4 de G0 / 0/0 (LAN IPv4 only) est traduit par RFC6145 car il est acheminé vers G0 / 0/3 (WAN IPv6 only)
Résultats
- Le PC Windows à double pile avec 464XLAT et WAN IPv6 only obtient un score de 10/10 pour IPv4 et IPv6 test-ipv6.com
- La navigation Web IPv4 normale fonctionne correctement
- La requête DNS peut être effectuée à partir d'un hôte IPv4 only vers n'importe quel serveur DNS public arbitraire tel que 8.8.8.8
- Lorsqu'un hôte à double pile est utilisé, il peut utiliser le DNS64 pour minimiser la traduction sur le CLAT puisque l'hôte à double pile recevra toujours des réponses AAAA pour les requêtes DNS.

Prochaines étapes

Code CLAT Android accepté et disponible sur les smartphones Android commerciaux
Partage des meilleures pratiques pour la mise en place d'un réseau IPv6 only avec du CLAT
464XLAT n'est plus nécessaire car les applications fonctionnent désormais sur IPv6 !

FAQ

Q: Pourquoi avez-vous créé cette page Web?
R: Pour démontrer que 464XLAT est une architecture utile avec du code qui fonctionne. Il est également destiné à aider les opérateurs de réseau à commencer leurs propres recherches, tests et déploiement de 464XLAT.

Q: Tous les tests ci-dessus démontrent comment 464XLAT permet au réseau de périphérie de se développer sans être étroitement couplé avec des ressources IPv4, puisque IPv4 est tout partagé sur le NAT PLAT avec état?
R: Oui, 464XLAT permet un partage avec état très efficace de ressources IPv4 limitées.

Q: Existe-t-il un moyen de le démontrer en utilisant uniquement du code libre et open source?
R: Oui, il existe des PLAT gratuits (Linux NAT64, OpenBSD PF, Ecdysis ....) et CLAT (Android, Vyatta / ASAMAP - configuration, CLATd pour Linux)

Q: Mon organisation n'aime pas l'open source, est-ce que cela peut être fait avec du matériel commercial?
R: Oui, il existe plusieurs plates-formes NAT64 PLAT: Cisco, Juniper, Brocade, A10 et autres. Vous pouvez également utiliser l'ASR 1000 comme CLAT en utilisant la traduction sans état (illustré ci-dessus)

Q: Où puis-je obtenir plus d'informations ou suggérer quelque chose sur 464XLAT?
R: Un bon point de départ est le 464XLAT IETF RFC 6877

vivien · « **Réponse #1 le:** 14 avril 2021 à 08:33:45 »

Le 464XLAT est ensuite arrivé avec Android 4.3 jellybean, sortie en juillet 2013.

Pour le partage de connexion IPv6 lorsqu'il n'y a qu'un seul préfixe / 64 délégué au combiné, c'est arrivé avec Android à partir de 5.1 Lollipop sortie en mars 2015.
cf RFC7278 : Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link

vivien · « **Réponse #2 le:** 15 avril 2021 à 11:17:06 »

Schéma montrant le fonctionnement du 464XLAT :

vivien · « **Réponse #3 le:** 15 juin 2021 à 10:02:01 »

Pourquoi sous Android l’IPv4 publique utilisée par le DNS64 est différent de celle utilisée pour le 464XLAT ?

Un seul préfixe NAT64 est utilisé, aussi bien pour le DNS64 que pour le 464XLAT. Toutefois l’opérateur alloue un /64 d’adresses IPv6 au mobile. De nombreux mobiles Android utilisent une IPv6 source, différente de l’IPv6 source utilisée par le CLAT, pour les flux qui partent directement sur Internet.

La plateforme NAT64 de l’opérateur peut attribuer une adresse IPv4 source différente aux flux provenant de deux IPv6 source distinctes, même si les deux IPv6 sont dans le même /64. Il en résulte que l’IPv4 publique affichée pour une requête vers un site IPv4 only joint via DNS64 peut être différente de celle utilisée pour joindre le même site depuis le même mobile, mais via une IPv4 littérale.

L’IPv6 destination du DNS64 et celle calculée par le CLAT sont identiques, ce sont les IPv6 sources différentes qui font que les deux IPv4 publiques du DNS64 sont différentes.

vivien · « **Réponse #4 le:** 19 juillet 2021 à 12:11:20 »

Dans le rapport sur l’état d’internet en France de l'Arcep, édition 2021 :

Citation de: vivien le 14 juillet 2021 à 21:59:21

Il y a quand même des nouveautés dans le rapport, comme les explications sur les accès IPv6 et le mécanisme de 464XLAT :

vivien · « **Réponse #5 le:** **Hier** à 10:50:08 »

2025 : le CLAT va arriver sous Windows 11, pour la prise en charge du 464XLAT en entreprise

Les technologies liées à IPv6 mettent du temps à venir...

L'article de Microsoft du 18 novembre 2025 dans le Microsoft Networking Blog, traduit en français :

Windows CLAT entre en phase d'évaluation privée : une étape importante pour l'adoption d'IPv6

Le chemin vers un Internet entièrement compatible IPv6 a été long, mais nous célébrons aujourd'hui une étape majeure.

Adoption d'IPv6 : un changement mondial

Depuis sa normalisation à la fin des années 1990, le protocole IPv6 a progressivement gagné du terrain. Ces quinze dernières années ont été marquées par des progrès considérables. Le taux d'adoption mondial de l'IPv6 se situe désormais entre 43 et 48 %, avec des pays comme la France (80 %), l'Allemagne (75 %) et l'Inde (74 %) en tête. Les États-Unis dépassent légèrement les 50 %, tandis que d'autres pays, comme la Chine, restent en dessous de 5 %.

Ce changement est dû à l'épuisement des adresses IPv4 – seules 4,3 milliards ont été disponibles. L'essor des appareils mobiles, de l'Internet des objets et des services cloud a accéléré cette raréfaction. Les gouvernements réagissent : Aux États-Unis, le Office of Management and Budget (OMB) exige que 80 % des ressources fédérales fonctionnent exclusivement en IPv6 d'ici fin 2025 (OMB M-21-07), et l'Allemagne a également fait de l'IPv6 une priorité dans ses plans d'infrastructure numérique (BDBOS IPv6 Programme).

Mécanismes de transition : des tunnels à la traduction

Au fil des années, divers mécanismes de transition d'IPv4 vers IPv6 ont émergé :
- Tunneling (ex. 6to4, Teredo) : souvent peu fiable en raison des dépendances NAT et de relais.
- Double pile IPv4+IPv6 : Efficace, mais gourmande en ressources et non durable à long terme.
- Technologies de traduction : Notamment NAT64 et DNS64, qui permettent aux clients IPv6 uniquement d'accéder aux services IPv4.

Parmi ces éléments, CLAT (Customer-side Translator) se distingue comme un facteur clé du fonctionnement des réseaux exclusivement IPv6. Il fait partie de l'architecture 464XLAT, définie dans la RFC 6877, et combine :
- CLAT : Traduction sans état (SIIT, RFC 7915) sur le client.
- PLAT : NAT64 avec état (RFC 6146) côté fournisseur.
Ensemble, ils permettent aux clients fonctionnant uniquement en IPv6 de communiquer avec des serveurs fonctionnant uniquement en IPv4 sans nécessiter de connectivité IPv4 sur le client.

À l'écoute de notre communauté

Début 2024, l'équipe Réseau du système d'exploitation Windows a mené une enquête sur la migration vers IPv6. Les résultats étaient sans équivoque : CLAT était la fonctionnalité IPv6 la plus demandée pour Windows. Ces retours ont contribué à définir notre feuille de route et ont renforcé notre engagement à fournir la prise en charge de CLAT.

La voici : aperçu privé de Windows CLAT

Cela fait plus d'un an que nous n'avons pas donné de nouvelles à notre communauté concernant CLAT et nous sommes ravis d'annoncer aujourd'hui que Windows CLAT est désormais disponible en avant-première privée. Vous trouverez ci-dessous plus d'informations sur la manière de participer à cette avant-première.

Comment fonctionne le CLAT

CLAT facilite la transition vers IPv6 en assurant la liaison entre les réseaux IPv6 et les applications et serveurs IPv4. Il s'appuie sur 464XLAT, qui combine :

1/ CLAT (Traducteur côté client)
- Effectue une traduction IP/ICMP sans état (SIIT, RFC 7915).
- Convertit les adresses IPv4 privées en adresses IPv6 globales et vice versa.
- Intégré au client, Windows en l'occurrence.

2/ PLAT (Traducteur côté fournisseur)
- Effectue une traduction avec état (NAT64, RFC 6146).
- Convertit les adresses IPv6 globales en adresses IPv4 globales et vice versa.
- Généralement déployés sur des périphériques tels que les routeurs.

Activation CLAT et flux de paquets

L'activation de CLAT sur un client Windows suit une séquence logique conçue pour garantir une prise en charge transparente des applications IPv4 sur les réseaux exclusivement IPv6 :

Figure 1 : Options d'activation de CLAT et de découverte de préfixes

1. Connectivité IPv6 uniquement : lors de l’initialisation de son interface réseau, un périphérique client Windows peut constater qu’aucune connectivité IPv4 native n’est disponible. De même, lors de la négociation DHCPv4, le réseau peut envoyer l’option 108, signalant que l’hôte peut fonctionner temporairement en mode IPv6 uniquement. Bien que l’option 108 du DHCPv4 (RFC 8925) ne fournisse pas de préfixe NAT64, elle indique une préférence pour IPv6 uniquement. Le système est alors amené à envisager un fonctionnement en mode IPv6 uniquement.

2. Détection de la disponibilité d'un traducteur NAT64 (PLAT) : L'hôte tente ensuite de déterminer si un traducteur NAT64 existe sur le réseau et quel est son préfixe NAT64 associé. Cette détection peut s'effectuer par deux mécanismes :
- Option Router Advertisement (RA) PREF64 (RFC 8781) : Le routeur réseau envoie des messages RA contenant l'option PREF64, informant explicitement l'hôte du préfixe NAT64.
- DNS-based discovery (RFC 7050) : L’hôte effectue des requêtes DNS AAAA pour ipv4only.arpa à l’aide du résolveur récursif du réseau. La réponse permet à l’hôte de déduire le préfixe NAT64.

3. Activation de CLAT : Une fois que l’hôte a confirmé la présence d’une PREF64 valide, il active CLAT. Cela garantit le fonctionnement des applications IPv4 uniquement, même dans un environnement IPv6 uniquement.

4. Adresse IPv4 synthétisée : CLAT configure une adresse IPv4 synthétique et une route par défaut IPv4. Cela permet aux applications IPv4 existantes de se connecter comme si une adresse IPv4 native était présente.

5. Traduction IPv4 vers IPv6 sans état : chaque paquet IPv4 généré par une application est intercepté par CLAT. À l’aide du préfixe NAT64 appris et des règles définies dans la RFC 6052, CLAT synthétise une adresse de destination IPv6 intégrant l’adresse IPv4 d’origine.

6. Routage vers NAT64 (PLAT) : Le paquet IPv6 nouvellement formé est acheminé sur le réseau IPv6 uniquement jusqu’au traducteur NAT64. Le PLAT effectue une traduction avec état, reconvertissant le paquet IPv6 en IPv4 et le transmettant à sa destination IPv4.

Figure 2 : Exemple d'activation CLAT et de flux de paquets

Ce flux garantit que même dans les environnements où IPv4 n'est plus disponible nativement, les applications existantes peuvent continuer à fonctionner de manière transparente sur l'infrastructure IPv6.

Perspectives : Construire le futur d'IPv6 avec CLAT

La préversion privée de Windows CLAT marque une étape cruciale dans notre transition vers l'IPv6. Il ne s'agit pas seulement d'une prouesse technique, mais aussi d'une réponse à la demande de la communauté, d'un pas vers la conformité aux réglementations gouvernementales et d'une base pour un réseau prêt pour l'avenir.

Nous sommes ravis de collaborer avec nos partenaires et clients pour peaufiner CLAT en vue de sa disponibilité générale. Si vous souhaitez tester Windows CLAT dans votre environnement, inscrivez-vous à l'aperçu privé sur aka.ms/winclatintake. Restez à l'écoute pour les mises à jour concernant l'aperçu public et merci de contribuer à cette étape importante.

Source : Microsoft Networking Blog, publié le 18 novembre 2025 par l'équipe Réseau du système d'exploitation Windows.

Paul · « **Réponse #6 le:** **Hier** à 23:23:27 »

Ça prête à légèrement sourire, parce qu'avant de voir des réseaux d'entreprise en IPv6 seulement, donc pour donner une utilité à ces protocoles de traduction, il faudrait déjà que l'IPv6 y soit activement déployé. Le scepticisme est par ailleurs palpable dans les commentaires du lien. Ça m'étonne d'autant plus que la demande soit ressortie comme forte dans l'enquête.

Citation de: vivien le Hier à 10:50:08

1/ CLAT (Traducteur côté client)
- Effectue une traduction IP/ICMP sans état (SIIT, RFC 7915).

Merci vivien, pas de translation : erroné en français sauf pour parler de déplacement de vecteurs ou de personnes, et tout le monde s'en fout

.

vivien · « **Réponse #7 le:** **Hier** à 23:51:03 »

Non, je connais des entreprises intéressées : le dual-stack nécessite de mettre toutes les règles en double, les entreprises sont intéressées pour faire le travail proprement et c'est ce que permet de faire le 464XLAT.

Les entreprises savent qu'il faut passer à terme en IPv6, mais elles souhaitent éviter de passer par une case dual-stack qui complique la configuration et qui n'est que temporaire. Dans 20 ans, il n'y aura plus du tout de pile IPv4.

On voit le succès coté mobile de cette technologie (la majorité des mobiles français l'utilisent).

Auteur Sujet: Article d'avril 2012 sur le 464XLAT, développé à l'origine sur un Nokia N900 ! (Lu 5961 fois)

vivien

Article d'avril 2012 sur le 464XLAT, développé à l'origine sur un Nokia N900 !

vivien

Article d'avril 2012 sur le 464XLAT, dévellopé à l'origine sur un Nokia N900 !

vivien

Article d'avril 2012 sur le 464XLAT, dévellopé à l'origine sur un Nokia N900 !

vivien

Article d'avril 2012 sur le 464XLAT, dévellopé à l'origine sur un Nokia N900 !

vivien

Article d'avril 2012 sur le 464XLAT, dévellopé à l'origine sur un Nokia N900 !

vivien

Article d'avril 2012 sur le 464XLAT, développé à l'origine sur un Nokia N900 !

Paul

Article d'avril 2012 sur le 464XLAT, développé à l'origine sur un Nokia N900 !

vivien

Article d'avril 2012 sur le 464XLAT, développé à l'origine sur un Nokia N900 !