Auteur Sujet: Baromètre IPv6 Arcep 2026 (Lu 282 fois)

vivien · « **Réponse #12 le:** **Aujourd'hui** à 08:44:19 »

5/ Transition IPv6 dans le monde

5.1/ Une carte IPv6 interactive sur le site de l’Arcep

La carte IPv6 https://carteipv6.arcep.fr/ est un outil clé pour suivre la transition vers IPv6. Le taux d’utilisation d’IPv6 affiché sur la carte correspond au pourcentage d’utilisateurs raccordés en IPv6 par leur fournisseur d’accès à internet. Cette mesure, réalisée auprès d’hébergeurs^* ayant déjà adopté IPv6, fournit une indication claire de l’état de la transition du côté des utilisateurs finaux, qu’ils soient grand public ou professionnels, sur réseaux fixes et mobiles.

^* La carte présente la médiane des quatre sources, correspondant à la moyenne arithmétique des deux valeurs centrales, afin d’assurer une représentation équilibrée et robuste des données. Les sources de données agrégées principalement utilisées sont celles de Google, Akamai, Facebook et l’APNIC.

En octobre 2025, l’Arcep a mis en place une nouvelle version de sa carte interactive IPv6 qui apporte plusieurs améliorations significatives visant à renforcer la fiabilité, la granularité et la transparence des données :
• Historique étendu : les données consultables remontent désormais à octobre 2013, offrant une perspective historique élargie ;
• Couverture géographique élargie de 100 à 229 pays : la carte intègre désormais des données pour tous les pays, pour une vision mondiale complète de la transition vers IPv6 ;
• Fréquence de mise à jour accrue : les données sont désormais actualisées chaque mois, au lieu de tous les deux mois ;
• Fiabilité des données améliorée : les mesures reposent désormais sur la moyenne des données quotidiennes sur le mois, et non plus sur un point unique de mesure ;
• Classement IPv6 des 100 pays avec le plus grand nombre d’internautes : la méthodologie et la fiabilité de ce classement ont été revues et renforcées.

Les données sont placées en open data sur data.gouv.fr.

5.2/ Position de la France par rapport aux autres pays

Depuis novembre 2025, la France est passée en première position sur le top 100 des pays avec le plus d’internautes. 75,6 % des clients grand public et entreprise ont de l’IPv6 en mars 2026, devant l’Inde (75,1 %) et l’Allemagne (65,4 %). Ce taux intègre les fournisseurs d’accès à internet grand public, mais aussi les offres « pro » et les accès à internet depuis de grandes entreprises.

5.3/ Pays avec la plus forte évolution d’IPv6 en un an

Les pays avec la plus forte progression d’IPv6, entre avril 2025 et avril 2026^* sont les suivants :

^* Des graphiques sont proposés, pays par pays, sur la carte IPv6 interactive.

• Kiribati : +35,3 points
• Niue : +27,0 points
• Îles Marshall : +26,4 points
• Côte d’Ivoire : +19,2 points
• Bolivie : +18,1 points
• République centrafricaine : +17,6 points
• Suriname : +16,1 points
• Tchad : +15,4 points
• Turquie : +15,1 points
• Îles Cook : +12,7 points
• Norvège : +11,8 points
• Indonésie : +11,5 points
• Érythrée : +11,2 points
• République tchèque : +10,9 points
• Tonga : +10,5 points
• Saint-Vincent-et-les-Grenadines : +10,2 points
• Soudan : +9,8 points
• Zimbabwe : +9,6 points
• Sénégal : +8,7 points
• Lituanie : +8,7 points
• Soudan du Sud : +8,6 points
• Panama : +8,5 points
• Équateur : +7,9 points
• Danemark : +7,9 points
• France : +7,6 points
• Guyana : +7,5 points
• Bahamas : +7,5 points
• Allemagne : +7,4 points
• Vanuatu : +6,9 points
• Honduras : +6,8 points
• Bulgarie : +6,8 points
• Îles Salomon : +6,6 points
• Saint-Martin : +6,6 points
• Arabie saoudite : +6,6 points
• Mongolie : +6,2 points
• Singapour : +6,0 points

vivien · « **Réponse #13 le:** **Aujourd'hui** à 08:44:45 »

Annexe 1/ Données complémentaires sur les opérateurs ayant plus de 3 millions de clients

