Messages récents51
IPv6 / Baromètre IPv6 Arcep 2026
« Dernier message par vivien le Hier à 08:46:58 »
Annexe 3.3/ Réseau mobile : les solutions de translation pour fournir une connectivité IPv4 derrière un mobile connecté à un réseau IPv6 only (IPv4 as a Service)
Bouygues Telecom et Orange proposent par défaut à leurs clients mobiles un accès à internet en IPv6 sans proposer d’accès natif IPv4, ce qui nécessite d’utiliser un mécanisme pour accéder aux ressources de l’internet disponibles uniquement en IPv4. Free et SFR proposent un réseau double pile avec une IPv4 privée derrière un Carrier-grade NAT et un préfixe IPv6 d’une taille /64.
Les deux technologies présentées ci-dessous sont complémentaires :
• DNS64 + NAT64 permet de convertir un flux qui utilise le DNS d’IPv4 vers IPv6 ;
• 464XLAT permet de gérer les cas dans lesquels un flux ne fait pas de requête DNS (IPv4 littérale).
Un terminal qui ne gère pas 464XLAT (cas de certaines box 4G) n’aura pas de connectivité IPv4 complète. À l’inverse, il est possible de se passer d’un DNS64 et de faire uniquement du 464XLAT (avec pour avantage de permettre au client de faire du DNSSEC, mais pour inconvénient de rajouter une latence imperceptible, et d’avoir potentiellement un impact sur la batterie d’alimentation de l’appareil).
3.3.1/ Le couple DNS64+NAT64 : une solution pour accéder en IPv6 côté client à un site hébergé en IPv4-only
Comme une partie importante d’internet est encore accessible uniquement en IPv4, Bouygues Telecom et Orange proposent un DNS64 : le résolveur DNS n’envoie pas une adresse IPv4 pour les sites hébergés en IPv4-only, mais une IPv6 spéciale : c’est une IPv6 qui pointe vers une plateforme NAT64, placée sur le réseau de l’opérateur. La plateforme NAT64 permet de faire communiquer la pile réseau IPv6 du client avec internet IPv4. La plateforme NAT64 fait une traduction d’adresse classique (NAT), mais en remplaçant l’IPv4 privée par une adresse IPv6.
DNS64 : Encapsulation de l’adresse destination IPv4 dans l’adresse IPv6
Le DNS64 génère une IPv6 construite à partir du préfixe réservé 64:ff9b::/96. Les 32 derniers bits de l’IPv6 créé sont les 32 bits de l’adresse du site en IPv4. La plateforme NAT64 sur le réseau de l’opérateur récupère l’IPv4 de destination dans l’IPv6 destination qu’il a reçu. L’opérateur sait alors créer une traduction NAT à la volée vers l’IPv4 de destination, et envoyer le paquet sur l’internet IPv4.
3.3.2/ Certains usages ne fonctionnent pas avec le DNS64 : naissance du 464XLAT
Certaines applications et services peuvent ne pas fonctionner côté client avec une IPv6. C’est par exemple le cas quand une application utilise une IPv4 littérale (exemple : 87.65.43.21) au lieu d’utiliser des noms DNS qui seraient résolus par le DNS64. Par exemple une application peer-to-peer a de fortes chances d’utiliser une IPv4 littérale à la place d’un nom de domaine. On se retrouve également en IPv4 quand une application ne fait pas appel au DNS64 proposé par le système d’exploitation, mais utilise son propre résolveur DNS qui n’est pas DNS64 (exemple : Certains terminaux n’utilisent pas le serveur DNS proposé par l’opérateur, mais le DNS 8.8.8.8 de Google). Enfin certains opérateurs, ne proposent pas de DNS64.
Historiquement, le 464XLAT est né de développeurs équipés de Nokia N900 qui ont cherché à utiliser le service IPv6-only proposé par T-Mobile aux USA. Plusieurs applications ne fonctionnaient pas, malgré la présence d’un DNS64 et d’un NAT64 chez l’opérateur. Ces développeurs ont commencé à 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 ensuite été portés sur Android et intégrés au projet Android Open Source* en novembre 2012. Cela a donné naissance à la RFC6877**, publiée en avril 2013.
* Soumission du logiciel nécessaire pour le CLAT au projet Android Open Source.
** RFC 6877 : « 464XLAT: Combination of Stateful and Stateless Translation ».
Le 464XLAT est intégré à partir d’Android 4.3 Jellybean, sortie en juillet 2013. Pour le partage de connexion IPv6 lorsqu’il n’y a qu’un seul préfixe d’une taille /64 délégué au combiné, il a fallu attendre la RFC7278*, publiée en juin 2014 et son intégration à Android à partir de 5.1 Lollipop sortie en mars 2015.
* RFC 7278 : « Extending an IPv6 /64 Prefix from a Third Generation Partnership Project Mobile Interface to a LAN Link ».
Apple de son côté privilégiait une approche sans CLAT, forçant les développeurs à utiliser des API compatibles IPv6, et Apple a imposé avec iOS 9 que toutes les applications soumises à l'App Store supportent les réseaux IPv6-only*, forçant les développeurs à utiliser des API compatibles IPv6 (comme NSURLSession). Toutefois, si les applications devaient être compatibles IPv6, ce n’était pas systématiquement le cas pour le contenu web.
* Diapositives Apple WWDC15 Transition vers des réseaux exclusivement IPv6.
En 2018, Apple a finalement intégré le support du CLAT avec iOS 12.0 pour assurer une compatibilité avec les applications qui utilisent encore des adresses IPv4 « en dur », facilitant ainsi la transition vers des réseaux mobiles IPv6-only. En France métropolitaine, Bouygues Telecom a basculé tous les iPhone équipés d'iOS 12.2 en IPv6 only. Pour Orange, cela fut en place avec iOS 13.0 pour les iPhone 7 ou plus récent et iOS 15.4 pour les iPhone 6S et SE. Free et SFR proposent de l’IPv6 double pile.
Bouygues Telecom et Orange proposent par défaut à leurs clients mobiles un accès à internet en IPv6 sans proposer d’accès natif IPv4, ce qui nécessite d’utiliser un mécanisme pour accéder aux ressources de l’internet disponibles uniquement en IPv4. Free et SFR proposent un réseau double pile avec une IPv4 privée derrière un Carrier-grade NAT et un préfixe IPv6 d’une taille /64.
Les deux technologies présentées ci-dessous sont complémentaires :
• DNS64 + NAT64 permet de convertir un flux qui utilise le DNS d’IPv4 vers IPv6 ;
• 464XLAT permet de gérer les cas dans lesquels un flux ne fait pas de requête DNS (IPv4 littérale).
Un terminal qui ne gère pas 464XLAT (cas de certaines box 4G) n’aura pas de connectivité IPv4 complète. À l’inverse, il est possible de se passer d’un DNS64 et de faire uniquement du 464XLAT (avec pour avantage de permettre au client de faire du DNSSEC, mais pour inconvénient de rajouter une latence imperceptible, et d’avoir potentiellement un impact sur la batterie d’alimentation de l’appareil).
3.3.1/ Le couple DNS64+NAT64 : une solution pour accéder en IPv6 côté client à un site hébergé en IPv4-only
Comme une partie importante d’internet est encore accessible uniquement en IPv4, Bouygues Telecom et Orange proposent un DNS64 : le résolveur DNS n’envoie pas une adresse IPv4 pour les sites hébergés en IPv4-only, mais une IPv6 spéciale : c’est une IPv6 qui pointe vers une plateforme NAT64, placée sur le réseau de l’opérateur. La plateforme NAT64 permet de faire communiquer la pile réseau IPv6 du client avec internet IPv4. La plateforme NAT64 fait une traduction d’adresse classique (NAT), mais en remplaçant l’IPv4 privée par une adresse IPv6.
DNS64 : Encapsulation de l’adresse destination IPv4 dans l’adresse IPv6
Le DNS64 génère une IPv6 construite à partir du préfixe réservé 64:ff9b::/96. Les 32 derniers bits de l’IPv6 créé sont les 32 bits de l’adresse du site en IPv4. La plateforme NAT64 sur le réseau de l’opérateur récupère l’IPv4 de destination dans l’IPv6 destination qu’il a reçu. L’opérateur sait alors créer une traduction NAT à la volée vers l’IPv4 de destination, et envoyer le paquet sur l’internet IPv4.
3.3.2/ Certains usages ne fonctionnent pas avec le DNS64 : naissance du 464XLAT
Certaines applications et services peuvent ne pas fonctionner côté client avec une IPv6. C’est par exemple le cas quand une application utilise une IPv4 littérale (exemple : 87.65.43.21) au lieu d’utiliser des noms DNS qui seraient résolus par le DNS64. Par exemple une application peer-to-peer a de fortes chances d’utiliser une IPv4 littérale à la place d’un nom de domaine. On se retrouve également en IPv4 quand une application ne fait pas appel au DNS64 proposé par le système d’exploitation, mais utilise son propre résolveur DNS qui n’est pas DNS64 (exemple : Certains terminaux n’utilisent pas le serveur DNS proposé par l’opérateur, mais le DNS 8.8.8.8 de Google). Enfin certains opérateurs, ne proposent pas de DNS64.
Historiquement, le 464XLAT est né de développeurs équipés de Nokia N900 qui ont cherché à utiliser le service IPv6-only proposé par T-Mobile aux USA. Plusieurs applications ne fonctionnaient pas, malgré la présence d’un DNS64 et d’un NAT64 chez l’opérateur. Ces développeurs ont commencé à 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 ensuite été portés sur Android et intégrés au projet Android Open Source* en novembre 2012. Cela a donné naissance à la RFC6877**, publiée en avril 2013.
* Soumission du logiciel nécessaire pour le CLAT au projet Android Open Source.
** RFC 6877 : « 464XLAT: Combination of Stateful and Stateless Translation ».
Le 464XLAT est intégré à partir d’Android 4.3 Jellybean, sortie en juillet 2013. Pour le partage de connexion IPv6 lorsqu’il n’y a qu’un seul préfixe d’une taille /64 délégué au combiné, il a fallu attendre la RFC7278*, publiée en juin 2014 et son intégration à Android à partir de 5.1 Lollipop sortie en mars 2015.
* RFC 7278 : « Extending an IPv6 /64 Prefix from a Third Generation Partnership Project Mobile Interface to a LAN Link ».
Apple de son côté privilégiait une approche sans CLAT, forçant les développeurs à utiliser des API compatibles IPv6, et Apple a imposé avec iOS 9 que toutes les applications soumises à l'App Store supportent les réseaux IPv6-only*, forçant les développeurs à utiliser des API compatibles IPv6 (comme NSURLSession). Toutefois, si les applications devaient être compatibles IPv6, ce n’était pas systématiquement le cas pour le contenu web.
* Diapositives Apple WWDC15 Transition vers des réseaux exclusivement IPv6.
En 2018, Apple a finalement intégré le support du CLAT avec iOS 12.0 pour assurer une compatibilité avec les applications qui utilisent encore des adresses IPv4 « en dur », facilitant ainsi la transition vers des réseaux mobiles IPv6-only. En France métropolitaine, Bouygues Telecom a basculé tous les iPhone équipés d'iOS 12.2 en IPv6 only. Pour Orange, cela fut en place avec iOS 13.0 pour les iPhone 7 ou plus récent et iOS 15.4 pour les iPhone 6S et SE. Free et SFR proposent de l’IPv6 double pile.
