Le taux de connexion IPv6 de Google atteint 50 %

 (blog.apnic.net)
2 points par GN⁺ 4 시간 전 | 2 commentaires | Partager sur WhatsApp
  • Le 23 avril 2026, les statistiques IPv6 de Google ont atteint 50 % pour la première fois, marquant l’entrée dans une phase où la moitié des accès aux services Google se font en IPv6
  • Le même jour, l’IPv6 capability mondiale mesurée par APNIC Labs était de 42 %, ce qui signifie qu’il faut lire ces deux chiffres en tenant compte des différences de méthode de mesure et de modèle de pondération
  • APNIC ne se contente pas d’additionner les données de mesure issues de Google Ads, mais applique une pondération qui reflète la taille de la population d’internautes de chaque économie
  • Comme des économies telles que l’India, le Viet Nam ou la Saudi Arabia présentent des courbes d’adoption très différentes, la seule moyenne mondiale ne suffit pas à décrire la réalité régionale
  • IPv6 fait désormais partie de l’exploitation quotidienne d’Internet, sur les réseaux fixes, mobiles, les terminaux personnels et les services de datacenter

Le cap des 50 % dans les statistiques IPv6 de Google

  • Les statistiques IPv6 de Google ont atteint 50 % pour la première fois le 23 avril 2026
    • Cette statistique reflète la proportion d’utilisateurs accédant aux services Google via IPv6
    • Il s’agit d’un indicateur qui observe en continu la capacité de connexion IPv6 des utilisateurs de Google
  • Atteinte de 50 % d’IPv6 : {p:50}
  • Ce chiffre peut être vu comme une étape montrant qu’IPv6 est devenu un protocole mature utilisé sur les réseaux réels à l’échelle mondiale

Des écarts régionaux invisibles dans la seule moyenne mondiale

  • L’adoption d’IPv6 varie fortement selon les régions et les économies, au point qu’il est difficile de juger la situation avec une seule courbe de tendance mondiale
  • Google ne publie pas de statistiques IPv6 par région, et limite aussi les données par économie à des totaux agrégés
  • Dans les données d’APNIC Labs, les courbes d’adoption par économie peuvent différer fortement de la moyenne mondiale

Les mesures d’APNIC Labs sont à 42 %

  • La mesure propre à APNIC enregistre une IPv6 capability mondiale de 42 % au 23 avril 2026
    • Mesure mondiale APNIC Labs : Source
  • IPv6 capability d’APNIC : {p:42}
  • Il existe un écart net entre les 50 % de Google et les 42 % d’APNIC
  • Au niveau des économies prises individuellement, les mesures d’APNIC Labs concordent globalement avec les données de Google, Cloudflare, Akamai, Cisco et d’autres
  • La forte différence observée au niveau mondial pourrait venir moins de la mesure de base elle-même que des différences dans le modèle de pondération d’APNIC
  • En pratique, les mesures d’APNIC tendent à être plus basses que celles de Google
  • En regardant les deux jeux de données ensemble, on peut les interpréter comme un encadrement de la plage réelle de l’IPv6 capability à un moment donné

La méthode de mesure publicitaire d’APNIC

  • Le programme de mesure d’APNIC est exploité par APNIC Labs et utilise des publicités en ligne diffusées via Google Ads vers des navigateurs web, jeux et applications d’utilisateurs finaux
  • Il ne cherche pas à sélectionner des utilisateurs précis, mais vise une exposition aussi large que possible, 24/7, dans toutes les économies
  • Il combine les systèmes classiques de suivi publicitaire avec la logique d’APNIC Labs afin d’exécuter un ensemble de tests spécifique
    • Il mesure l’IP, le routage BGP, le DNS et d’autres choix techniques
  • Les données personnelles identifiables (PII) des utilisateurs finaux ne sont pas conservées
  • Les mesures brutes ne sont pas partagées, et seules des agrégations au niveau des ISP, des économies et des régions sont publiées
  • Ce travail de mesure est financé et soutenu par Google Research, l’ICANN et d’autres organisations