1.1/ Réseau fixe grand public

1.2/ Réseau fixe « Pro »

vivien · « **Réponse #14 le:** **Aujourd'hui** à 08:44:58 »

1.3/ Réseau mobile grand public

1.4/ Réseau mobile « Pro »

vivien · « **Réponse #15 le:** **Aujourd'hui** à 08:45:11 »

1.5/ Possibilité d’accéder à distance à des données hébergées derrière la box

Certains opérateurs offrent la possibilité de paramétrer la box pour accéder depuis internet à du contenu hébergé chez le client. Un usage typique est l’accès à distance à un NAS hébergé derrière la box ou l’auto-hébergement d’un service.

Cet usage demande de pouvoir ouvrir les flux en question, en IPv4 ou en IPv6, selon le choix du client.

Le tableau ci-dessous récapitule la possibilité de réaliser cet usage et les options éventuelles qu’il faudra souscrire chez son opérateur.

Le tableau mentionne également si le client doit utiliser un DynDNS (DNS dynamique, DDNS ou DynDNS), un outil qui va mettre à jour automatiquement un serveur DNS dans le cas où l’adresse IP est dynamique.

vivien · « **Réponse #16 le:** **Aujourd'hui** à 08:45:24 »

1.6/ Partage d’IPv4, adresses IP fixes ou dynamiques

Certains usages avancés sont incompatibles avec une ou plusieurs technologies de partage d’IP entre plusieurs clients. De même certains usages peuvent nécessiter une IPv4 publique fixe ou un préfixe IPv6 fixe.

Le tableau ci-dessous récapitule la présence d’un éventuel partage d’adresse IP, le mécanisme de partage d’une IPv4 publique mis en œuvre et la stabilité de l’IPv4 et du préfixe IPv6.

1.7/ Activation d’IPv6 et Pare-feu IPv6

La taille du préfixe IPv6 conditionne la possibilité de déléguer un préfixe (64 bits habituellement) sur un autre réseau pour des usages avancés.

Le tableau ci-dessous récapitule les principaux paramètres IPv6 par technologie d’accès.

vivien · « **Réponse #17 le:** **Aujourd'hui** à 08:45:39 »

Annexe 2/ Données complémentaires sur les opérateurs grand public ayant moins de 3 millions de clients

2.1/ Réseau fixe

2.2/ Réseau mobile

vivien · « **Réponse #18 le:** **Aujourd'hui** à 08:45:53 »

2.3/ Possibilité d’accéder à distance à des données hébergées derrière la box

vivien · « **Réponse #19 le:** **Aujourd'hui** à 08:46:06 »

2.4/ Partage d’IPv4, adresses IP fixes ou dynamiques

2.5/ Activation d’IPv6 et Pare-feu IPv6

vivien · « **Réponse #20 le:** **Aujourd'hui** à 08:46:20 »

Annexe 3/ Panorama des technologies accompagnant la transition vers IPv6

Cette annexe détaille les différentes solutions techniques qu’il est possible de mettre en œuvre, sur un réseau fixe et un réseau mobile.

Annexe 3.1/ Cohabitation des protocoles IPv4 et IPv6 (dual-stack)

IPv6 n’est pas nativement rétrocompatible avec IPv4, les opérateurs et les entreprises peuvent aujourd’hui mettre en place un réseau IPv4 et IPv6 (double pile) ou un réseau uniquement IPv6 avec des technologies de traduction ou encapsulation pour proposer une compatibilité avec l’IPv4.

Voici un tableau récapitulant les avantages de chaque technologie :

	Double pile (dual-stack)	IPv6-only
Mise en œuvre	Simple : permet de ne pas toucher à l’existant IPv4	Nécessite un travail d’ingénierie plus important et peut nécessiter des box internet avec des fonctions spécifiques pour fournir une connectivité IPv4
Accès IPv4 / IPv6	Accès à la fois à IPv4 et à IPv6, permettant une migration en douceur	Pas d’accès en IPv4 : des mécanismes de traduction d’adresses ou d’encapsulation sont nécessaires pour accéder aux ressources IPv4-only
Configuration	Nécessite de configurer à la fois IPv4 et IPv6	Configuration plus simple et possibilité de mis en œuvre de nouvelles technologies agiles comme SRv6
Sécurité	Définition des règles des IPS / IDS doublées	Une seule configuration de sécurité

