Utilisation de DNS pour estimer l'état mondial de l'adoption d'IPv6

Pour qu'un appareil puisse communiquer avec d'autres appareils sur Internet via le protocole Internet Protocol (IP), il doit d'abord recevoir une adresse numérique unique. La forme de cette adresse dépend de la version d'IP utilisée : IPv4 ou IPv6.

IPv4 a été déployé pour la première fois en 1983. C'est cette version d'IP qui a donné naissance à l'Internet moderne, et qui reste encore dominante aujourd'hui. IPv6 remonte à 1998 ; toutefois, ce n'est qu'au cours de la dernière décennie que ce protocole a commencé à gagner du terrain, progressant d'un taux de moins de 1 % pour atteindre un taux compris entre 30 et 40 %, selon les auteurs des rapports, ainsi que les données mesurées et les méthodes employées.

Face à la croissance du nombre d'appareils connectés, qui dépasse de loin le nombre d'adresses IPv4 disponibles, et à l'augmentation des coûts liés à ce protocole, l'espace d'adressage beaucoup plus vaste fourni par IPv6 devrait permettre à ce dernier de s'imposer comme le protocole dominant à l'heure actuelle. Toutefois, comme nous le verrons, ce n'est pas le cas.

Cloudflare est un fervent défenseur d'IPv6 depuis de nombreuses années et, grâce à Cloudflare Radar, nous suivons de près l'adoption d'IPv6 à l'échelle d'Internet. gée de trois ans, Cloudflare Radar est encore une plateforme relativement récente. Pour remonter plus loin dans le temps, nous pouvons brièvement nous tourner vers nos amis d'APNIC1, l'un des cinq registres Internet régionaux (RIR). Leurs données, qui remontent jusqu'à 2012, nous permettent d'observer qu'IPv6 a connu une période de croissance apparemment exponentielle jusqu'à mi-2017, après quoi le protocole est entré dans une période de croissance linéaire qui perdure aujourd'hui :

L'adoption d'IPv6 est ralentie par l'absence de compatibilité entre les deux protocoles (les appareils doivent recevoir à la fois une adresse IPv4 et une adresse IPv6), ainsi que par le fait que la quasi-totalité des appareils connectés à Internet prend encore en charge IPv4. Néanmoins, le protocole IPv6 est essentiel à l'avenir d'Internet, et des efforts continus sont nécessaires pour accroître son déploiement.

Cloudflare Radar, à l'instar d'APNIC et de la plupart des autres sources aujourd'hui, publie des chiffres qui reflètent principalement la mesure dans laquelle les fournisseurs d'accès Internet (FAI) ont déployé IPv6 : le côté client. C'est une perspective très importante, qui concerne directement les utilisateurs finaux. Cependant, il existe également l'autre côté de l'équation : le côté serveur.

En gardant cela à l'esprit, nous vous invitons à nous suivre lors d'une brève expérience pendant laquelle nous allons essayer d'obtenir un aperçu de l'adoption d'IPv6 côté serveur, ainsi que de la fréquence à laquelle les clients sont réellement capables (ou susceptibles) de communiquer avec des serveurs via IPv6. Aux fins de cette exploration, nous utiliserons DNS – et, comme disent certains, les résultats pourraient vous surprendre !