Pourquoi les échantillons bruts ne sont pas additionnés tels quels

  • APNIC applique une pondération statistique aux données collectées et modélise l’usage d’Internet par économie à l’aide de sources externes comme les statistiques de la World Bank
  • Le nombre d’échantillons de mesure reçus chaque jour par APNIC Labs n’est pas uniforme
  • Comme la diffusion publicitaire de Google est optimisée pour maximiser le volume livré et les revenus, certaines économies peuvent produire davantage de publicités et donc davantage d’échantillons certains jours
    • Par exemple, lors de journées où la demande publicitaire est forte dans des économies nord-africaines comme l’Egypt ou la Tunisia, davantage de mesures peuvent être collectées dans ces zones
    • Le même jour, l’South America ou l’Asia peuvent fournir relativement moins d’échantillons
  • APNIC Labs n’additionne pas simplement les volumes d’échantillons bruts
    • Il agrège d’abord l’IPv6 capability mesurée pour chaque économie
    • Il applique ensuite une pondération selon le nombre estimé d’internautes dans cette économie
  • Des économies à forte population connectée comme l’India, la China, l’Indonesia et d’autres grandes économies pèsent donc davantage dans le résultat mondial, quel que soit le nombre brut d’échantillons observés un jour donné
  • L’objectif de cette approche est que la mesure finale reflète davantage l’usage mondial d’Internet que les schémas quotidiens de diffusion publicitaire

Pourquoi la transition vers IPv6 a pris du temps

  • Certains voient dans le temps nécessaire pour atteindre le cap des 50 % d’adoption d’IPv6 la preuve d’un échec systémique d’IPv6
  • Le déploiement d’IPv6 a demandé un effort technique important et de lourds investissements en capital
  • Les différences de progression selon les régions et les économies reflètent les arbitrages propres à chaque ISP et à chaque économie entre croissance du réseau, attentes des utilisateurs et réalités d’exploitation de l’infrastructure Internet
  • L’Internet mondial n’est pas une économie planifiée : il évolue par collaboration et coopération dans un cadre piloté par le marché
  • De nombreux fournisseurs avaient auparavant beaucoup investi dans IPv4 et ont cherché à maximiser le rendement de cet investissement
    • Ce faisant, ils ont construit des réseaux IPv4 durables et commercialement viables dans le périmètre de leurs services existants
  • Pour les nouveaux entrants, il a souvent été plus rationnel d’adopter IPv6 comme protocole par défaut
    • IPv6 peut réduire le coût total de possession (TCO)
    • Cette tendance est particulièrement marquée dans le mobile
    • Le Reliance Jio network en India est présenté comme un exemple de déploiement IPv6 à grande échelle

L’Internet actuel où IPv4 et IPv6 coexistent

  • Aujourd’hui, l’Internet mondial fonctionne dans deux mondes de protocoles
  • Il aurait sans doute été plus simple sur le plan logistique d’opérer avec un seul protocole, mais la réalité n’a pas suivi cette voie
  • L’Internet actuel mêle plusieurs formes de connectivité
    • connectivité IPv4 directe
    • IPv4 via NAT résidentiel ou Carrier-Grade NAT (CGNAT) opérateur
    • IPv6
  • La gestion de la traduction d’adresses via NAT n’est pas intrinsèquement moins complexe que la traduction de protocole, l’encapsulation d’IPv4 sur IPv6 ou d’autres mécanismes de transition et de proxy
  • Dire que « IPv4 is working fine » fait facilement oublier que les réseaux IPv4 modernes reposent déjà sur plusieurs couches de complexité opérationnelle
  • Il n’existe pas, avec IPv4 seul, d’approche intrinsèquement moins coûteuse ou plus simple

Où se situe réellement l’interopérabilité entre IPv4 et IPv6

  • L’absence d’interopérabilité directe entre IPv4 et IPv6 a été comprise dès le départ comme un problème à résoudre
  • Au début, des idées de protocole permettant d’englober IPv4 sans le modifier et de rendre possible une connexion directe entre les deux mondes ont été explorées, mais elles n’ont pas prouvé leur viabilité en pratique
  • L’interopérabilité se construit à une couche plus élevée, via des protocoles de transport comme TCP, UDP ou QUIC, qui fonctionnent indépendamment de la version d’IP
  • Ce modèle nécessite une forme ou une autre d’intermédiaire
  • On retrouve cette architecture dans la façon dont de grands fournisseurs de contenu et de cache comme Cloudflare proposent des services dual-stack, que leurs systèmes backend prennent ou non en charge les deux protocoles

