La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: vivien le 14 avril 2021 à 08:13:50
-
Traduction de l'article 464XLAT -- A Solution for Providing IPv4 Services Over and IPv6-only Network (https://sites.google.com/site/tmoipv6/464xlat) 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 (https://tools.ietf.org/html/draft-arkko-ipv6-only-experience-05), les réseaux IPv6 only (https://tools.ietf.org/html/rfc6144#section-2.1), même avec du NAT64 (https://tools.ietf.org/html/rfc6146) / DNS64 (https://tools.ietf.org/html/rfc6147), 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 (https://docs.google.com/spreadsheet/ccc?key=0AnVbRg3DotzFdGVwZWlWeG5wXzVMcG5qczZEZloxWGc#gid=0). 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 (https://mailarchive.ietf.org/arch/msg/3gv6/HTq83DPdCzRIvvB4uZGYollb2GI/). En essayant de résoudre certaines limitations de l'IPv6 only, certains utilisateurs précoces d'IPv6 (https://talk.maemo.org/showthread.php?t=60320) à l'esprit technique ont commencés à expérimenter la traduction locale d'IPv4 en IPv6 (https://code.google.com/archive/p/n900ipv6/) sur le smartphone Nokia N900 (https://fr.wikipedia.org/wiki/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 (https://android-review.googlesource.com/c/platform/external/android-clat/+/34490). 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 (https://tools.ietf.org/html/rfc6877) 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 :
(https://lafibre.info/images/ipv6/201201_464xlat_clat_plat_diagramme.png)
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 (https://dan.drown.org/android/clat/)
- Le logiciel CLAT découvre le Pref64 à l'aide de draft-ietf-behave-nat64-discovery-heuristic (https://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-17)
- 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 (https://sites.google.com/site/tmoipv6/lg-mytouch)
- Le réseau est conforme à la 3GPP Release 7 (https://tools.ietf.org/html/rfc6459#section-6.1) 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 (https://docs.google.com/spreadsheets/d/1z8nmENKVXrCR0QcarYOR3p-sc9aMuzVtq-S_5yYi_XE/edit#gid=0)
- L'interface rmnet0 est IPv6 only et l'interface CLAT a IPv4 et IPv6
(https://lafibre.info/images/ipv6/201204_android_ifconfig.png) - 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 (https://www.cisco.com/c/en/us/products/routers/asr-1000-series-aggregation-services-routers/index.html) 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 (https://sites.google.com/site/tmoipv6/asr1kclat)
- 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 (https://android-review.googlesource.com/c/platform/external/android-clat/+/34490) 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 (https://tools.ietf.org/html/rfc6877) 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 (https://github.com/toreanderson/clatd))
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 (https://tools.ietf.org/html/rfc6877)
-
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 (https://www.rfc-editor.org/rfc/rfc7278.txt) : Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link
-
Schéma montrant le fonctionnement du 464XLAT :
(https://lafibre.info/images/ipv6/201201_464xlat_clat_plat_diagramme_fr.png)
-
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.
-
Dans le rapport sur l’état d’internet en France de l'Arcep, édition 2021 :
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 :
(https://lafibre.info/images/ipv6/202107_arcep_rapport_etat_internet_2021_ipv6_only_1.png)
(https://lafibre.info/images/ipv6/202107_arcep_rapport_etat_internet_2021_ipv6_only_2.png)