À la fin du mois d'octobre 2023, du point de vue de Cloudflare, l'adoption d'IPv6 à l'échelle d'Internet représentait environ 36 % de l'ensemble du trafic, avec de légères variations en fonction de l'heure de la journée et du jour de la semaine. Si l'on exclut les bots, l'estimation s'élève à un peu plus de 46 %, tandis que si l'on exclut le trafic humain, cette estimation chute à près de 24 %. Ces chiffres font référence à la part de requêtes HTTP servies via IPv6 sur l'ensemble des contenus compatibles IPv6 (c'est-à-dire le paramètre par défaut).

Aux fins de cet exercice, ce qui importe le plus est le chiffre correspondant aux humains et aux bots. Il existe de nombreuses raisons expliquant l'écart d'adoption entre les deux types de trafic, des différents niveaux de prise en charge d'IPv6 au sein de la myriade de logiciels client utilisés aux différents niveaux de déploiement d'IPv6 sur les nombreux réseaux d'où provient le trafic, en passant par l'étendue variable de ces réseaux, etc. Toutefois, c'est un vaste domaine que nous examinerons un autre jour. Si vous êtes curieux de connaître les chiffres d'un pays ou d'un réseau en particulier, vous pouvez les trouver sur Cloudflare Radar et dans notre rapport Year in Review pour l'année 2023.

Vous, lecteur, pourriez remarquer que la mesure du côté client de l'équation client-serveur ne raconte qu'une facette de l'histoire : pour qu'un client compatible IPv6 puisse établir une connexion à un serveur via IPv6, le serveur doit également être compatible IPv6.

Cela soulève deux questions :

1. Quel est le degré d'adoption du protocole IPv6 côté serveur ?

2. Dans quelle mesure l'adoption d'IPv6 côté client correspond-elle à l'adoption côté serveur ?

Il existe plusieurs réponses possibles, selon qu'il s'agit d'utilisateurs, d'appareils, d'octets transférés, etc. Nous allons nous concentrer sur les connexions (nous verrons pourquoi dans un instant), et la question combinée que nous posons est la suivante :

À quelle fréquence un client compatible IPv6 peut-il utiliser IPv6 lorsqu'il se connecte à des serveurs sur Internet, dans le cadre de modèles d'utilisation habituels ?

Les modèles d'utilisation habituels incluent les personnes qui vaquent à leurs occupations quotidiennes, en consultant plus fréquemment certains sites web que d'autres, ou des appels d'API par des clients automatisés. Nous allons nous intéresser à DNS pour avoir cette perspective.

Avant qu'un client puisse tenter d'établir une connexion à un serveur par son nom, en utilisant soit le protocole IPv4 classique, soit le protocole IPv6, plus moderne, il doit rechercher l'adresse IP du serveur dans le répertoire d'Internet, le système de noms de domaine (DNS).

La recherche d'un nom d'hôte dans DNS est un processus récursif. Pour trouver l'adresse IP d'un serveur, la hiérarchie de domaine (c'est-à-dire les composants séparés par des points du nom d'un serveur) doit être suivie sur plusieurs serveurs DNS de référence, jusqu'à ce que l'un d'entre eux renvoie la réponse souhaitée. La plupart des clients, cependant, ne le font pas directement, et demandent plutôt à un serveur intermédiaire appelé résolveur récursif de le faire à leur place. Cloudflare gère l'un de ces résolveurs récursifs, accessible à tous les utilisateurs d'Internet 1.1.1.1.

Pour simplifier, lorsqu'un client demande à 1.1.1.1 l'adresse IP où réside « www.example.com », 1.1.1.1 va interroger les serveurs racine DNS sur « .com », puis interroger les serveurs DNS .com3 sur « example.com » ; enfin, il va interroger les serveurs DNS d'example.com sur « www.example.com », qui en a une connaissance directe et répond avec une adresse IP. Pour accélérer la recherche pour le prochain client qui pose une question similaire, 1.1.1.1 met en cache (c'est-à-dire, mémorise pendant un certain temps) la réponse finale et les étapes intermédiaires.

Cela signifie que 1.1.1.1 est idéalement positionné pour compter la fréquence à laquelle les clients essaient de rechercher des adresses IPv4 (requêtes de type A) par rapport à la fréquence à laquelle ils essaient de rechercher des adresses IPv6 (requêtes de type AAAA), couvrant la majeure partie de l'Internet observable.

Mais comment un client sait-il quand demander l'adresse IPv4 ou l'adresse IPv6 d'un serveur ?

Pour répondre de manière concise, les clients disposant d'IPv6 demandent simplement les deux adresses, en effectuant des recherches https://www.cloudflare.com/learning/dns/dns-records/dns-a-record/A et AAAA distinctes pour chaque serveur auxquels ils souhaitent se connecter. Ces clients compatibles IPv6 prioriseront la connexion sur IPv6 lorsqu'ils recevront une réponse AAAA non vide, qu'ils reçoivent ou non également une réponse A non vide (qu'ils reçoivent presque toujours, comme nous le verrons). L'algorithme à l'origine de cette préférence pour la modernité est appelé Happy Eyeballs, si ces détails vous intéressent.

Nous sommes maintenant prêts à commencer à examiner des données réelles...

La première étape consiste à établir une base de référence en mesurant le déploiement d'IPv6 côté client du point de vue de 1.1.1.1, puis en comparant celui-ci avec les chiffres correspondant aux requêtes HTTP avec lesquels nous avons commencé.