Pourquoi certains services n’ont pas de dual-stack

  • Le fait que certains services ne disposent pas d’une capacité dual-stack native est souvent considéré comme un frein important aux progrès d’IPv6
  • Des exemples cités incluent une certaine plateforme Git ou un diffuseur TV national
  • Cette situation reflète moins une résistance à IPv6 qu’une complexité opérationnelle
  • Dans le cas d’un diffuseur national, des contraintes pratiques telles que les exigences légales et réglementaires liées à l’accès aux données et à la geolocation peuvent jouer un rôle

IPv6 fait désormais partie de l’exploitation quotidienne

  • IPv6 est maintenant déployé à l’échelle mondiale
  • Environ la moitié des internautes visibles par Google accèdent déjà aux services Google via IPv6
  • IPv6 est utilisé chaque jour, à chaque heure, dans les pays développés comme en développement, sur les réseaux fixes comme mobiles, et des petits appareils personnels aux grands services de datacenter
  • IPv6 n’est plus une technologie expérimentale ou marginale, mais une partie du fonctionnement quotidien d’Internet

À lire aussi

2 commentaires

 
purely4959 4 시간 전

Quand l’IPv6 sera-t-il adopté pour l’internet résidentiel en Corée du Sud ?
 
GN⁺ 4 시간 전
Commentaires sur Hacker News

  • Pour ajouter un exemple de plus au cas du « les ISP ne le font toujours pas », Virgin Media, un grand ISP britannique, avait publiquement déclaré lors du World IPv6 Day en 2011 qu’il prendrait totalement en charge IPv6 d’ici fin 2012, mais 15 ans plus tard, ils n’ont toujours pas réussi à actionner l’interrupteur
    https://havevirginmediaenabledipv6yet.co.uk/
    Annonce de l’époque : https://ispreview.co.uk/story/2011/06/08/uk-isp-fluidata-hai...

    • La manière de faire pression sur un ISP pour qu’il prenne en charge IPv6 est stupide, mais peut être efficace. Il suffit qu’un site de comparaison d’offres affiche un gros avertissement rouge sur les ISP sans prise en charge IPv6, et que les sites web montrent aussi une bannière disant « votre ISP ne prend pas en charge la connexion Internet normale utilisée par ce site »
      Les consommateurs ne savent peut-être pas ce qu’est IPv6, mais ils comprennent un gros avertissement rouge et une bannière agaçante
    • J’ai déjà demandé à Virgin Media s’il était possible d’activer IPv6 sur une ligne 1Gb DIA, et on m’a répondu : « nous pouvons basculer la ligne vers IPv6, mais il faudra abandonner IPv4 »
      Après ça, je n’ai plus eu envie de reposer la question
    • D’un point de vue purement business, VM n’a pas vraiment de raison de le faire. Ils ont assez d’adresses IPv4, et à part une toute petite base d’utilisateurs techniques, les clients ne ressentent pas les avantages d’IPv6
      En ajoutant à cela les cas où les implémentations IPv6 d’autres ISP cassent aléatoirement certaines choses, on peut aussi comprendre pourquoi ils ne le font pas
    • Aux Pays-Bas, il existe des sites comme https://heeftodidoipv6.nl
      Cet ISP a bien de l’IPv6 dans son réseau cœur, mais ne le fournit pas à ses clients, alors même qu’il représente 17 % du marché télécom néerlandais
    • Aux États-Unis, ça se rapproche enfin. Les principaux ASN ont un taux d’activation IPv6 supérieur à 75 %
      Mais Optimum Communications et Frontier tirent fortement les chiffres vers le bas avec chacun autour de 15 %, et même si Frontier progresse très lentement, il y a peu de preuves de changement du côté d’Optimum

  • Il y a aussi eu un fil de 626 commentaires il y a deux mois : https://news.ycombinator.com/item?id=47777894

  • En essayant de mettre en place un serveur en IPv6 « pur », j’ai été surpris de voir que GitHub ne prend pas IPv6 en charge. Sans les opérateurs volontaires de NAT64 listés sur https://nat64.xyz/, il est impossible d’atteindre GitHub depuis un environnement IPv6

    • L’absence de prise en charge IPv6 chez GitHub est totalement impardonnable
    • Internet contourne encore une fois le problème. C’est un bon exemple du fait que, même dans les années 2020, il n’existe en pratique non pas plusieurs Internets, mais un seul Internet

  • Non, mon sous-réseau IPv4 en /22 est comme un 401k personnel, je dois m’en servir pour ma retraite

    • Dit comme une blague, mais c’est exactement ainsi que la société considère aussi le logement
    • Le moment est peut-être venu de le monétiser ?
    • Vers 2100, ça risque vraiment de devenir compliqué

  • T-Mobile/Odido aux Pays-Bas promet depuis des années qu’ils sont en train d’y travailler, mais ne prend toujours pas en charge IPv6
    Le support semble aussi un peu décevant du côté des passerelles Ubiquiti, et ce serait bien qu’elles prennent en charge des fonctions comme le tunneling Hurricane Electric

    • Ici, via une passerelle Ubiquiti, l’accès à l’adresse IPv6 2606:7100:1:67::26 de news.ycombinator.com fonctionne bien
    • Les plages d’adresses de tunnel HE subissent désormais des désavantages assez marqués pour les adresses non résidentielles / non professionnelles, si bien que j’ai fini par les désactiver
      Par exemple, YouTube semble en général bloquer les utilisateurs non connectés provenant des plages HE, et je me suis aussi souvent retrouvé face à des CAPTCHA sans fin
    • Il est intéressant de noter qu’aux États-Unis, T-Mobile fait exactement l’inverse : ils ne prennent pas en charge IPv4, n’attribuent que de l’IPv6, puis fournissent un « faux NAT » pour IPv4 via 464XLAT
    • T-Mobile US est IPv6 only depuis environ 2018 : https://www.youtube.com/watch?v=d6oBCYHzrTA
    • Tous les ISP devraient payer le coût des tunnels Hurricane Electric, et ce serait donc gratuit pour les utilisateurs. Si suffisamment de gens se mettent à utiliser des tunnels HE, les ISP finiront par fournir de l’IPv6 natif
      Mais en pratique, on se fait facilement bloquer par les sites web visités, et c’est aussi difficile à utiliser si l’on est derrière un CGNAT ou si le routeur domestique n’a pas de DMZ

  • Je voudrais arrêter de payer les adresses IPv4 publiques à AWS, mais comme beaucoup de FAI côté clients ne le prennent pas en charge, une bascule complète vers IPv6 est impossible
    À l’heure actuelle, rien ne pousse les FAI à migrer vers IPv6, c’est même plutôt l’inverse. Les FAI aiment facturer les IP fixes

    • Pour être juste, si Google arrêtait la prise en charge d’IPv4, ce serait une incitation assez forte pour forcer les FAI à s’aligner

  • Si le ratio IPv6 augmente surtout le week-end, cela semble indiquer que les réseaux d’entreprise / professionnels repoussent encore l’implémentation

    • Le vrai jalon, c’est toujours le moment où l’on dépasse durablement les 50 %
    • On dit que c’est juste « par flemme », mais IPv6 n’est pas le genre de chose qu’on active en cochant une case
      Pourquoi faudrait-il réorganiser l’organisation et faire toutes sortes de travaux juste pour changer quelques chiffres ? Si IPv4 fonctionne, pourquoi faire ?

  • Le fait que l’IPv6 de Google ait atteint 50 % est une très bonne chose du point de vue de l’accès aux sites web
    Mais mon routeur TP-Link bloque par défaut les connexions IPv6 entrantes, sans option de configuration, donc ce n’est toujours pas idéal pour le streaming bidirectionnel en IPv6 pur, le jeu, ou les services de réseau domestique

    • En installant OpenWRT dessus, on peut faire ce qu’on veut. On découvre alors la joie d’ajouter des règles d’accès IPv6 pour à peu près les mêmes ports, au lieu des règles de redirection de ports d’IPv4
    • J’auto-héberge le web et le mail via un VPN WireGuard sur un VPS gratuit. Je l’ai fait gratuitement sur OCI, et c’était aussi possible à bas coût sur AWS Lightsail
      On peut aussi utiliser une solution facile à configurer comme Tailscale, et de cette façon on n’expose pas directement son réseau domestique à Internet
    • Les fabricants de routeurs grand public sont globalement tous médiocres, donc l’écart n’est pas énorme, mais TP-Link est vraiment mauvais. Je recommande fortement de ne pas utiliser ce matériel
    • Ces systèmes reflètent l’époque où ils ont été conçus. IPv6 est une technologie vieille de 30 ans, et nombre des menaces actuelles n’existaient pas à l’époque
      Par exemple, la décision de prendre par défaut un bloc /64 venait de l’idée qu’on utiliserait en partie des adresses MAC 48 bits, mais on sait aujourd’hui que c’est un cauchemar pour la vie privée, donc plus personne ne fait ça. Malgré cela, on reste encore liés au schéma d’adressage 128 bits qui en est issu
      IPv6 devait remplacer le NAT par une quantité suffisante d’adresses, mais cela a eu un effet intéressant : un problème d’expression de l’intention. Avec le NAT, lorsqu’un service sur un ordinateur demande un port pour des connexions entrantes, l’intention du propriétaire du service est explicite ; IPv6 n’a pas ce signal d’intention. Les fabricants de routeurs domestiques n’ont donc d’autre choix que de bloquer les adresses par défaut, sinon un scan externe du PC pourrait exposer sur l’Internet public des services non prévus à cet effet
      Un espace d’adressage plus vaste est peut-être techniquement meilleur, mais il faut aussi tenir compte des valeurs par défaut et de l’intention de l’utilisateur. Une bonne solution technique peut, à ce niveau, devenir une mauvaise solution ou créer une multitude de problèmes

  • Chez Cloudflare, IPv6 semble être à plus de 40 %, mais malgré la croissance du trafic total, cela n’a pas beaucoup progressé au cours de l’année écoulée. Comme l’observe l’article d’APNIC, le taux réel d’adoption global se situe probablement quelque part entre Google et Cloudflare
    https://radar.cloudflare.com/adoption-and-usage#ipv4-vs-ipv6
    Cela reflète toutefois le taux d’adoption côté client. Même parmi les services connus, beaucoup restent encore uniquement en IPv4, donc la part réelle d’IPv6 sur l’Internet public pourrait être bien plus faible
    Maintenant que les nouvelles allocations IPv4 sont épuisées depuis longtemps, il semble qu’il faille une nouvelle incitation à la transition différente de celle d’autrefois

    • Si l’on regarde la part du trafic, la plupart des grands services gourmands en bande passante — les sites de streaming vidéo et les CDN — fonctionnent déjà majoritairement sur IPv6. Les services de longue traîne encore limités à IPv4 consomment généralement moins de bande passante
    • De nos jours, la limitation de débit peut constituer une forte contre-incitation. En IPv4, le blocage par plage reste relativement efficace, mais en IPv6 il l’est beaucoup moins
      C’est aussi pour cela que HE Tunnelbroker a mauvaise réputation aujourd’hui. Des bots musicaux Discord répartissaient la charge entre des IP de tunnelbroker pour récupérer les données audio de YouTube, et même en bloquant un /64, il était possible de contourner via du /48 ou plus large. J’ai aussi l’impression que la principale raison pour laquelle Discord avait désactivé IPv6 tenait au blocage basé sur l’IP et à la limitation de débit de l’API

  • Les ratios par pays sont intéressants. La France semble être montée à 85 %
    https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

    • Plus la part du trafic mobile est élevée, plus le ratio IPv6 augmente. Quand on regarde l’Inde, tout le monde n’utilise manifestement pas une fibre où tout passe en IPv6
    • Je me demande d’où vient le signal haute fréquence superposé à la tendance de long terme sur ce graphique
      https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
    • Le fait que l’Inde soit à 75 % est vraiment une excellente nouvelle. Sinon, la pression sur le prix des adresses IPv4 serait devenue absurde