Pour permettre à un réseau « IPv6 only » d’offrir une connectivité IPv4, plusieurs solutions sont envisageables.

• Pour le réseau fixe, les opérateurs utilisent par exemple du tunneling : un paquet IPv4 est encapsulé à l’intérieur d’un paquet IPv6. C’est comme mettre une lettre écrite en IPv4 dans une enveloppe adressée en IPv6 pour faire traverser à un flux IPv4 un réseau qui ne gère plus IPv4. L’inverse est également possible pour faire traverser à un flux IPv6 un réseau qui ne gère pas encore IPv6. L’annexe 3.2 liste les technologies disponibles.

• Pour le réseau mobile, les opérateurs utilisent la translation (NAT64 / DNS64) : un équipement réseau (souvent chez votre fournisseur d’accès) fait office de traducteur en temps réel. Il convertit les paquets IPv6 en IPv4 (et réciproquement) pour permettre l’établissement d’une communication entre terminaux et serveurs non compatibles. L’annexe 3.3 explique le fonctionnement.

vivien · « **Réponse #21 le:** **Aujourd'hui** à 08:46:33 »

Annexe 3.2/ Réseau fixe : Les solutions pour fournir une connectivité IPv4 derrière une box connectée à un réseau IPv6-only (IPv4 as a Service)

Avec les technologies IPv4 as a service, le réseau transporte de l’IPv6 pur (il n’y a plus de paquets IPv4 sur le réseau de transport) tout en permettant d’accéder aux services en IPv4.

Technologie	Type de mécanisme	RFC	État dans le réseau opérateur	Localisation du NAT44 / NAPT	Usage Typique
DS-Lite	Encapsulation 4‑en‑6 + CGN	RFC 6333	Stateful	Carrier-grade NAT dans le cœur de réseau	En France : Orange sur le fixe
Lightweight 4over6	Encapsulation 4‑en‑6 + A+P	RFC 7596	État par abonné	Box internet	Évolution de DS-Lite
MAP-E	Encapsulation 4‑en‑6 stateless	RFC 7597	Stateless	Box internet	En France : Free sur le fixe
MAP-T	Double traduction 4‑6‑4 stateless	RFC 7599	Stateless	Box internet	En France : Bouygues Telecom sur le fixe
4rd	Encapsulation ou traduction stateless	RFC 7600	Stateless	Box internet	Protocole historique, moins déployé

Voici le descriptif de ces technologies utilisées par les fournisseurs d’accès à internet pour un réseau fixe, avec des box déployées chez les clients.

3.2.1/ DS-Lite (Dual-Stack Lite)

Le DS-Lite ne demande pas de fonctions complexes dans la box internet. Cette dernière prend tout le trafic IPv4 local, l’encapsule dans de l’IPv6 et l’envoie à un Carrier-grade NAT chez l’opérateur. Le Carrier-grade NAT doit maintenir l’état de chaque connexion IPv4 TCP / UDP de chaque abonné (un NAT44 classique est réalisé).
• Avantage : Compatibilité avec un très grand nombre de box.
• Inconvénients : Le Carrier-grade NAT dans le réseau est très gourmand en ressources (obligation de garder des journaux) et est un point unique de défaillance. Le Carrier-grade NAT bloque la possibilité d’ouvrir les flux entrants IPv4 non sollicités pour permettre un auto-hébergement IPv4. Le passage par la plateforme qui héberge le Carrier-grade NAT peut, dans certaines architectures, rajouter de la latence. Enfin, un en-tête IPv6 de 40 octets est ajouté à chaque paquet IPv4.

3.2.2/ Lightweight 4over6 (lw4o6)

Le Lightweight 4over6 garde l’architecture DS-Lite (tunnel IPv4 dans IPv6), mais on déplace la fonction NAT du cœur de réseau vers la box chez le client. Le routeur central ne fait plus que du routage de tunnels (stateless ou semi-stateless), il n’a plus besoin de suivre chaque connexion TCP. L’opérateur dit explicitement à chaque box : « Toi, tu as l’IP X et la plage de ports Y ».
• Cas d’usage : Idéal pour migrer une infrastructure DS-Lite existante vers quelque chose de plus léger, en réutilisant en grande partie l’architecture existante.
• Inconvénients : Le mapping (IP et ports) n’est pas algorithmique, mais provisionné. Un en-tête IPv6 de 40 octets est ajouté à chaque paquet IPv4.