Il est tentant de compter la fréquence à laquelle les clients se connectent à 1.1.1.1 via IPv6, mais les résultats sont trompeurs pour plusieurs raisons, la plus importante étant cachée à la vue de tous : 1.1.1.1 est l'adresse la plus mémorable de l'ensemble d'adresses IPv4 et IPv6 que les clients peuvent utiliser pour effectuer des recherches DNS via le service 1.1.1.1. Idéalement, les quatre adresses IP suivantes (et pas seulement les deux premières) devraient être configurées sur les clients compatibles IPv6 qui utilisent 1.1.1.1 en tant que résolveur récursif :

• 1.1.1.1 (IPv4)

• 1.0.0.1 (IPv4)

• 2606:4700:4700::1111 (IPv6)

• 2606:4700:4700::1001 (IPv6)

Cependant, lorsqu'une configuration manuelle est requisesup>4, les humains trouvent que les adresses IPv6 sont moins faciles à mémoriser que les adresses IPv4 et ils sont moins enclins à les configurer, considérant que les adresses IPv4 sont suffisantes.

Un facteur de confusion connexe, mais moins évident, est que de nombreux clients compatibles IPv6 effectueront toujours des recherches DNS sur IPv4, même lorsque les adresses IPv6 de 1.1.1.1 ont été configurées, car la répartition des recherches sur les adresses disponibles est une option par défaut courante.

Une approche plus judicieuse pour évaluer l'adoption d'IPv6 à partir de l'activité du client DNS consiste à calculer le pourcentage de requêtes de type AAAA par rapport au nombre total de requêtes de type A, en partant du principe que les clients IPv6 exécutent toujours ces deux requêtes5, comme nous l'avons mentionné plus haut.

Ensuite, du point de vue de 1.1.1.1, l'adoption d'IPv6 côté client est estimée à 30,5 % en volume de requêtes. Cette valeur est un peu inférieure à celle que nous avons observée sur le trafic HTTP durant la même période (35,9 %), mais une telle différence entre deux perspectives différentes n'est pas inattendue.

Il n'y a pas que les résolveurs récursifs qui mettent en cache les réponses DNS ; la plupart des clients DNS disposent également de leurs propres caches locaux. Votre navigateur web, votre système d'exploitation et même votre routeur domestique conservent les réponses avec l'objectif d'accélérer les requêtes ultérieures.

La durée de conservation de chaque réponse dépend du champ time-to-live (TTL, durée de vie) renvoyé avec les enregistrements DNS. Si vous êtes familier avec DNS, vous vous demandez peut-être si les TTL des enregistrements A et AAAA sont similaires. Si ce n'est pas le cas, nous risquons de recevoir moins de requêtes pour l'un de ces deux types (car il est mis en cache plus longtemps au niveau du client), ce qui fausse les chiffres d'adoption résultants.

Les graphiques à secteurs présentés ici détaillent les TTL minimaux renvoyés par 1.1.1.1 en réponse à des requêtes A et AAAA6. On observe un écart entre les deux types, mais la différence est très réduite.

Le graphique suivant montre la fréquence à laquelle les requêtes de type A et AAAA reçoivent des réponses non vides, ce qui met en lumière l'adoption d'IPv6 côté serveur et nous rapproche de la réponse que nous recherchons :

L'adoption d'IPv6 par les serveurs est estimée à 43,3 % en volume de requêtes, soit une valeur nettement supérieure à celle observée côté client.

Si 30,5 % des recherches d'adresses IP gérées par 1.1.1.1 peuvent utiliser une adresse IPv6 pour se connecter à leurs destinations prévues, mais seulement 43,3 % de ces recherches reçoivent une réponse non vide, cela peut nous fournir une indication assez pertinente de la fréquence à laquelle les connexions IPv6 sont établies entre le client et le serveur – environ 13,2 % du temps.

L'adoption d'IPv6 côté serveur, mesurée en fonction du volume de requêtes, pour les domaines figurant dans la liste Top 100 de Cloudflare Radar est de 60,8 %. Si nous excluons ces domaines de nos calculs globaux, le chiffre précédent de 13,2 % tombe à 8 %. Il s'agit d'une différence significative, mais pas inattendue, car les domaines de la liste Top 100 représentent plus de 55 % de la totalité des requêtes de type A et AAAA, selon 1.1.1.1 .

Si quelques-uns seulement de ces domaines très populaires déployaient IPv6 aujourd'hui, l'adoption observée augmenterait sensiblement et, avec elle, la probabilité que les clients compatibles IPv6 utilisent ce protocole pour établir des connexions.