3.2.3/ MAP-E (Mapping of Address and Port with Encapsulation)

Dans MAP-E, comme pour lw4o6, le NAT est sur la box du client. Mais ici, le cœur de réseau est totalement stateless. Il n’y a pas de table de correspondance chez l'opérateur. L’adresse IPv6 de la box contient mathématiquement (via un algorithme) l’adresse IPv4 et la plage de ports. Le routeur de bordure calcule simplement où envoyer le paquet en lisant l’adresse IP.
• Avantages : Stateless. Passage à l’échelle infinie (pas de mémoire requise côté opérateur par utilisateur). Très robuste. Deux abonnés peuvent échanger en IPv4 sans passer par un élément central. Permet d’ouvrir les flux entrants IPv4 non sollicités sur la plage de ports attribuée à la box, pour permettre un auto-hébergement IPv4 (en plus de IPv6 pour lequel tous les ports sont disponibles).
• Inconvénient : Un en-tête IPv6 de 40 octets est ajouté à chaque paquet IPv4.

3.2.4/ MAP-T (Mapping of Address and Port using Translation)

MAP-T est identique à MAP-E, sauf pour l’encapsulation qui est remplacée par une traduction : Au lieu d’enfermer le paquet IPv4 dans un paquet IPv6 (ce qui ajoute 40 octets), MAP-T remplace l'en-tête IPv4 par un en-tête IPv6 (NAT46). Le routeur de bordure re-traduit en IPv4 vers Internet (NAT64).
• Avantages : Identiques à MAP-E, avec en plus l’absence de double en-tête IP pour les paquets IPv4.
• Inconvénients : Perte de certaines informations de l’en-tête IPv4 original (checksums à recalculer, options IPv4 perdues, ce qui peut compliquer le traitement de certains champs tel que la fragmentation, géré différemment dans l’en-tête IPv6). C’est techniquement plus complexe à implémenter correctement pour ne rien casser.

3.2.5/ 4rd (IPv4 Residual Deployment)

4rd était une technologie expérimentale, créée par un ingénieur français Rémi Després, qui a été déployé essentiellement par le fournisseur d’accès à internet français Free. Les concepts de 4rd ont essentiellement été absorbés et finalisés avec MAP-E et MAP-T. Il n’y a plus de nouveaux déploiements de 4rd et Free a basculé son infrastructure réseau sur MAP-E.

vivien · « **Réponse #22 le:** **Aujourd'hui** à 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.

vivien · « **Réponse #23 le:** **Aujourd'hui** à 08:47:37 »

3.3.3/ Fonctionnement du 464XLAT

Le 464XLAT consiste à introduire le CLAT (partie cliente du NAT) dans le système d’exploitation du client, pour que les applications disposent en apparence d’une adresse IPv4 privée fonctionnelle alors que le terminal n’est connecté qu’à un réseau IPv6-only.

Les IPv4 utilisées côté smartphone appartiennent généralement à la petite plage 192.0.0.0/29, ce sont les mêmes IP pour chaque terminal. Le CLAT va traduire algorithmiquement les IPv4 en IPv6 pour le flux sortant, comme le ferait le DNS64 en utilisant le préfixe réservé 64:ff9b::/96 ou un autre préfixe découvert via une requête DNS vers un nom de domaine particulier : « ipv4only.arpa » (voir RFC 8683). Dans tous les cas, les 32 derniers bits sont les 32 bits de l’adresse du site en IPv4.

Côté opérateur, c’est le PLAT, la plateforme NAT64, qui récupère l’IPv4 de destination dans l’IPv6 destination qu’il a reçue, afin de former l’IPv4 destination, envoyé sur l’internet IPv4.

3.3.4/ Différence entre l’IPv4 publique du DNS64 et celle du 464XLAT sous Android

De nombreux mobiles Android utilisent une IPv6 source pour le CLAT différente de l’IPv6 source utilisée pour les flux qui partent directement sur internet. La plateforme NAT64 de l’opérateur va attribuer une adresse IPv4 source différente aux flux provenant de deux IPv6 source distinctes. Il en résulte que l’IPv4 source utilisée par le NAT64 pour un même mobile est différente si la requête est réalisée via le DNS64 ou via le CLAT.