L'observation de l'étendue de l'adoption d'IPv6 sur Internet peut avoir différentes implications :

• Permettre un comptage des utilisateurs disposant d'un accès Internet compatible IPv6 ;

• Permettre un comptage des équipements compatibles IPv6 ou des logiciels sur ces périphériques (client et/ou serveurs) ;

• Calculer la quantité de trafic transitant via les connexions IPv6, mesurée en octets ;

• Compter la fraction de connexions (ou de requêtes individuelles) établies avec IPv6.

Aux fins de cet exercice, nous avons choisi d'examiner les connexions et les requêtes. En gardant à l'esprit que la réalité sous-jacente ne peut être réellement comprise qu'en prenant en compte plusieurs points de vue différents, nous avons observé trois chiffres différents concernant l'adoption d'IPv6 :

• 35,9 % (côté client) si l'on compte les requêtes HTTP servies depuis le réseau CDN de Cloudflare ;

• 30,5 % (côté client) si l'on compte les requêtes DNS de type A et AAAA traitées par 1.1.1.1https://one.one.one.one/dns/ ;

• 43,3 % (côté serveur) de réponses positives aux requêtes DNS de type AAAA, également traitées par 1.1.1.1.

Nous avons réuni les chiffres côté client et côté serveur du point de vue de DNS pour estimer la fréquence à laquelle les connexions à des serveurs tiers sont susceptibles d'être établies via IPv6 plutôt qu'IPv4 : seulement 13,2 % du temps.

Pour améliorer ces chiffres, les fournisseurs d'accès Internet, les fournisseurs de cloud et d'hébergement, ainsi que les entreprises doivent augmenter la vitesse à laquelle ils rendent le protocole IPv6 disponible pour les équipements connectés à leurs réseaux. Cependant, les grands sites web et sources de contenus ont également un rôle essentiel à jouer pour permettre aux clients compatibles avec IPv6 d'utiliser plus souvent ce protocole, car 39,2 % des requêtes correspondant aux domaines de la liste Top 100 de Cloudflare Radar (qui représentent plus de la moitié de la totalité des requêtes A et AAAA adressées à 1.1.1.1) sont encore limitées à des réponses IPv4 uniquement.

Sur la voie de l'adoption complète d'IPv6, l'Internet est encore loin de sa destination. Cependant, les efforts continus réalisés par toutes les parties concernées peuvent l'aider à continuer d'avancer, et peut-être même à accélérer le déroulement.

Côté serveur, Cloudflare contribue à cet effort mondial depuis de nombreuses années en offrant une prise en charge gratuite d'IPv6 pour tous les domaines. Côté client, l'application 1.1.1.1 active automatiquement votre appareil pour IPv6, même si votre fournisseur d'accès Internet ne propose pas la prise en charge d'IPv6. Et, si vous gérez un réseau IPv6 uniquement, la prise en charge de DNS64 par 1.1.1.1 vous couvre également.

***

¹Le résolveur DNS public de Cloudflare (1.1.1.1) est géré en partenariat avec APNIC. Pour plus d'informations à ce sujet, consultez l'article de blog consacré à l'annonce originale et la politique de confidentialité de 1.1.1.1.

²Vous trouverez plus d'informations sur le fonctionnement de DNS dans la section « Qu'est-ce que le DNS ? » de notre site web. Si vous préférez apprendre en pratiquant, nous vous invitons à jeter un coup d'œil à l'article « mess with dns » de Julia Evans.

³Un résolveur récursif connaîtra déjà à l'avance les adresses IP des 13 serveurs racine. Cloudflare participe également au plus haut niveau de DNS en fournissant le service Anycast aux instances E et F-Root, ce qui facilite cette première étape de recherche pour 1.1.1.1.

⁴Lorsque vous utilisez l'application 1.1.1.1, les quatre adresses IP sont configurées automatiquement.

⁵Pour simplifier, nous supposons que le nombre de clients IPv6 uniquement est encore négligeable. Il s'agit d'une hypothèse raisonnable en général, et les autres ensembles de données dont nous disposons le confirment.

⁶1.1.1.1, à l'image des autres résolveurs récursifs, renvoie des TTL ajustés : la durée de vie d'origine de l'enregistrement moins le nombre de secondes écoulées depuis la dernière mise en cache de l'enregistrement. Les réponses A et AAAA vides sont mises en cache pour la durée définie dans l'enregistrement Start of Authority (SOA) du domaine, conformément aux spécifications de la norme RFC 2308.