Il y a une histoire que l’industrie britannique raconte sur IPv6, et elle va comme ceci. Le passage est difficile. Le matériel est vieux. Les clients ne le demandent pas. Il n’y a pas d’argent dedans. Un jour, quand l’argument commercial tournera, on s’y mettra.

Chaque partie de ça est un mensonge que l’industrie se raconte pour ne pas avoir à faire de travail.

IPv6 a été spécifié en décembre 1995. J’y suis arrivé par le 6bone, le banc d’essai expérimental qui le portait avant que le vrai internet ne le veuille, et j’ai fait tourner la pile Linux et la pile de Microsoft Research sur Windows XP pour voir en quoi elles différaient. Mon accès venait de Hurricane Electric.

Le 6bone a été éteint le 6 juin 2006, alors je suis passé au tunnelage automatique 6to4, et plus tard à un tunnel Hurricane Electric — toujours gratuit, et ils vous routent un /48 sur demande. IPv6 natif est arrivé chez moi en 2017, quand j’ai changé de FAI pour Zen.

Donc pendant près de vingt ans mon IPv6 venait d’une entreprise de transit américaine qui le donnait, plutôt que d’aucun des FAI britanniques que je payais. Hurricane Electric distribuait des /48 routés à quiconque en voulait un. Mon propre fournisseur me vendrait une IPv4 statique pour cinq livres par mois.

Les dates disent le reste. L’IETF a tué le 6bone en 2006 et a déprécié les relais anycast de 6to4 en mai 2015, qualifiant le mécanisme d’« unsuitable for widespread deployment and use in the Internet » — inadapté au déploiement et à l’usage généralisés sur l’internet. J’ai survécu à deux mécanismes de transition officiels en attendant qu’un FAI britannique me remette une adresse. Le jour où le 6bone s’est éteint, trente-sept des quarante fournisseurs britanniques du graphique ci-dessous n’avaient pas encore demandé d’allocation au registre. Vingt-deux d’entre eux — plus de la moitié — n’ont pas demandé avant 2015 ou plus tard, l’année où l’IETF a aussi abandonné 6to4.

Il est allumé par défaut dans chaque système d’exploitation que quiconque fait tourner depuis Windows Vista en 2007. Il ne coûte rien de plus au registre. Le plus gros FAI qui ait jamais essayé dans ce pays a fini le travail en trois ans avec une équipe qui tiendrait dans une salle de réunion, et a gagné un prix pour ça.

Trente ans après la spécification. Quatorze ans après le jour où l’internet l’a allumé pour de bon. Et la réponse dans ce pays a été de casser l’internet exprès, d’emballer le morceau cassé dans plus de machinerie, et de facturer le client pour le désagrément.

Ce n’est pas un problème de coût. C’est un problème de flemme, et ça dure depuis vingt ans.

Ce que j’ai mesuré, et comment

Tout ce qui suit est soit le travail de quelqu’un d’autre, lié, soit un chiffre que j’ai produit moi-même. Là où c’est le mien, le script qui l’a compté est dans le téléchargement ci-dessous, exécuté tel que publié. La seule exception est les totaux d’adresses, et j’explique comment ceux-là sont calculés dans les réserves. Quatre sources publiques, toutes gratuites : les fichiers de délégation des registres, le vidage de la table de routage de RIPE, la base de données RIPE, et le DNS. Là où j’ai choisi un échantillon plutôt que de mesurer le tout, je le dis.

Les chiffres de routage viennent de deux jeux de fichiers publics.

Le premier est les fichiers de délégation, un par registre régional, qui listent chaque bloc d’adresses et numéro d’AS que ce registre a distribué, le pays où il est enregistré, et un identifiant opaque pour l’organisation qui le détient. Celui de RIPE couvre l’Europe et le Moyen-Orient, et c’est celui qui compte pour le Royaume-Uni — mais quelques dizaines de numéros d’AS enregistrés au Royaume-Uni siègent dans les fichiers ARIN et APNIC à la place, et la comparaison plus bas a besoin du tout. Les miens ont été générés les 26 et 27 août 2026.

Le second est le vidage de la table de routage mondiale du Routing Information Service de RIPE, qui liste chaque préfixe en BGP et le numéro d’AS qui l’annonce. IPv4 et IPv6 viennent en fichiers séparés. Le mien a été généré à 18 h 06 UTC le 27 août 2026.

Mettez-les ensemble et vous pouvez répondre à une question que personne dans l’industrie britannique ne veut voir posée tout haut : des réseaux que ce pays a enregistrés, combien ont réellement allumé IPv6 ?

Les scripts, prêts à l'emploi ipv6-uk-2026-scripts.zip · 10 kB

Sortez les numéros d’AS enregistrés à GB des fichiers de délégation, sortez chaque numéro d’AS originant un préfixe des vidages RIS, et faites un comm des deux listes l’une contre l’autre par famille d’adresses. Ça donne la première table ci-dessous. Un piège qui vaut d’être nommé : triez lexicalement, pas avec sort -n. comm compare des chaînes, et une entrée triée numériquement vous donne silencieusement la mauvaise réponse plutôt qu’une erreur que vous remarqueriez.

Échangez GB contre tout autre code de pays et vous obtenez la ligne de ce pays dans la table de comparaison plus bas. 05-country-row.sh fait exactement ça.

Les chiffres au niveau organisation utilisent le huitième champ, qui est le handle opaque du registre pour le compte détenant chaque ressource. Ceux-là restent sur le seul fichier RIPE — les handles sont locaux à chaque registre, donc concaténer cinq d’entre eux compterait deux fois la même entreprise plutôt que de la fusionner. Les organisations britanniques sont membres de RIPE, donc RIPE est là où elles sont. Voici combien détiennent un numéro d’AS et aucun IPv6 du tout :

03-org-no-ipv6.sh les compte. Et 04-silent-holders.py est celui qui compte le plus. Les organisations qui détiennent IPv6, sont vivantes en BGP, et n’en annoncent rien.

Quatre réserves avant les chiffres, parce qu’elles comptent et je préfère les dire que de me les faire jeter à la figure.

Les handles d’organisation sont par compte de registre, donc une entreprise faisant tourner plusieurs comptes compte plus d’une fois.

Annoncer un préfixe IPv6 en BGP n’est pas la même chose que remettre IPv6 à un client. C’est le plancher, pas le plafond. Un réseau qui n’annonce rien ne l’a certainement pas déployé. Un réseau qui annonce quelque chose pourrait encore être assis dessus.

Les totaux d’adresses effondrent les préfixes chevauchants. Un réseau annonçant un /16 à côté de quatre /17 issus de lui annonce 65 536 adresses, pas 196 608, et compter les préfixes naïvement gonfle les gros détenteurs de deux ou trois fois. J’utilise ipaddress.collapse_addresses de Python avant de totaliser.

La liste de cinquante sites web plus loin est un échantillon choisi à la main, pas une mesure de tout le pays. Une autre cinquantaine donnerait une fraction différente. Elle illustre un schéma plutôt qu’elle ne prouve une proportion, et je nomme ceux dont je parle au fil.

Les deux premières de celles-là rendent les chiffres de routage plus indulgents envers l’industrie que la vérité.

Le décompte

Numéros d'AS britanniques, et combien portent IPv6Réseaux britanniques dans la table de routage, 27 août 2026Source : fichier de délégation RIPE NCC et vidage de table RIPE RISenregistrés (orgs britanniques)3 106visibles dans la table2 248annonçant IPv42 078annonçant IPv61 048IPv4 et aucun IPv61 20057,7 % des réseaux actifsSur ces 1 200, au total 463 détiennent de l'espace IPv6 déjà émis par le registreet n'en ont jamais annoncé un seul préfixe. 1 113 autres organisations britanniques détenantun numéro d'AS n'ont jamais demandé d'IPv6 du tout, bien que ça ne coûte rien de plus quel'adhésion qu'elles paient déjà.
Chaque numéro d’AS enregistré à une organisation britannique, mesuré contre la table de routage mondiale le 27 août 2026. L’écart à droite est tout l’argument : 1 200 réseaux britanniques sont vivants sur l’internet sans aucun IPv6, et 463 d’entre eux détiennent de l’espace IPv6 émis par le registre qu’ils n’ont jamais annoncé.
Numéros d’AS enregistrés à des organisations britanniques3 106
Visibles dans la table de routage mondiale2 248
Annonçant IPv42 078
Annonçant IPv61 048
Annonçant IPv4 et aucun IPv61 200 — 57,7 %

Près de six réseaux britanniques actifs sur dix ne portent aucun IPv6. Pas partiellement. Pas derrière un drapeau. Pas dans un labo. Pas un préfixe.

Maintenant la partie qui met fin à l’argument du coût pour de bon.

Des 2 363 organisations britanniques détenant un numéro d’AS, 1 113 — 47,1 % — ne détiennent aucune allocation IPv6 d’aucune sorte. Elles ne l’ont jamais demandée au registre.

Une adhésion RIPE NCC coûte 1 800 € par an pour 2026, forfait, et ce tarif couvre vos allocations. Un /29 IPv6 vous donne 524 288 sous-réseaux de la taille de tout l’internet IPv4. C’est gratuit avec une adhésion que ces organisations paient déjà, et ça arrive en quelques jours.

La moitié d’entre elles n’ont jamais rempli le formulaire.

Et de celles qui l’ont fait, 463 organisations britanniques détiennent de l’espace IPv6, annoncent IPv4 au monde chaque jour, et n’annoncent aucun IPv6 quel qu’il soit. C’est 44,7 % des détenteurs britanniques d’IPv6 qui sont vivants en BGP.

Relisez ça, parce que c’est tout le billet en une phrase. Ils ont demandé les adresses. On leur a donné les adresses. Ils les ont mises dans un tableur. Puis personne n’a eu envie de les taper dans un routeur.

Vous ne pouvez pas expliquer ça avec l’argent. Personne n’a rien dépensé. Il n’y a pas de facture, pas d’achat, pas d’argument commercial, pas de demande de capital. Il y a une chose gratuite posée dans un compte de registre, et un service d’ingénierie qui n’a pas ouvert le ticket en quatorze ans.

Qui est sur cette liste

Voici les plus grands réseaux britanniques annonçant IPv4 et aucun IPv6, par la quantité d’espace d’adressage qu’ils annoncent réellement, le 27 août 2026. Les noms viennent de la base de données RIPE, qui vous dira qui détient chacun d’eux :

curl -s https://rest.db.ripe.net/ripe/aut-num/AS15914.json \
  | python3 -c 'import sys,json; a=json.load(sys.stdin)["objects"]["object"][0]["attributes"]["attribute"]; print(next(x["value"] for x in a if x["name"]=="org"))'
Les plus grands réseaux britanniques sans IPv6Les plus grands réseaux britanniques annonçant IPv4 et aucun IPv6, 27 août 2026Adresses IPv4 annoncées en BGP, préfixes chevauchants effondrés. Noms de la base RIPE.0k50k100k150k200kVodafone LimitedAS25310229 376Nationwide Building SocietyAS8698131 072British Airways plcAS15914131 072Convergence Group (Metronet)AS4297394 976Rackspace LtdAS2486786 016Lloyds Banking GroupAS4975881 920QinetiQ LimitedAS2477569 632Barclays Bank plcAS1270168 608MUFG Securities EMEAAS865165 792Université de WarwickAS20177365 792NatWest Markets plcAS2105465 536PricewaterhouseCoopers ServicesAS2129665 536London Borough of HackneyAS3940065 536Wireless Logic LimitedAS5132039 424Ensemble, les réseaux britanniques sans IPv6 siègent sur 4 232 232 adresses IPv4.Barclays détient 141.228.0.0/16 depuis août 1990.
Les quatorze plus grands réseaux britanniques annonçant IPv4 et aucun IPv6 le 27 août 2026, par l’espace d’adressage qu’ils annoncent réellement. Préfixes chevauchants effondrés avant de totaliser.

Regardez cette liste et essayez de dire les mots « barrière de coût » sans rire.

Quatre des banques de compensation. Un cabinet comptable mondial dont tout le produit est de dire aux autres comment gérer leurs affaires. Une entreprise de technologie de défense. Un hébergeur dont les clients le paient pour savoir ça. Une entreprise de connectivité internet des objets, vendant des cartes SIM, sans IPv6.

Entre eux, les réseaux britanniques n’annonçant aucun IPv6 sont assis sur 4 232 232 adresses IPv4. Le marché du transfert a fait en moyenne 20,04 $ l’adresse sur le premier semestre 2026, donc c’est une détention valant quelque chose au nord de quatre-vingts millions de dollars. Ce qui est la vraie raison pour laquelle aucun n’a bougé : ils sont riches en adresses, donc la pénurie est le problème de quelqu’un d’autre, et la plomberie de long terme de l’internet n’est le travail de personne en particulier.

Ce n’est pas une stratégie. C’est être à l’aise.

Le fichier de délégation porte la date où chaque bloc a été distribué, donc vous pouvez voir exactement à quel point à l’aise :

grep -E '\|ipv4\|(141\.228|155\.131|155\.136|161\.2)\.0\.0\|' \
  delegated-ripencc-extended-latest | cut -d'|' -f4,5,6

Barclays détient 141.228.0.0/16 depuis le 6 août 1990. Nationwide et NatWest ont pris les leurs en novembre 1991, à quatre jours d’écart. British Airways a obtenu 161.2.0.0/16 en avril 1992. Ce sont des blocs de classe B d’avant l’existence du web, distribués quand les adresses étaient gratuites et que personne ne comptait.

Tous ceux venus après eux paient pour ça. AWS a commencé à facturer 0,005 $ l’heure pour chaque adresse IPv4 publique le 1er février 2024 — 43,80 $ par an, chacune — et a dit clairement pourquoi : le coût d’en acquérir une « has risen more than 300% over the past 5 years » — a augmenté de plus de 300 % sur les cinq dernières années. La pénurie est réelle et elle a un prix. Il n’est juste pas payé par les gens détenant quatre millions d’adresses qu’ils ont eues pour rien en 1991.

Comment nous nous situons face à des pays comme nous

Deux chiffres par pays. Le premier est la part de sa population qui atteint Google en IPv6 natif, qui est la mesure de Google le 25 août 2026. Le second est la part de ses réseaux actifs qui annoncent un préfixe IPv6, qui est la mienne, à partir des mêmes fichiers que ci-dessus. Je l’ai gardé aux économies développées. Nous comparer à des pays qui ont eu l’internet tard ne vous dit rien sur nous. Ordonné par population.

PaysUtilisateurs en IPv6Réseaux avec IPv6Réseaux actifs
France85,6 %48,5 %1 368
Allemagne76,6 %63,9 %2 291
Belgique72,8 %45,8 %273
États-Unis56,6 %25,9 %18 453
Japon56,1 %56,4 %721
Royaume-Uni53,7 %42,3 %2 078
Norvège52,6 %66,9 %278
Pays-Bas51,9 %61,8 %1 023
Canada43,6 %33,1 %1 578
Irlande38,1 %41,5 %195
Australie37,2 %26,3 %1 652
Suède36,1 %53,6 %642
Corée du Sud18,1 %5,3 %916
Italie17,6 %35,8 %1 078
Espagne13,3 %26,7 %934

Sixième sur quinze. La France a les deux tiers de plus de sa population en IPv6 que nous, sur la même chaîne d’approvisionnement européenne, sous les mêmes équipementiers, avec les mêmes clients leur disant que personne ne demande. L’Allemagne est vingt-trois points devant nous sur les utilisateurs et vingt-deux points devant sur les réseaux.

Les deux colonnes de pourcentage ne sont pas d’accord entre elles, et le désaccord est l’histoire.

Utilisateurs en IPv6 contre réseaux portant IPv6, quinze économies développéesGens en IPv6, contre réseaux portant IPv6Mesure utilisateur de Google, 25 août 2026, contre mon décompte des réseaux actifs annonçant un préfixe IPv6, 27 août 2026.part des genspart des réseauxFrance85,6 %48,5 %Allemagne76,6 %63,9 %Belgique72,8 %45,8 %États-Unis56,6 %25,9 %Japon56,1 %56,4 %Royaume-Uni53,7 %42,3 %Norvège52,6 %66,9 %Pays-Bas51,9 %61,8 %Canada43,6 %33,1 %Irlande38,1 %41,5 %Australie37,2 %26,3 %Suède36,1 %53,6 %Corée du Sud18,1 %5,3 %Italie17,6 %35,8 %Espagne13,3 %26,7 %0 %20 %40 %60 %80 %100 %Une longue barre bleue sur une courte rose veut dire que trois ou quatre opérateurs ont fait le travail et le restedu pays non. La France, la Belgique, les États-Unis et le Royaume-Uni ont tous cette forme.La Norvège, la Suède et le Japon non.
Les mêmes quinze pays sur les deux mesures, ordonnés par la part de gens utilisant IPv6. Là où la barre réseau est bien plus courte que la barre utilisateur, quelques grands opérateurs portent le pays et personne d’autre ne s’est donné la peine. C’est la forme des États-Unis, de la Belgique, de la France — et du Royaume-Uni.

Le pourcentage utilisateur d’un pays est fixé par trois ou quatre entreprises. Le pourcentage réseau est fixé par tous les autres. Quand le premier est haut et le second bas, ça veut dire que les grands réseaux d’accès ont fait le travail et que le reste du pays a fait du parasitisme dessus.

Les États-Unis sont le cas le plus net : 56,6 % de leur population est en IPv6 et seulement 25,9 % de leurs réseaux le sont. Les câblo-opérateurs et les opérateurs mobiles portent presque tout le monde. Les dix-huit mille autres réseaux américains n’ont rien fait.

Le nôtre est le même tour avec de plus petits chiffres — 53,7 % d’utilisateurs contre 42,3 % de réseaux. Ces 53,7 % ne sont pas un accomplissement national. C’est Sky et BT, et une erreur d’arrondi de tous les autres.

La Norvège et la Suède sont la contre-forme honnête : moins d’utilisateurs en IPv6 que nous, plus de réseaux le portant. Plus de leur industrie a réellement fait le travail, et ce sont les FAI grand public qui traînent plutôt que le métier.

Et une ligne mérite un regard plus proche, parce que c’est celle que les gens saisissent quand ils veulent se sentir mieux à notre sujet.

La Corée du Sud est le pire pays de cette liste, de loin. Des 916 réseaux coréens actifs, 61 annoncent IPv6. Soixante et un.

Parmi le haut débit domestique le plus rapide de la terre, une industrie de puces qui imprime de l’argent, et 94,7 % de ses réseaux ne l’ont jamais allumé. Les trois grands opérateurs — KT, SK Broadband et LG U+ — l’annoncent tous, ce qui est pourquoi 18,1 % des utilisateurs coréens l’ont. Les huit cent cinquante autres réseaux n’ont rien fait.

Quelle que soit l’excuse là-bas, ce n’est pas l’argent, ce n’est pas la capacité, et ce n’est pas l’état de la fibre.

Vingt ans à boulonner des choses

Voici ce que l’industrie a construit au lieu de taper les adresses.

Quand les adresses ont commencé à manquer, la réponse a été le NAT à l’échelle opérateur : mettre des centaines de clients derrière une seule adresse IPv4 publique et traduire entre eux. Tout ce qui est ci-dessous existe pour rendre ça survivable, et chacun de ces documents est un morceau de travail d’ingénierie que quelqu’un a choisi de faire plutôt que de déployer IPv6.

RustineÀ quoi ça sert
RFC 6598 (2012)Brûle un /10 entier — quatre millions d’adresses — comme « espace d’adressage partagé », pour que le contournement de la pénurie ait besoin de ses propres adresses
RFC 6333 (2011)DS-Lite : tunneliser IPv4 sur le réseau IPv6 que vous avez bâti mais n’avez pas donné au client
RFC 6877 (2013)464XLAT : traduire IPv4 en IPv6 et retour sur le même trajet
RFC 6888 (2013)La liste des exigences qu’un NAT à l’échelle opérateur doit satisfaire pour ne pas être dangereux
RFC 7021 (2013)Une étude complète des applications que le NAT à l’échelle opérateur casse
RFC 7422 (2014)Correspondance d’adresses déterministe, inventée uniquement pour empêcher le volume de journalisation de ruiner le fournisseur
RFC 7597 / 7599 (2015)MAP-E et MAP-T : deux façons de plus de porter IPv4 sur IPv6 sans admettre qu’on a IPv6
Vingt ans de contournements contre le seul changement qu'ils remplacentCe que nous avons bâti à la place, et au lieu de quoiÉviter IPv6Espace partagé — un /10 entier brûléRFC 6598, 2012DS-Lite — tunneliser IPv4 sur un cœur IPv6RFC 6333, 2011464XLAT — traduire hors d'IPv4 et retourRFC 6877, 2013Des règles pour rendre le CGN survivableRFC 6888, 2013Une étude des applications qu'il casseRFC 7021, 2013Correspondance déterministe pour les journauxRFC 7422, 2014MAP-E et MAP-T — IPv4 sur IPv6 encoreRFC 7597/9, 2015Plus le niveau NAT lui-même : tables de session,allocation de ports, passerelles, bascule, capacité,un pipeline de journaux — et une loi de conservationvotée pour masquer l'attribution qu'il a détruite.Faire IPv6Double pileUne famille d'adresses de plus,sur le protocole de routage etla politique de pare-feu en place.Pas de nouveau niveau dans le trafic.Pas d'état de session à dimensionner.Pas de journaux pour une loi.Gratuit au registre.Les deux colonnes sont du travail d'ingénierie, et celle de gauche est plus grande.La différence est que le travail de gauche peut s'acheter à un fournisseur, et celui de droitedoit être compris par les gens qui possèdent le réseau.
Deux décennies de travail de normalisation, de matériel et de journalisation, tout au service de ne pas faire la chose à droite. La double pile est une famille d’adresses ajoutée à côté de celle que vous faites déjà tourner. Tout à gauche existe pour l’éviter.

Regardez la forme de ça. Chaque élément de la liste est plus dur que la double pile. Tunneliser IPv4 dans IPv6 est strictement plus de travail que router IPv6, parce qu’il faut router l’IPv6 de toute façon pour porter le tunnel. Traduire entre familles est plus de travail que ne pas traduire. Un NAT à l’échelle opérateur est une boîte à états au milieu de votre réseau, avec de la planification de capacité, de la bascule, des tables de session, de l’allocation de blocs de ports, des passerelles de couche applicative pour les protocoles qu’il casse, et un pipeline de journalisation dimensionné pour une obligation légale.

La double pile est une famille d’adresses, un protocole de routage que vous faites déjà tourner, et une politique de pare-feu que vous avez déjà écrite.

L’industrie a regardé ces deux options et a choisi la chère, vingt ans de suite, parce que la chère pouvait s’acheter et la bon marché devait se comprendre. Acheter une boîte est un exercice d’achat. Allumer IPv6 veut dire que quelqu’un dans le bâtiment doit savoir comment le réseau marche.

Ce que ça casse réellement

Pour quiconque pense que c’est de l’esthétique, voici ce qu’une adresse partagée coûte à vos utilisateurs, dans l’ordre où ils vous appelleront à ce sujet.

Rien ne peut entrer. Pas de redirection de port, donc pas d’auto-hébergement de quoi que ce soit, pas de console de jeu jouant l’hôte, pas de VPN site à site sans relais, pas de caméra de sécurité sans cloud fournisseur, pas d’accès distant à la chose de l’autre site. Chacun de ceux-là se fait remplacer par un service de rendez-vous tiers, qui est une entreprise de plus détenant vos données parce que votre fournisseur ne vous donnait pas une adresse.

Vous héritez de la réputation d’inconnus. Partagez une adresse avec quelques centaines de gens et vous partagez leur comportement. Limitations de débit, CAPTCHA, blocages Wikipédia, erreurs géographiques de streaming et notation de fraude atterrissent tous sur vous pour quelque chose que quelqu’un d’autre a fait.

Les ports s’épuisent. Un NAT à l’échelle opérateur a 65 535 ports par adresse publique par protocole, et une seule session de navigateur moderne en mange des dizaines. Sur-souscrivez et la défaillance n’est pas une erreur propre. C’est un défaut lent, intermittent, non reproductible qui ressemble à tout sauf à ce qu’il est, et il brûle des jours de temps de support par incident.

Chaque contournement doit être maintenu à jamais, par des gens qui auraient pu passer ce temps sur le correctif.

Et puis il y a celui qui a cessé d’être un désagrément et est devenu le problème de tout le monde. Personne ne peut dire qui a fait quoi.

La rustine qui a atteint le Parlement

Une fois que des centaines de clients partagent une adresse, une adresse n’identifie plus personne. Donc la police ne peut pas résoudre une adresse IP à une personne, et la réponse à ça n’a pas été IPv6. C’était de la législation.

L’article 21 du Counter-Terrorism and Security Act 2015 a amendé le régime de conservation des données précisément pour que le Secretary of State puisse contraindre les fournisseurs à conserver les données supplémentaires nécessaires « to link the unique attributes of a public Internet Protocol (IP) address to the person (or device) using it at any given time » — pour lier les attributs uniques d’une adresse IP publique à la personne (ou l’appareil) l’utilisant à un moment donné. Les notes explicatives sont nettes sur pourquoi il fallait : les fournisseurs « may share IP addresses between multiple users, and the providers generally have no business purpose for keeping a log of who used each address at a specific point in time » — peuvent partager des adresses IP entre plusieurs utilisateurs, et n’ont généralement aucune raison commerciale de tenir un journal de qui a utilisé chaque adresse à un instant précis.

Lisez ça en ingénieur plutôt qu’en juriste. L’industrie a cassé l’attribution pour s’épargner du travail, et le Parlement a voté une loi l’obligeant à bâtir un système de journalisation pour masquer la casse.

Deux ans plus tard Europol l’a dit platement. En octobre 2017 il a publié un appel à l’industrie pour cesser d’utiliser le NAT à l’échelle opérateur, avec des chiffres : 90 % des fournisseurs d’accès internet mobile et 50 % des fournisseurs de ligne fixe avaient adopté une technologie qui les empêchait d’identifier leurs propres abonnés. Le directeur exécutif d’alors d’Europol a dit que le CGN « has created a serious online capability gap in law enforcement efforts to investigate and attribute crime » — a créé une grave lacune de capacité en ligne dans les efforts des forces de l’ordre pour enquêter et attribuer le crime —, et a noté qu’il « forces judiciary and law enforcement authorities to investigate many more individuals than would normally be necessary » — force les autorités judiciaires et policières à enquêter sur bien plus d’individus qu’il ne serait normalement nécessaire.

Europol a aussi dit la partie silencieuse. Le NAT à l’échelle opérateur « was supposed to be a temporary solution until the transition to IPv6 was completed » — était censé être une solution temporaire jusqu’à ce que la transition vers IPv6 soit achevée. À la place l’industrie a continué d’en augmenter l’usage tandis que le remplacement était là, fini, gratuit et ignoré.

Donc le coût de ne pas déployer IPv6 comprend : une loi primaire, une obligation de conservation à l’échelle nationale, des innocents entraînés dans des enquêtes parce qu’ils partageaient une adresse avec quelqu’un qui ne l’était pas, et une lacune de capacité continue que la police décrit comme un problème de sécurité publique.

Personne n’a mis ça sur l’argument commercial. Ça n’apparaît jamais dans la diapositive « IPv6 n’a pas de retour sur investissement », parce que ce n’est pas payé par les gens qui l’ont causé.

Ça ne fait pas que cacher les criminels. Ça les aide.

L’argument de l’attribution est celui que font les forces de l’ordre, et il porte sur attraper les gens après coup. Il y a un second argument qui se fait bien moins souvent et qui est pire : le partage d’adresses dégrade activement les défenses qui empêchent les attaques d’arriver tout court.

Ce n’est pas mon analyse. L’IETF a publié le catalogue dans le RFC 6269, Issues with IP Address Sharing, en juin 2011. C’était avant que le Royaume-Uni ne déploie l’essentiel du NAT à l’échelle opérateur qu’il fait tourner maintenant. Ses mots simples : le partage d’adresses « creates a vector for attack amplification in numerous ways » — crée un vecteur d’amplification d’attaque de nombreuses façons.

Voici ce qu’il a averti qui casserait, et a cassé.

Les limitations de débit et les verrouillages cessent de marcher. La défense standard contre la devinette de mots de passe et le bourrage d’identifiants est de compter les échecs par adresse et de mettre le fautif au coin. Partagez cette adresse entre des centaines de gens et le compteur mesure une foule. Le RFC 6269 est net sur le résultat : « In the presence of widespread large-scale address sharing, penalty box solutions to service abuse simply will not work » — en présence d’un partage d’adresses à grande échelle et généralisé, les solutions de mise au coin contre l’abus de service ne marcheront tout simplement pas. Les connexions ratées d’un utilisateur verrouillent tous les autres, donc les opérateurs relèvent les seuils, et relever les seuils est ce que l’attaquant voulait.

Le blocage devient un dommage collatéral. Bloquez le spammeur et vous bloquez la route où il vit. Donc l’opérateur sensé cesse de bloquer, et l’abus continue depuis une adresse que personne n’ose toucher.

Les machines infectées restent infectées. Les flux d’abus et les notifications de malware arrivent comme une adresse et un horodatage. Derrière un CGN sans journalisation de ports, le fournisseur ne peut pas dire lequel de ses clients fait tourner le bot, donc le client n’est jamais prévenu et l’infection reste active. Pire, le RFC 6269 note le problème inverse : « someone else’s worm can interfere with the ability to access the service for other subscribers sharing the same IP address » — le ver de quelqu’un d’autre peut gêner la capacité d’accéder au service pour les autres abonnés partageant la même adresse IP.

Le contrôle d’accès par adresse échoue. Chaque liste d’autorisation bâtie sur l’adresse source admet maintenant une foule plutôt qu’un client.

Et une défense est mesurablement affaiblie plutôt que simplement émoussée. Les attaques TCP à l’aveugle dépendent de deviner le quintuplet, et la mitigation de l’industrie est de randomiser le port source (RFC 6056). Un NAT à l’échelle opérateur remet à chaque abonné une tranche de la plage de ports plutôt que la totalité. Dans les mots du RFC 6269, « with shared IPv4 addresses, the port selection space is reduced » — avec des adresses IPv4 partagées, l’espace de sélection de ports est réduit. Le contournement de la pénurie d’adresses retire directement de l’entropie à un mécanisme anti-attaque.

Puis il y a la partie qui devrait inquiéter n’importe qui, quoi qu’il pense de la police. Si le serveur n’a pas journalisé les ports source et que le NAT n’a pas journalisé les destinations, le RFC 6269 énonce ce qu’un fournisseur doit faire quand une requête légale arrive : il « would need to disclose the identity of all subscribers who had active sessions on the NAT during the time period in question. This may be a large number of subscribers » — devrait divulguer l’identité de tous les abonnés ayant eu des sessions actives sur le NAT pendant la période en question. Ce peut être un grand nombre d’abonnés.

L’alternative à identifier un abonné coupable est de remettre l’identité de plusieurs centaines d’innocents. C’est le vrai résultat en matière de vie privée du partage d’adresses, et c’est l’opposé de celui que ses défenseurs lui prêtent.

Trois choses doivent s’aligner, et personne n’est tenu d’en fournir aucune

Les gens supposent que les journaux existent quelque part et que c’est affaire de demander. La plupart du temps ils n’existent pas, et la raison est arithmétique plutôt que malveillance.

Pour retransformer une adresse partagée en un foyer, trois choses séparées doivent toutes s’être bien passées :

  1. Le serveur distant a journalisé le port source. Le RFC 6302 a demandé aux serveurs exposés à l’internet de journaliser le port source et l’horodatage à côté de l’adresse, en 2011. C’est une recommandation. Personne ne l’impose, et un grand nombre de serveurs journalisent encore l’adresse seule. Auquel cas la piste est morte avant d’atteindre le bout britannique.
  2. Le fournisseur a gardé la correspondance. Chaque session, pendant des mois.
  3. Les horloges étaient d’accord. Le RFC 6269 avertit que sur un CGN chargé « even very small amounts of clock skew between a third party’s server and the CGN operator will result in ambiguity about which customer was using a specific port at a given time » — même de très petites dérives d’horloge entre le serveur d’un tiers et l’opérateur du CGN entraîneront une ambiguïté sur quel client utilisait un port précis à un moment donné.

Manquez-en une seule et vous n’avez rien. Et celle du milieu est là où ça s’effondre, parce que les documents de normalisation contiennent les calculs.

Le RFC 7422 a mis de vrais chiffres dessus. Les opérateurs ont rapporté environ 33 000 connexions par foyer par jour. À environ 150 octets par entrée de journal ça fait 5 Mo par abonné par jour, 150 Mo par mois. Pour un fournisseur d’un million d’abonnés : 150 téraoctets de journaux par mois, 1,8 pétaoctet par an — à garder pendant les six à douze mois que la loi attend, et à chercher sur demande.

Et ce n’est jamais un seul journal. NAT444, le cas pour lequel le RFC 7422 dimensionne ses entrées, met une traduction dans le routeur du client et une autre chez l’opérateur, et chaque porte qu’un paquet franchit doit noter ce qu’elle a fait. Reconstruire une seule session veut dire corréler des tables séparées, tenues par des parties séparées, contre le problème d’horloge ci-dessus. La preuve arrive en morceaux de systèmes différents, ou elle n’arrive pas.

Et l’argent n’en est que la moitié. Capturer des enregistrements de session à ce rythme, les expédier quelque part, les indexer pour qu’une requête légale revienne en heures plutôt qu’en semaines, et garder le tout un an est un projet d’ingénierie des données. Il n’y a pas de tableau de bord pour ça et pas de boîte à acheter. Ça doit être bâti par quelqu’un qui comprend ce qu’il bâtit, et ce n’est pas du pointer-cliquer, ce qui dans cette industrie est assez proche de dire que ça n’est pas bâti.

Personne n’allait jamais payer pour ça non plus. Et l’IETF le savait, ce qui est pourquoi le RFC 6888 dit aux opérateurs l’opposé de ce dont la sécurité publique a besoin : « A CGN’s port allocation scheme SHOULD minimize log volume » — le schéma d’allocation de ports d’un CGN DEVRAIT minimiser le volume de journaux —, justifié parce que « huge log volumes can be problematic to CGN operators » — d’énormes volumes de journaux peuvent être problématiques pour les opérateurs de CGN. Le RFC 7422 n’existe pour aucun autre but que de rabattre cette facture.

Donc le conseil de conception à l’industrie est journalisez moins, l’économie dit que 1,8 pétaoctet par an est inabordable, et l’attente légale est un enregistrement complet. Ces trois-là ne peuvent pas être vrais à la fois, et celui qui cède est l’enregistrement.

C’est pourquoi Europol a trouvé que la majorité des fournisseurs d’accès ne peuvent pas identifier un abonné quand on leur signifie une ordonnance légale. Pas parce qu’ils font obstruction. Parce que la chose demandée n’était jamais économiquement possible à garder, et personne n’a jamais été contraint.

Deux choses en découlent, et elles sont miennes plutôt que la citation de quiconque.

Premièrement : une grande part des connexions internet britanniques sont non attribuables par construction. Le mobile est le cas le plus net, et une mesure indépendante le situe plus haut qu’Europol, à 95 %. Donc l’anonymat qui exigeait avant Tor, ou un VPN que quelqu’un devait acheter, est maintenant le réglage d’usine d’une connexion mobile britannique — délivré gratuit avec la SIM, à tout le monde, y compris le petit nombre de gens que tout l’appareil est censé trouver.

Deuxièmement, et pire : casser la méthode ciblée bon marché est ce qui produit la demande pour la chère non ciblée. Quand vous pouvez signifier un mandat sur une adresse et obtenir un foyer, vous n’avez besoin de rien d’autre. Quand ça cesse de marcher, l’État ne hausse pas les épaules. Il saisit quelque chose de plus large. C’est ce qu’était la loi de 2015 : un devoir de conservation sur toute la base d’abonnés, pour répondre à des questions sur une poignée de gens.

Rien de tout ça n’existe de l’autre côté. Rien n’est traduit, donc il n’y a aucun enregistrement par connexion à garder du tout. L’adresse dans le journal du serveur distant est déjà le préfixe de l’abonné : un enregistrement, écrit une fois quand la ligne a été provisionnée, dans un système. Même un fournisseur faisant tourner les préfixes quotidiennement écrit quelques centaines par an par client, contre les douze millions que 33 000 connexions par jour font. Ce n’est pas qu’IPv6 journalise moins. Il n’y a rien à journaliser.

Les gens qui ont écrit le contournement le savaient. Au milieu d’une spécification écrite sans autre raison que de rendre le CGN abordable à journaliser, ils se sont arrêtés pour consigner que « native IPv6 will offer subscribers a better experience than CGN » — l’IPv6 natif offrira aux abonnés une meilleure expérience que le CGN.

Une industrie a refusé de dépenser une quinzaine par réseau sur un protocole gratuit, et le pays a eu un régime de conservation des données à la place.

Corriger ça protégerait-il les enfants mieux que l’Online Safety Act ?

Je veux être prudent ici, parce qu’il est facile de mal faire cet argument et la version mal faite mérite le tacle qu’elle recevrait.

Commencez par comment une enquête sur l’abus d’enfants se déroule réellement. Une plateforme détecte le matériel et le signale. Le signalement porte une adresse et un horodatage. La police signifie au fournisseur d’accès de transformer ça en un abonné, et l’abonné est une adresse dans le monde réel avec une porte dessus. C’est toute la chaîne, et chaque étape après dépend de celle d’avant.

Maintenant mettez un NAT à l’échelle opérateur au milieu. Le signalement arrive encore. L’adresse se résout encore. Vers plusieurs centaines de foyers, et Europol a trouvé des enquêtes « dropped or delayed » — abandonnées ou retardées — en conséquence. Leurs exemples de cas incluent un procureur incapable d’identifier les membres d’un forum soutenant l’EIIL, donc la poursuite n’a pas eu lieu, et le HMRC traçant une fraude fiscale de masse vers des adresses mobiles et trouvant les pistes « frustrated from the outset » — contrariées dès le départ.

La CyberTipline du NCMEC a pris 21,3 millions de signalements en 2025 et en a renvoyé plus de 18,8 millions aux forces de l’ordre, dont plus de 53 000 impliquant un enfant en danger immédiat. Le NCMEC consigne aussi que plus de 10 % des signalements de l’industrie sont arrivés avec des informations trop pauvres pour déterminer à quelle juridiction les envoyer. Ce chiffre n’est pas l’œuvre du CGNAT et je ne prétends pas qu’il l’est — mais il vous dit où dans ce pipeline les affaires meurent. Elles meurent sur les métadonnées.

Donc la version honnête de la comparaison est celle-ci. Le NAT à l’échelle opérateur casse le dernier kilomètre même de l’Online Safety Act. Le Parlement a imposé des devoirs de détecter et signaler, et a laissé le réseau d’accès incapable de résoudre ce qui est signalé. Vous pouvez voter autant de devoirs de signalement que vous voulez. Si l’étape finale renvoie une foule, le signalement est du papier.

Et le coût des deux choses n’est pas comparable de loin. La loi est la plus grande pièce de régulation internet que ce pays ait tentée — des milliers de services concernés, un régulateur écrivant des codes pendant des années, une vérification d’âge tournant à des millions de contrôles par jour, et un problème de contournement assez grand pour que le Parlement ait débattu de l’usage des VPN à la Chambre des lords. IPv6 ne coûte rien au registre et prend à une équipe compétente une couple de semaines. L’une de ces choses a été exigée de toute l’industrie. L’autre n’a jamais été demandée à personne.

Trois choses doivent être dites platement, parce que l’argument est sans valeur sans elles.

Une. Ce n’est pas un substitut, et je ne le propose pas comme tel. IPv6 ne fait rien pour empêcher un enfant de douze ans de trouver de la pornographie. Il ne fait rien sur les systèmes de recommandation, la lecture automatique ou la diffusion en direct. Il ne fait rien sur le matériel hébergé dans un autre pays, ce qui est l’essentiel. Ce sont les problèmes pour lesquels la loi a été écrite et aucun changement de protocole ne les touche.

Deux. IPv6 n’est pas une couche d’identité, et quiconque le vend comme telle le survend. Les extensions de vie privée font tourner l’adresse d’un appareil par conception, donc l’adresse de la machine n’est pas la chose stable. Ce qui est stable est le préfixe délégué à la ligne — le /56 que Sky remet à chaque abonné depuis 2016. Ça se résout à un abonné, ce qui est exactement la résolution dont une requête légale a besoin, et pas plus. C’est une restauration de ce qu’une seule adresse IPv4 par ligne donnait avant, pas une nouvelle capacité de surveillance.

Trois. La propriété qui contrarie la police contrarie aussi tous les autres qui vous pistent, et certains gens la valorisent. Être l’un de cinq cents derrière une adresse partagée est une vraie couverture de foule contre le profilage commercial. Je ne pense pas qu’elle vaille ce qu’elle coûte — c’est une couverture achetée en rendant l’abus non attribuable et la limitation de débit inutile, et c’est une couverture que les plateformes voient de toute façon à travers avec les cookies et l’empreinte. Mais c’est un vrai argument et il mérite d’être énoncé plutôt qu’ignoré.

Donc non, ce n’est pas IPv6 à la place de l’Online Safety Act. C’est que la Grande-Bretagne a écrit la loi de sécurité en ligne la plus chère de son histoire par-dessus une plomberie qu’elle savait cassée, quand le correctif était gratuit, bien documenté, et disponible pendant tout le temps où le projet de loi était rédigé.

Ce qu’il faut réellement demander

Pas une interdiction. Une interdiction est le mauvais instrument et se retournerait contre nous.

Il ne reste pas d’IPv4 à distribuer — RIPE est vide depuis novembre 2019, et un nouveau fournisseur obtient un seul /24 d’une liste d’attente. Interdisez le partage d’adresses demain et le petit opérateur ne peut plus connecter de clients du tout, tandis que les structures assises sur des blocs de classe B de 1990 continuent intactes. Ça enracinerait exactement les gens dont parle ce billet.

Le meilleur instrument existe déjà et quelqu’un a déjà mené l’expérience.

En 2012 la police fédérale belge, son régulateur des télécoms, son Collège des procureurs généraux et son association de FAI ont signé un code de conduite volontaire de deux pages. Maximum 16 abonnés derrière une adresse IPv4. Limiter l’usage du CGN. Commencer à adopter IPv6.

Dès 2017 la plupart des opérateurs belges étaient sous la limite, l’un était descendu à 8, et la police belge voyait en moyenne quatre utilisateurs par adresse mobile. Le propre résumé d’Europol du pourquoi est la partie qui vaut d’être lue deux fois : les plus grands fournisseurs « are quickly moving towards IPv6 because no financial interest to invest in CGN anymore » — se dirigent rapidement vers IPv6 parce qu’il n’y a plus d’intérêt financier à investir dans le CGN. Plafonnez la sur-souscription et l’économie du contournement s’effondre, parce qu’un NAT qui ne peut empiler que seize personnes n’est pas moins cher que le protocole qui n’en a besoin d’aucune.

Cette année-là la Belgique avait la plus haute adoption d’IPv6 au monde à 49 %, quand la Grande-Bretagne et la France étaient à 14 % et l’Espagne et l’Italie sous 1 %. La Belgique est encore troisième dans la table de pays ci-dessus, à 72,8 %.

C’est ça la demande. Pas « vous ne pouvez pas partager d’adresses » — vous ne pouvez pas vendre une connexion qui est à la fois non attribuable et sans IPv6. Adressage partagé à côté d’un IPv6 qui marche, c’est bien. C’est comme ça que chaque réseau mobile de la terre opère. Adressage partagé sans IPv6, c’est vendre un service cassé et facturer au public les conséquences.

Sky a prouvé que c’était faisable, il y a onze ans

Si c’était vraiment dur, personne au Royaume-Uni n’y serait arrivé.

Sky a démarré un projet IPv6 interne début 2013 et a fini en 2016, avec environ 90 % de sa base de ligne fixe — environ cinq millions d’utilisateurs — recevant IPv6 et l’utilisant. Leur ingénieur a tout écrit sur RIPE Labs : 6PE à travers le cœur MPLS, peering et transit à double pile, attributs RADIUS pour l’activer par abonné, travail de firmware sur sept modèles de CPE dont cinq anciens, et mises à niveau de capacité sur RADIUS et DNS.

Trois ans, un FAI, et le même cuivre Openreach que tous les autres vendaient dessus. ISPreview a rapporté la fin en septembre 2016, Sky attendant 95 % de sa base pour la fin de cette année-là, et Sky a pris le Jim Bound IPv6 Award pour ça.

Leur conseil était : « Do not underestimate the work required to enable IPv6, and do not leave it to the last minute to begin the journey » — ne sous-estimez pas le travail requis pour activer IPv6, et ne laissez pas le voyage à la dernière minute.

Onze ans plus tard, l’essentiel de l’industrie est encore à la dernière minute, et la traite comme un endroit où vivre.

Tout le monde a les adresses depuis des années

Sky a été le premier des grands FAI. Il était loin d’être le premier du pays, et pas un fournisseur de cette liste ne peut dire qu’il attendait le registre.

RIPE estampe la date d’allocation dans le nom du bloc, donc vous pouvez vérifier n’importe lequel vous-même :

whois -h whois.ripe.net 2a01:4b00::/32 | grep -E 'netname|^org:'
# netname:  UK-BCUBE-20110225   -> Hyperoptic, allocated 25 February 2011

Chaque date ci-dessous vient de cette recherche contre la propre allocation du fournisseur, recoupée contre le fichier de délégation. Les grands FAI sont en gras, le reste sont les bâtisseurs de fibre complète. Que les clients obtiennent réellement IPv6 vient de l’enquête d’ISPreview telle que mise à jour en mars 2025, et du traqueur mobile pour les réseaux de téléphonie.

Depuis quand chaque fournisseur britannique détient IPv6, et si les clients l'ontDepuis quand chaque fournisseur britannique détient IPv6 — et si les clients l'ontDates d'allocation du fichier de délégation RIPE et de ses estampilles netname.S'il atteint les clients : ISPreview, mars 2025, et le traqueur mobile communautaire.les clients l'onten partie — un réseautoujours pas livré (17 sur 40)20022002200620062010201020142014201820182022202220262026TalkTalk (sous Opal Telecom)Andrews & ArnoldVodafone UKEE (sous T-Mobile)SkyGigaclearO2 (Telefónica UK)BTVirgin Media (sous NTL)KCOMHyperoptic (sous Bcube)Zen InternetB4RNTrooli (sous Call Flow)ExascaleThree UKCommunity FibreOgi (sous NetSupport)WightFibreTruespeedAirbandG.NetworkWessex InternetQuicklineFibreNestWildanetFibrus (sous B4B Networks)ZzoommGoFibre (sous Borderlink)ToobNetomnia / YouFibrePine MediaBeFibreSquirrel InternetbrskLit Fibre (sous Broadreach)iDNET *GrainHey! BroadbandOctaplusChacun des quarante détient de l'espace IPv6 depuis au moins trois ans, la plupart depuis plus d'une décennie.17 d'entre eux ne le donnent toujours pas à un client.
Quarante fournisseurs britanniques, ordonnés par la date où le registre leur a donné IPv6. Chaque barre court de cette allocation à aujourd’hui. Les barres bleues le livrent aux clients ; les roses ne l’ont jamais fait.

Quarante fournisseurs. Chacun détient de l’espace IPv6 depuis au moins trois ans, la plupart depuis plus d’une décennie — et dix-sept d’entre eux ne le donnent toujours pas à un client.

Hyperoptic détient 2a01:4b00::/32 depuis février 2011. Quinze ans à bâtir de la fibre dans des immeubles, à vendre des connexions gigabit, et à mettre des gens derrière un NAT à l’échelle opérateur avec une allocation IPv6 inutilisée dans les livres. Trooli a le sien depuis treize ans. Truespeed et Airband depuis dix.

Andrews & Arnold est celui contre qui tenir les autres. Un petit FAI à Bracknell avec une fraction des clients et des ingénieurs de tout autre sur cette liste, donnant IPv6 à chaque ligne depuis 2002, et l’une des structures derrière 6UK. TalkTalk a pris son allocation trois mois plus tôt et ne le livre toujours pas aux particuliers.

Virgin Media a pris son bloc trois semaines avant que Zen ne prenne le sien. Zen l’a livré, et je suis au bout d’un de leurs /48 depuis. Virgin dit encore « quand nous serons prêts ».

Et regardez le bas de la table. Squirrel, brsk, Lit Fibre et Octaplus ont tous obtenu leurs allocations dans les six dernières années et livrent tous IPv6, tandis que des fournisseurs détenant de l’espace depuis 2011 ne le font pas. Commencer tard n’est pas l’obstacle. Commencer tout court l’est.

Deux noms de cette enquête ne sont pas dans le graphique, et la raison est la même pour les deux. Cuckoo est une marque de détail achetant de l’accès de gros sur Openreach, CityFibre et d’autres, et Freedom Fibre est un réseau de gros dont les clients viennent par des partenaires de détail. Ni l’un ni l’autre ne détient son propre espace d’adressage, donc IPv6 est la décision de quelqu’un d’autre à prendre pour eux. iDNET est marqué d’un astérisque parce que le sien est une assignation indépendante du fournisseur plutôt qu’une allocation en propre.

Celui qui tranche

Si vous voulez l’argument réduit à une seule entreprise, c’est Plusnet.

BT a acheté Plusnet en janvier 2007. Plusnet siège sous le propre compte RIPE de British Telecommunications, donc il a accès à l’allocation IPv6 de BT depuis juin 2010. BT livre IPv6. EE, l’autre entreprise sœur, livre IPv6. ISPreview a noté que BT et Plusnet utilisent même des routeurs clients presque identiques, qualifiant l’écart de « somewhat of a peculiarity » — quelque peu une curiosité.

Plusnet a testé IPv6 en 2011 et a publiquement pressé le reste de l’industrie de s’y mettre. En 2019 il a dit qu’il lancerait au printemps 2020. En 2021 il attendait « to make good progress over the coming year » — de faire de bons progrès dans l’année à venir. En novembre 2023 il a mené un essai de trois mois sur deux sites à Chesterfield et Sheffield, avec une vingtaine de salariés et de clients amicaux dessus.

En avril 2026 son propre forum client demandait encore où IPv6 en était.

Une maison mère. Une allocation d’adresses. Du matériel presque identique. Des ingénieurs qui travaillent pour le même groupe et peuvent descendre le couloir vers les gens qui l’ont déjà fait. Trois marques, et l’une d’elles ne peut pas gérer en quinze ans ce que les deux autres ont fini.

Quoi qui arrête ça, ce n’est pas la technologie, l’argent, le matériel, ou l’espace d’adressage. C’est quelqu’un décidant que ce n’est pas son problème ce trimestre, quinze ans de suite.

Virgin Media, seize ans de « quand nous serons prêts »

L’autre bout de l’échelle mérite d’être nommé, parce que la chronologie est de notoriété publique et elle est remarquable.

Mars 2010 : un client demande sur le propre forum de Virgin Media quand IPv6 arrive. La réponse est « quand nous serons prêts ».

Novembre 2016 : Virgin dit à ISPreview qu’il prévoit d’adopter IPv6 pour mi-2017. Il ne le fait pas.

Juin 2018 : un essai grand public est rapporté. Décembre 2018 : une troisième présentation au UK IPv6 Council, laissant entendre 2019.

2021 : une déclaration qu’ils « continuing to plan our IPV6 deployment having tested several solutions and intend to introduce IPV6 for our customers in future » — continuent de planifier leur déploiement IPv6 ayant testé plusieurs solutions et comptent introduire IPv6 pour leurs clients à l’avenir.

Février 2024 : Virgin Media verrouille le fil de forum vieux de quatorze ans.

Août 2026 : toujours rien.

Seize ans. Dans ce temps l’entreprise a été achetée, fusionnée avec O2, a reconstruit son cœur deux fois et remplacé tout son parc de routeurs. À aucun moment personne n’a ajouté une famille d’adresses. Verrouiller le fil est la chose la plus honnête de cette liste. C’est le moment où ils ont cessé de faire semblant et se sont mis à gérer la plainte au lieu du problème.

Les altnets n’avaient aucune excuse du tout

Les bâtisseurs de fibre complète étaient la chance de partir propre. Nouveaux réseaux, nouveau matériel, pas d’héritage, des ingénieurs embauchés cette décennie. Regardez où ils siègent dans la table d’allocation et la plupart ont pris l’espace d’adressage et se sont arrêtés.

Donc une entreprise qui a levé de l’argent institutionnel pour bâtir un tout nouveau réseau de fibre a creusé les routes, soufflé de la fibre vers cent mille foyers, acheté de nouveaux routeurs, écrit une nouvelle pile de provisionnement. Et a mis ses clients derrière une adresse partagée sur un réseau sans IPv6, en 2026, avec l’espace d’adressage déjà posé dans son propre compte de registre.

Et puis plusieurs d’entre eux facturent 5 £ par mois pour une IPv4 publique statique.

Ils ont retiré la chose qui marchait, refusé de livrer le remplacement gratuit, et transformé la casse qui en résulte en une ligne sur votre facture. Il y a un mot pour un modèle d’affaires qui fabrique un défaut puis vend le correctif, et ce n’est pas « innovation ».

Les sites web vendent la mèche

La table de routage montre ce que les réseaux font. Le DNS montre ce que tous les autres font. Donc le 27 août 2026 j’ai mis cinquante des sites britanniques les plus connus dans un fichier — administration centrale, les banques, les grands détaillants, les télécoms, les transports et quelques universités — et j’ai demandé à chacun s’il répond en IPv6 :

while read -r d; do
  n=$(dig +short AAAA "$d" | grep -c ':')
  printf '%-46s %s\n' "$d" "$([ "$n" -gt 0 ] && echo AAAA || echo none)"
done < sites.txt | sort -k2

Puis j’ai vérifié chaque réponse contre un second résolveur, parce qu’un serveur récursif ayant une mauvaise journée n’est pas une conclusion :

dig @1.1.1.1 +short AAAA www.tesco.com | grep -c ':'

Dix-sept sur cinquante avaient un enregistrement AAAA. Trente-trois n’en avaient pas, et les deux résolveurs étaient d’accord sur chacun.

Ceux sans IPv6 incluent www.bbc.co.uk, www.nhs.uk, www.hmrc.gov.uk, www.hsbc.co.uk, www.barclays.co.uk, www.lloydsbank.com, www.santander.co.uk, www.tesco.com, www.johnlewis.com, www.marksandspencer.com, www.britishairways.com, tfl.gov.uk, monzo.com — une banque fondée en 2015, sans aucun héritage — et, mon préféré, www.sky.com.

Sky. L’entreprise qui a mis cinq millions de clients sur IPv6 et gagné un prix pour ça. Son propre site web ne répond pas en IPv6.

Maintenant le morceau qui prouve la thèse au-delà de toute discussion.

Quinze des dix-sept qui ont bien IPv6 l’ont eu d’un fournisseur, pas d’eux-mêmes. J’ai résolu chacun et cherché qui possède l’adresse qui a répondu :

whois -h whois.radb.net -- "$(dig +short AAAA www.sainsburys.co.uk | grep ':' | head -1)" | grep -i descr

www.gov.uk et www.cam.ac.uk répondent depuis Fastly. ico.org.uk, www.parliament.uk, www.ofcom.org.uk, www.asda.com, www.autotrader.co.uk, www.nationalrail.co.uk et www.jisc.ac.uk répondent depuis Cloudflare, qui allume IPv6 pour tout le monde par défaut. natwest.com et nationwide.co.uk répondent depuis Azure Front Door. www.legalandgeneral.com et www.screwfix.com répondent depuis CloudFront. www.sainsburys.co.uk et www.next.co.uk répondent depuis Akamai.

Deux l’ont fait eux-mêmes : Imperial College London, répondant depuis son propre espace d’adressage, et le propre site web du UK IPv6 Council. Une université et les gens dont tout le but est IPv6. C’est ça la liste.

Et www.tesco.com, www.sky.com et www.nhs.uk siègent aussi sur Akamai — le même CDN, le même produit — et n’ont aucun IPv6 du tout.

Akamai est explicite là-dessus depuis juin 2022 : « Akamai has enabled IPv4+IPv6 dual-stack as the default for our CDN delivery products for many years, meaning that customers have needed to opt-out for content to be IPv4-only » — Akamai a activé la double pile IPv4+IPv6 par défaut pour ses produits de livraison CDN depuis de nombreuses années, ce qui veut dire que les clients ont dû se désinscrire pour que le contenu soit uniquement IPv4. Ils ont ajouté qu’ils ont rendu le changement facile, y compris par l’API.

Même fournisseur. Même plateforme. Activé par défaut. Une organisation l’a laissé tranquille et une autre est entrée et l’a éteint, ou a gardé une config ancienne que personne n’a lue depuis. Sainsbury’s a IPv6 et Tesco non, et la différence entre eux est un seul drapeau de configuration et l’attention de quelqu’un.

Après ça il ne reste debout aucun argument de coût et aucun argument de complexité. Il ne reste que de savoir si quelqu’un faisait attention.

Sur tout l’échantillon la règle tient : là où IPv6 arrive comme le défaut d’un fournisseur, la Grande-Bretagne l’a. Là où une organisation britannique aurait eu à décider quelque chose, elle ne l’a pas. Deux sites sur cinquante, et l’un de ceux-là était le IPv6 Council.

Ce qui nous amène à l’industrie du service géré

Les FAI grand public reçoivent le blâme pour le CGNAT, et ils l’ont mérité. Mais la couche qui fait le plus de dégâts est celle qui vend l’expertise : les prestataires de services gérés, les intégrateurs, les équipes réseau externalisées, les cabinets de conseil qui écrivent la conception de bas niveau.

Revenez à la liste des plus grands réseaux britanniques sans IPv6 — les banques, British Airways, PwC, QinetiQ. Ce ne sont pas des jeunes pousses débrouillardes. Ce sont des structures qui paient beaucoup d’argent pour que quelqu’un d’autre fasse tourner leur réseau, ou emploient une grande équipe pour le faire elles-mêmes. Chacun de ces numéros d’AS a un document de conception derrière, un processus de changement, un comité de revue d’architecture, et un fournisseur avec « réseau » dans son nom. Pas un d’entre eux n’a produit un plan IPv6.

Le schéma est le même partout où on le regarde :

Le gabarit est IPv4. La norme de construction, le jeu de règles de pare-feu, les contrôles de surveillance, l’IPAM, le runbook, le plan de reprise, le dossier de passation client — tout IPv4, écrit une fois, cloné pendant une décennie. Ajouter une famille d’adresses veut dire tout éditer, et personne n’est payé pour l’éditer.

Personne ne l’a demandé. C’est la phrase qui met fin à chaque conversation IPv6 dans cette industrie, et c’est un aveu. Personne n’a demandé TLS 1.3 non plus. Personne ne vous a demandé de cesser d’utiliser SMBv1. Les clients achètent le résultat et vous paient pour savoir ce que le résultat exige. « Le client n’a pas demandé » veut dire « je ne veux pas l’apprendre et ils ne peuvent pas le dire ».

Le RFC 1918 semble infini. Le dix-point, c’est 16,7 millions d’adresses, donc un réseau interne ne semble jamais court, donc il n’y a jamais d’événement déclencheur. Puis la fusion arrive, les deux parcs sont sur 10.0.0.0/8, et la réponse est une décennie de plus de NAT de sous-réseaux chevauchants et un document expliquant quelle fausse adresse veut dire quelle vraie — plus de machinerie, encore, pour éviter la famille d’adresses qui en aurait fait un non-problème.

IPv6 expose la compétence. C’est la vraie. La double pile ne vous laisse pas vous cacher.

Vous devez savoir ce qu’est réellement votre politique de pare-feu, parce que vous devez l’écrire deux fois. Vous devez savoir à quoi ressemble votre DNS. Vous devez comprendre la découverte de voisins, la délégation de préfixe, et ce que votre CPE fait d’un /56.

Un ingénieur qui s’est débrouillé avec le NAT comme contrôle de sécurité accidentel découvre, devant des gens, qu’il n’en a jamais été un. Il y a des carrières de vingt ans dans cette industrie bâties sur cette seule confusion.

Donc ce n’est pas proposé. Pas parce que ça coûte de l’argent — ce n’est pas le cas — mais parce que le proposer veut dire le posséder, et le posséder veut dire l’apprendre.

C’est ce que j’entends par fainéant jusqu’à l’os. Pas paresseux au sens de ne pas travailler dur. Cette industrie travaille extrêmement dur. Elle travaille dur au NAT à l’échelle opérateur, et à expliquer à un client pourquoi sa vidéosurveillance ne se connectera plus de l’extérieur. Elle fera n’importe quelle quantité de travail, tant que le travail est du genre qu’on peut acheter plutôt que du genre qu’on doit comprendre.

Et ça va cesser d’être affaire de goût. Le Cyber Security and Resilience Bill qui passe maintenant au Parlement amenderait les NIS Regulations pour tirer, entre autres, les « managed service providers (organisations that provide third-party IT services to other businesses) » — prestataires de services gérés (organisations fournissant des services informatiques tiers à d’autres entreprises). Ce n’est pas encore la loi. Quand ce le sera, la détection, la journalisation et le signalement d’incident cessent d’être des gammes de produits que cette couche vend et deviennent des devoirs qu’elle doit remplir.

Mettez ça à côté de la chaîne plus haut. Résoudre tout signalement d’abus commence par un serveur distant ayant journalisé un port source, et le serveur distant est très souvent la boîte d’une de ces structures. Les gens qui devront bientôt prouver qu’ils peuvent détecter et signaler un incident sont les mêmes qui ne peuvent présentement pas être amenés à activer une famille d’adresses, ou à lire une capture de paquets quand un tunnel ne veut pas monter.

Les trois excuses

Vous entendrez les mêmes trois à chaque fois, et aucune ne tient une minute.

« La double pile, c’est deux de tout. » Je l’ai fait tourner en production chez Nominet, sur des répartiteurs de charge F5 devant le registre .uk, donc je sais ce que vaut l’objection. Le niveau NAT que vous avez acheté à la place aussi, et celui-là siège dans le chemin du trafic avec une table de session, un modèle de capacité, une histoire de bascule et une obligation de journalisation attachée. Vous ne choisissiez jamais entre complexité et simplicité. Vous avez choisi la complexité qui venait avec une facture.

« Le matériel ne le supporte pas. » En 2006, admettons. En 2026 ça veut dire que votre matériel est hors support, ce qui est une pire chose à admettre que celle que vous essayiez d’éviter de dire.

« Il n’y a pas de revenu dedans. » Il n’y a pas de revenu dans les sauvegardes non plus.

Les choses que les gens publient

Les excuses ci-dessus sont ce que vous entendez en réunion. Dessous siège une couche d’affirmations techniques qui se répètent dans les fils de forum, les sections de commentaires et les réponses LinkedIn chaque fois qu’IPv6 revient, et la plupart sont fausses depuis plus d’une décennie.

Une partie est de l’honnête confusion et une partie est une personne qui a décidé de ne pas apprendre quelque chose saisissant une raison. Dans un cas comme l’autre ça vaut de le parcourir, parce que ces affirmations font un vrai travail. C’est ce qu’un ingénieur répète à un manager qui ne peut pas les vérifier.

« Le NAT est mon pare-feu. IPv6 met chaque appareil directement sur internet. »

C’est la grosse et elle est à l’envers. La protection que les gens attribuent au NAT vient de ce qu’il n’y a pas de correspondance jusqu’à ce que quelque chose à l’intérieur en demande une — ce qui est un pare-feu à états, et c’est le pare-feu qui fait le travail, pas la traduction. L’IETF l’a dit dans le RFC 4864 en 2007 : ce rôle, « often marketed as a firewall, is really an arbitrary artifact » — souvent commercialisé comme un pare-feu, est vraiment un artefact arbitraire —, là où un vrai pare-feu vous donne « explicit and more comprehensive management controls » — des contrôles de gestion explicites et plus complets.

Chaque routeur IPv6 grand public est livré avec refus par défaut en entrée. Vous obtenez la même posture, d’une politique que quelqu’un a couchée sur le papier, plutôt que d’un effet de bord d’avoir manqué d’adresses. Et vous pouvez alors permettre exactement la seule chose que vous vouliez permettre, au lieu de la séance de spiritisme de redirection de ports.

Si tout votre modèle de sécurité est « les attaquants ne peuvent pas trouver mes appareils », vous n’aviez pas de modèle de sécurité. Vous aviez du NAT.

« IPv6 est plus lent. »

Celle-ci mérite une réponse honnête plutôt qu’un rejet, parce que la vérité est mitigée et les gens qui la font ne sont pas simplement dans l’erreur.

Les fournisseurs de contenu qui l’ont optimisé mesurent des gains : Facebook a rapporté des chargements de page environ 15 % plus rapides en IPv6, Akamai environ 5 % sur mobile. La mesure plus large de tout l’internet par APNIC est moins flatteuse et donne des temps d’aller-retour IPv6 marginalement plus élevés en moyenne — de l’ordre d’une milliseconde environ, et s’améliorant avec le temps.

Donc : globalement à égalité, meilleur là où quelqu’un a fait le travail, occasionnellement un cheveu pire là où personne ne l’a fait.

Il vaut de savoir où le coût siège réellement, parce que l’en-tête est la chose que les gens imaginent et l’en-tête n’est pas le problème.

Les en-têtes IPv4 et IPv6, et ce que chacun coûte à un routeurLes deux en-têtes, et ce que chacun coûte à un routeurChamps à l'échelle sur 32 bits. Sources : RFC 791 (IPv4) et RFC 8200 (IPv6).travail du routeur à chaque sautclé de recherche plus largeIPv420 octets, jusqu'à 60 avec options031VersionIHLType of ServiceTotal LengthIdentificationFlagsFragment OffsetTime to LiveProtocolHeader ChecksumSource AddressDestination AddressOptions — variable length, 0 to 40 more bytesIPv640 octets, fixe. Toujours.031VersionTraffic ClassFlow LabelPayload LengthNext HeaderHop LimitSource Address (128 bits)Destination Address (128 bits)IPv4 fait recalculer au routeur la somme de contrôle à chaque saut, lire un champ de longueur avant de savoir oùcommence la charge, et un chemin de fragmentation. IPv6 abandonne les trois — pour une clé quatre fois plus large.
Les deux en-têtes côte à côte, champs dessinés à l’échelle sur 32 bits. En orange, le travail qu’un routeur doit faire à chaque saut ; en bleu, la clé de recherche plus large.

Commencez par ce qu’IPv6 a retiré au routeur. IPv4 porte une somme de contrôle d’en-tête. Le Time to Live change à chaque saut, donc la somme de contrôle doit changer avec, et le RFC 6583 liste « verifying and updating the checksum » — vérifier et mettre à jour la somme de contrôle — comme une étape du processus de retransmission lui-même. IPv6 n’en a aucune. Cette étape disparaît juste.

Puis la longueur. Un en-tête IPv4 est variable, ce qui est à quoi sert l’IHL : un routeur lit une longueur avant de savoir où commence la charge utile. Un en-tête IPv6 fait 40 octets. Toujours. Chaque champ siège à un décalage fixe et rien n’a à être calculé d’abord.

Puis la fragmentation. Les routeurs IPv4 peuvent fragmenter en vol, ce qui est pourquoi Identification, Flags et Fragment Offset siègent dans l’en-tête tout court. Le RFC 8200 est net : « fragmentation in IPv6 is performed only by source nodes, not by routers along a packet’s delivery path » — la fragmentation en IPv6 n’est faite que par les nœuds source, pas par les routeurs le long du chemin de livraison. Donc ce chemin disparaît aussi.

Sur la seule gestion d’en-tête IPv6 est le protocole le moins cher à retransmettre. Il a été bâti pour l’être.

Le seul endroit où il coûte plus est par route, et ça s’avère ne pas compter. La clé de recherche est passée de 32 bits à 128, donc une entrée de retransmission IPv6 est plus large et sur beaucoup de matériel prend deux emplacements matériels là où une route IPv4 en prend un. Tout le monde arrête l’argument là. Il vaut d’aller un pas plus loin, parce que la table complète est quatre fois plus petite.

Sur le vidage RIS généré à 02 h 03 UTC le 28 août 2026 il y avait 1 229 166 préfixes IPv4 dans la table de routage mondiale et 300 470 IPv6. Quatre fois plus de routes IPv4, chacune d’un quart de la largeur. Donc le stockage brut des clés arrive à égalité parfaite : 4,92 Mo contre 4,81 Mo. Maintenant appliquez la règle des deux-emplacements-par-route-IPv6 qui inquiète les gens. Une table IPv6 complète a encore besoin d’environ la moitié des entrées matérielles d’une IPv4 complète.

Et la raison pour laquelle la table IPv4 est si grande est la pénurie elle-même. 767 543 de ces 1,2 million de routes sont des /24 — 62 % de tout l’internet IPv4 siégeant au préfixe le plus long que quiconque acceptera, parce que des blocs ont été découpés, vendus et annoncés en morceaux par qui les a achetés. Chacun d’eux est un routeur quelque part tenant une entrée dont il n’aurait pas besoin si l’espace n’avait pas manqué.

La table de routage IPv4 est quatre fois plus grande que celle d'IPv6La table de routage IPv4 est quatre fois plus grande — et l'essentiel est la pénuriePréfixes distincts dans la table de routage mondiale, vidage RIPE RIS généré à 02 h 03 UTC, 28 août 2026.IPv4clé 32 bits767 543 sont des /241 229 166IPv6clé 128 bits300 470Quatre fois plus de routes IPv4, chacune d'un quart de la largeur — donc le stockage brut des clés est àégalité, 4,92 Mo contre 4,81 Mo.Comptez une route IPv6 comme deux entrées matérielles, comme les gens le craignent, et une tableIPv6 complète a encore besoin d'environ la moitié.62 % de la table IPv4 sont des /24 — des blocs découpés, vendus et annoncés en morceauxparce que l'espace a manqué. Chacun est une entrée qu'un routeur ne tiendrait pas sinon.
Préfixes distincts dans la table de routage mondiale le 28 août 2026, comptés depuis le vidage RIS de RIPE. La partie pleine de la barre IPv4 est les /24 — la désagrégation que la pénurie d’adresses a forcée.

Donc l’argument mémoire tourne dans le sens inverse de comment il se raconte en réunion. Porter IPv6 est moins cher sur votre FIB que porter IPv4, et ça devient moins cher chaque année où le marché du transfert tranche un /16 de plus en seize /24.

Et les pics de CPU que les gens frappent réellement ne sont ni l’un ni l’autre. Un routeur moderne retransmet les deux familles en silicium à débit ligne. Ce qui fait mal est tout ce qui pousse un paquet hors de ce chemin vers le plan de contrôle, que le RFC 6583 appelle « a ‘slower’ software process running on a general purpose processor » — un processus logiciel « plus lent » tournant sur un processeur généraliste. Ce processeur a été dimensionné pour les protocoles de routage. Jamais pour le trafic.

Deux choses lui poussent des paquets. La première est les en-têtes d’extension. Ils sont une chaîne plutôt qu’un bloc fixe, donc une boîte voulant les ports de couche 4 pour une ACL ou un hachage ECMP doit parcourir une liste de longueur variable pour les trouver, et un en-tête Hop-by-Hop Options « may be examined or processed by any node along a packet’s delivery path » — peut être examiné ou traité par tout nœud le long du chemin de livraison. Sur beaucoup de matériel ça veut dire dérouté.

La seconde est la découverte de voisins. Un /64 couvre des milliers de milliards d’adresses qui ne seront jamais assignées, donc en scanner un met un routeur à résoudre des adresses qui n’existent pas. Le RFC 6583 existe pour ça, et l’appelle un déni de service.

Les deux ont des réponses connues. Filtrer le Hop-by-Hop en bordure, limiter le débit de la ND, plafonner le cache de voisins. Aucune n’est une raison pour laquelle le protocole est lent. Ce sont des raisons pour lesquelles un routeur non configuré est lent, et ça pointe là où le reste de ce billet pointe.

Maintenant pesez une milliseconde contre l’alternative que vous avez réellement déployée — une boîte de traduction à états dans le chemin de chaque connexion, tenant une table de session, qui en casse certaines carrément. Personne n’a stagné vingt ans pour une milliseconde.

« Il y a plein d’IPv4 dans la nature, vous pouvez juste en acheter. »

Vous pouvez. C’est à quoi une pénurie ressemble. Des blocs distribués pour rien en 1990 changent maintenant de mains à environ 20 $ l’adresse, et AWS facture 43,80 $ par an pour chacune que vous utilisez.

Un marché d’une chose ne prouve pas qu’il y en a plein. Il prouve que quelqu’un a compris comment vous facturer la pénurie.

Personne n’allait jamais les y obliger

Le Royaume-Uni n’a aucune politique là-dessus, et n’en a jamais eu.

Il y a eu une tentative. 6UK a été monté en 2010 avec 20 000 £ d’argent d’amorçage du Department for Business, Innovation and Skills, soutenu par Vint Cerf, avec LINX, AAISP, Timico et Easynet derrière. En décembre 2012 ses administrateurs bénévoles ont démissionné à l’assemblée générale, personne ne s’est présenté au conseil, et il a été dissous. Son verdict d’adieu : les incitations du marché libre sont insuffisantes, « one factor appears to dominate IPv6 adoption rates, namely government support » — un facteur semble dominer les taux d’adoption d’IPv6, à savoir le soutien du gouvernement —, et « countries with hands-off governments fall behind » — les pays aux gouvernements non interventionnistes prennent du retard.

Quatorze ans plus tard, c’est exactement ce qui est arrivé. Le UK IPv6 Council tourne encore, mais un forum n’est pas un levier.

Comparez les États-Unis, où le mémorandum M-21-07 de l’OMB exigeait que 80 % des actifs fédéraux compatibles IP soient uniquement IPv6 pour la fin de l’exercice budgétaire 2025. Les agences l’ont raté. Elles avaient quand même un chiffre à rater, une date pour le rater, et quelqu’un qui doit se lever et expliquer le raté. Ici il n’y a rien à rater, donc personne n’a jamais eu à expliquer quoi que ce soit.

Le gouvernement britannique n’exige pas IPv6 dans son propre achat d’aucune façon significative. L’Ofcom ne le mesure pas. Aucun régulateur ne le demande. Et donc, comme prévu, www.nhs.uk et www.hmrc.gov.uk ne l’ont pas, tandis que www.gov.uk l’a. Et www.gov.uk ne l’a que parce qu’il est servi via Fastly, qui a allumé IPv6 il y a des années pour le compte de quelqu’un d’autre.

J’ai écrit avant sur ce qui arrive quand personne ne tient de contrat sur une industrie — les mécanismes qui marchent s’avèrent être ceux que quelqu’un doté de ressources choisit d’actionner, et si personne ne le fait, rien n’arrive pendant une décennie. IPv6 au Royaume-Uni est ce schéma encore, sans même un vote de membres à la fin.

Et ce n’est pas que personne n’a remarqué

L’absence d’une exigence serait décevante si ça avait échappé à l’attention. Ce ne fut pas le cas.

L’État a compris ce que fait le NAT à l’échelle opérateur et a légiféré à son sujet. Le Parlement a regardé le problème droit dans les yeux, l’a compris assez bien pour écrire une loi dessus, et a écrit la loi qui accommode la casse. « Exiger d’eux qu’ils déploient le protocole qui la supprime » n’a soit jamais été soulevé, soit été soulevé et abandonné.

Donc nous sommes un pays dont la position déclarée est que l’attribution IP compte assez pour une législation antiterroriste, et qui ne demande pas à un seul fournisseur de faire la chose gratuite qui la restaure. Fraude, prise de contrôle de compte, harcèlement, menaces de mort, signalements d’abus d’enfants et terrorisme arrivent tous au réseau d’accès en posant la même question, et pour beaucoup de connexions britanniques la réponse honnête est « un de ces plusieurs centaines de foyers ».

Le National Cyber Security Centre fait partie du GCHQ et publie des recommandations sur un grand nombre de choses. Il n’exige IPv6 de personne. Personne en Grande-Bretagne ne le fait.

www.ncsc.gov.uk et www.gchq.gov.uk répondent bien tous deux en IPv6, cela dit. L’Internet Watch Foundation aussi. Les trois parce qu’ils siègent derrière Cloudflare, qui l’a allumé pour tout le monde par défaut. www.police.uk n’en a aucun.

Et ce que ça veut dire pour les dix-sept

Dix-sept des quarante fournisseurs de ce billet vendent des connexions sans IPv6, et environ la moitié des bâtisseurs de fibre complète mettent des clients derrière un NAT à l’échelle opérateur.

Je n’accuse aucun d’eux d’un crime, et personne dans ces bâtiments n’en espère un.

Mais une connexion derrière un NAT à l’échelle opérateur sans IPv6 ne peut pas être résolue à un abonné. Ce n’est pas contesté. L’IETF l’a couché sur le papier en 2011, Europol en 2016 et 2017, le Parlement en 2015 — tout ça publié avant que l’essentiel de cet équipement ne soit acheté. L’alternative était gratuite, et disponible tout le temps.

C’est ce que « on s’occupera d’IPv6 un jour » veut dire, une fois qu’on le suit jusqu’au bout.

Que faire, concrètement

Court, parce que rien n’est dur. C’est tout l’intérêt du billet.

Si vous achetez de la connectivité : mettez IPv6 dans l’appel d’offres comme une exigence éliminatoire, pas un bonus. Demandez une double pile native et un préfixe délégué, par écrit, et demandez de quelle taille.

Si la réponse est un seul /64, continuez de demander. Le RFC 6177 a tué celle-là en 2011 : remettre à un site résidentiel un /64 « precludes the expectation that even home sites will grow to support multiple subnets » — exclut l’attente que même les sites résidentiels croissent pour supporter plusieurs sous-réseaux —, et il est « strongly intended that even home sites be given multiple subnets worth of space, by default » — fortement voulu que même les sites résidentiels reçoivent l’équivalent de plusieurs sous-réseaux d’espace, par défaut.

Ce qu’il n’a pas fait, c’est nommer une taille. Il a retiré l’ancien /48 systématique, dit que le choix « is an issue for the operational community » — est une question pour la communauté opérationnelle —, et lâché un exemple concret au passage : un défaut résidentiel « of less than /48, such as a /56 » — de moins d’un /48, tel qu’un /56.

Les opérateurs y ont répondu eux-mêmes. Le RIPE-690 est leur propre document de pratique et il est net. Un /48 chacun si vous voulez un plan simple. Un /48 pour les entreprises et un /56 pour le résidentiel si vous voulez un plan pragmatique. Tout plus long qu’un /56 est « strongly discouraged » — fortement déconseillé —, et un /64 ne se conforme pas aux normes IPv6 et cassera les LAN des clients.

Donc le plancher est un /56, et c’est le propre chiffre de l’IETF plutôt que la préférence de quiconque. Sky en remet un à chaque abonné depuis 2016. Zen distribue un /48, ce qui fait 65 536. Une entreprise ne devrait pas accepter moins qu’un /48.

Si un fournisseur vous dit qu’un /48 pour une maison est extravagant, un FAI britannique le fait depuis des années pendant qu’ils travaillaient encore sur leur position.

Si vous faites tourner un numéro d’AS : vous détenez probablement déjà un /29 que vous n’avez jamais annoncé. Vérifiez.

AS=AS20712                                    # your AS number
ORG=$(whois -h whois.ripe.net "$AS" | awk '/^org:/{print $2; exit}')

# what IPv6 the registry has already given you
whois -h whois.ripe.net -- "-i org $ORG" | grep -i '^inet6num'

# what you are actually announcing of it
whois -h whois.ripe.net -- "-i origin $AS" | grep -i '^route6'

Si la première commande imprime un préfixe et la seconde n’imprime rien, vous êtes l’un des 463.

Annoncez-le, mettez votre bordure et un VLAN interne en double pile, et posez un AAAA sur un service public. C’est une quinzaine de travail pour un ingénieur et ça transforme votre organisation d’une statistique dans la table ci-dessus en une qui a commencé.

Si vous faites tourner un site web : vérifiez un enregistrement AAAA. Si vous êtes derrière un CDN, c’est probablement un interrupteur que vous pouvez allumer cet après-midi sans coût. S’il est éteint, quelqu’un l’a éteint.

Si vous vendez des services gérés : écrivez IPv6 dans la norme de construction et le gabarit de conception de bas niveau, une fois, et chaque client après ça l’obtient par défaut. Personne n’a à le demander, parce que personne ne demande TLS non plus.

Si vous êtes un ingénieur qui ne l’a jamais fait : montez un labo ce soir. Environ 90 % de mon propre trafic passe par IPv6 natif et c’est la chose la moins mouvementée de mon réseau. Prenez un tunnel ou un VPS avec un /64, posez des adresses sur des choses, cassez-le, réparez-le. Ça prend une soirée pour cesser d’être effrayant et c’est la chose la moins chère que vous puissiez faire à votre carrière cette année.

Les questions que je ne peux pas trancher

Tout ce qui précède je peux vous le montrer. Cette partie est le morceau que je continue de retourner, et je n’ai de réponse propre à aucun d’eux.

Pourquoi certains et pas d’autres ?

C’est celle qui compte, et les données la rendent plus étrange plutôt que plus claire.

Sky et Virgin Media ont vendu du haut débit au même pays, sous le même régulateur, au même moment. L’un a fini en 2016. L’autre dit « quand nous serons prêts » depuis 2010. Sainsbury’s et Tesco siègent sur le même CDN, sur un produit où la double pile est le défaut, et l’un a IPv6 et l’autre non. La Norvège et la Grande-Bretagne achètent aux mêmes fournisseurs et 66,9 % des réseaux norvégiens portent IPv6 contre 42,3 % des nôtres.

Chaque facteur externe que vous pourriez blâmer est tenu constant dans ces paires. Même pays, mêmes fournisseurs, même matériel, mêmes clients, même décennie, même régulateur, même argent. Et les résultats sont opposés.

Donc la cause n’est pas dans les circonstances. Elle est à l’intérieur du bâtiment. Quelque part chez Sky il y avait une personne qui en a fait son affaire et a continué d’en faire son affaire pendant trois ans. Dans les autres endroits il n’y en avait pas, ou il y en avait une et personne au-dessus d’elle ne s’en souciait. C’est toute la variable, et elle n’est pas technique.

Ce qui est une réponse inconfortable, parce que vous ne pouvez pas l’acheter, et vous ne pouvez pas la mettre dans un document de stratégie.

Est-ce la formation ?

En partie, et moins que vous ne le penseriez.

Regardez de nouveau les 463 structures détenant un IPv6 qu’elles n’ont jamais annoncé. Quelqu’un dans chacun de ces bâtiments en savait assez pour savoir qu’il en avait besoin, savait à qui demander, a rempli le formulaire, et l’a fait émettre. La connaissance était là et le suivi n’y était pas.

La formation amène un ingénieur au point d’être capable. Elle ne l’amène pas au point d’y être obligé. Personne n’a jamais eu une mauvaise évaluation pour ne pas avoir déployé IPv6. Personne n’a jamais perdu un contrat dessus. Jusqu’à ce qu’une de ces choses soit vraie, la formation va sur la pile avec tout le reste que quelqu’un a appris à un cours et n’a jamais utilisé.

Combien de temps jusqu’à ce que nous y soyons tous ?

Je peux mettre un chiffre sur celle-ci, et il est pire que je m’y attendais.

Google mesure la part de ses propres visiteurs arrivant en IPv6 depuis 2008. En prenant mi-août chaque année, pour que ce soit comparable :

L'adoption mondiale d'IPv6 décélère avant la moitiéL'adoption mondiale d'IPv6 ralentit, elle n'accélère pasPart des propres visiteurs de Google en IPv6 natif, mi-août chaque année. Source : statistiques IPv6 de Google.0 %10 %20 %30 %40 %50 %201718,1 %20182019202020212022202320242025202648,1 %Points ajoutés cette année-là+3,6+5,0+4,4+3,3+4,3+3,3+2,3+2,6+1,1Cette année a ajouté 1,1 point, le plus petit gain en une décennie, contre 6,6 points dans l'année jusqu'à août 2017.
La mesure par Google de ses propres visiteurs arrivant en IPv6 natif, prise mi-août chaque année pour que ce soit comparable. La ligne est le niveau. Les barres sont ce que chaque année a ajouté.

Nous n’accélérons pas vers la ligne d’arrivée. Nous décélérons avant la moitié. Cette année a ajouté 1,1 point, le plus petit gain en une décennie, contre 6,6 points dans l’année jusqu’à août 2017.

Tirez une ligne droite des trois dernières années et le monde atteint 100 % en 2049. Tirez-la de cette seule année et c’est 2073. Ni l’une ni l’autre n’est une prévision. Une courbe qui s’aplatit n’atteint pas le sommet par dérive du tout. Elle stagne quelque part dans les soixante et le reste ne bouge jamais, parce que les réseaux qui ne l’ont pas fait d’ici là sont ceux que rien n’allait jamais faire bouger.

J’adorerais avoir tort là-dessus. Le chiffre est devenu plus petit chaque année où je l’ai regardé.

Faut-il une loi ?

C’est celle sur laquelle j’ai le plus hésité, et j’ai atterri sur « pas la loi que les gens saisissent ».

Contre un mandat : les Américains ont voté le plus fort que quiconque ait, et l’ont raté. Une échéance n’est pas un déploiement.

Pour un : le verdict d’adieu de 6UK en 2012 était que les incitations du marché libre sont insuffisantes et que les pays qui prennent du retard sont ceux aux gouvernements non interventionnistes. Quatorze ans de données britanniques leur donnent raison.

Et voici la partie qui tranche. Ce pays a déjà légiféré sur ce problème — il a juste légiféré dans le mauvais sens. Nous étions prêts à légiférer pour accommoder le partage d’adresses. Nous n’avons jamais été prêts à légiférer pour le supprimer.

Ce que je demanderais n’est pas une interdiction et pas une cible, mais l’instrument belge décrit plus haut : une limite dure au nombre d’abonnés pouvant partager une adresse. Il n’a besoin d’aucune nouvelle adresse, il ne ferme personne hors du marché, et il agit sur l’économie plutôt que sur les bonnes intentions de quiconque.

Un mandat en soi produit une chose utile, et ce n’est pas le déploiement. C’est une personne nommée qui doit expliquer le raté. Nous n’en avons jamais eu.

Comment sommes-nous passés à IPv4 si vite, alors ?

Parce que quelqu’un pouvait éteindre l’ancien.

La comparaison est exacte, et presque personne ne la fait. L’ARPANET faisait tourner le Network Control Program, qui adressait les hôtes en 8 bits — 6 pour le nœud et 2 pour l’hôte, donc 64 nœuds de 4 machines, 256 hôtes au total. À la fin des années 1970 ce n’était manifestement pas assez, et la réponse a été un nouveau protocole avec une adresse plus grande. Le même problème que nous avons maintenant, quarante et quelques années plus tôt.

Jon Postel a publié le plan de transition en novembre 1981. En mars 1982 le Department of Defense américain a déclaré TCP/IP sa norme officielle. Les deux protocoles tournaient côte à côte, et le 1er janvier 1983 NCP a été éteint. Les hôtes qui n’avaient pas converti ont perdu l’accès au réseau. Vint Cerf se souvient de badges « I survived the TCP/IP switchover » — j’ai survécu à la bascule TCP/IP — portés ensuite par les gens qui l’ont traversée.

Quatorze mois du plan au jour du drapeau.

Maintenant comptez ce qui a rendu ça possible. Environ deux cents hôtes, pas quatre milliards. Un réseau, pas tous les réseaux. Un financeur qui possédait chaque machine dessus et payait les salaires de tous ceux qui y touchaient. Une seule organisation capable de fixer une date, et — c’est le morceau qui compte — capable de faire cesser de marcher l’ancien protocole à cette date.

Aucune de ces choses n’existe maintenant, et c’est toute la réponse. IPv4 n’a pas gagné parce que la migration était facile. Il a gagné parce qu’il y avait quelqu’un en position de mettre fin à l’argument.

Personne n’est dans cette position aujourd’hui. Il n’y a pas d’autorité qui puisse éteindre IPv4, et il n’y en aura jamais. Ce qui veut dire que cette transition ne peut pas être finie comme la dernière l’a été — elle ne peut être finie que par plusieurs milliers de structures décidant chacune, seule, de s’en donner la peine.

Sur les chiffres de cette année, ça atterrit en 2073. Quatre-vingt-dix ans après le jour du drapeau.

Nous faisions les choses proprement, avant

Une norme est quelque chose qu’on tient quand personne ne vérifie. C’est tout. Il n’y a pas d’inspecteur pour ça, pas de certificat, pas d’auditeur qui se présente et demande à voir votre table de routage, et vingt ans ont maintenant montré exactement ce que ce pays fait d’une obligation que personne n’impose.

On la laisse tomber, et puis on achète quelque chose pour couvrir l’écart.

Rien de tout ça n’est un échec technique et je ne prétendrai pas que c’en est un. La Grande-Bretagne peut faire ce travail. Les compétences sont là, le matériel est là, l’espace d’adressage est émis et posé à attendre dans des comptes que nous payons déjà. Ce qui est parti, c’est l’instinct de faire un travail proprement parce que c’est le travail — sans être payé en plus pour ça, et sans quelqu’un debout au-dessus de vous vous y forçant.

Demandez ce qui l’arrête réellement et vous atterrissez sur l’argent, mais pas au sens où les gens l’entendent.

Un NAT à l’échelle opérateur a un bon de commande. Il a un fournisseur, un devis, une remise, un contrat de support et une date de renouvellement. Il va dans le plan de capital, il se déprécie sur cinq ans, et le nom de quelqu’un siège sur l’argument commercial. Le livrer est une chose visible qu’un manager peut montrer du doigt dans une évaluation.

IPv6 n’a rien de ça. Pas de facture, pas de fournisseur, pas de renouvellement, rien à mettre dans un budget et rien que quiconque puisse être vu avoir acheté. C’est juste du travail, fait proprement, par des gens qui savent ce qu’ils font, pour aucun retour ce trimestre. Personne dans cette industrie n’a jamais été promu pour une chose qui n’est jamais apparue dans un budget.

À ce titre l’option la moins chère perd, chaque année, pendant vingt ans. Pas parce que quelqu’un l’a pesée et a mal choisi, mais parce qu’une culture de gestion a grandi ici qui ne peut voir que les parties de l’ingénierie qui arrivent avec un prix dessus. Bon marché n’a jamais été l’obstacle. Non facturable l’était. C’est à ça que ça ressemble quand une entreprise cesse de se soucier des normes et se met à ne se soucier que de ce qu’elle peut mettre sur une facture, et c’est un choix fait par des gens payés assez bien pour savoir mieux.

Puis il y a ce qu’ils nous ont vendu à la place d’une adresse, ce qui devrait mettre les gens plus en colère que ça ne le fait.

L’internet a été bâti pour que n’importe quelle machine puisse atteindre n’importe quelle autre machine directement. Pas un détail de la conception. La conception. C’est pourquoi n’importe qui avec une connexion et une idée pouvait mettre en ligne quelque chose que le monde entier pouvait atteindre. Mettez un client derrière une adresse partagée et c’est parti. Vous pouvez demander, mais vous ne pouvez jamais répondre. Vous êtes un consommateur des services des autres, en permanence, et jamais un fournisseur des vôtres.

Ce n’est pas un effet de bord malheureux d’une pénurie. C’est une ré-architecture, et elle arrange tous ceux qui la vendent. La caméra qui a maintenant besoin du cloud du fabricant. L’accès distant qui a maintenant besoin du relais de quelqu’un. La chose que les gens faisaient tourner à la maison qui est maintenant un abonnement mensuel. Chacune de celles-là est quelqu’un qui possédait une chose converti en quelqu’un qui la loue, et une connexion discrètement rétrogradée d’une place sur l’internet à une fenêtre sur celui de quelqu’un d’autre.

Nous avons donné le milieu de l’internet à une poignée d’entreprises d’un autre continent, puis nous sommes restés là à avoir l’air surpris qu’il ait fini centralisé. Vous ne pouvez pas être autonome sur une connexion qui ne vous laisse rien héberger.

L’autonomie est la partie sur laquelle je reviens sans cesse, parce que ce pays a cessé de l’attendre de lui-même. L’instinct maintenant est d’attendre. Un fournisseur, un régulateur, une subvention, un mandat, un client qui appelle et demande. Aucun de ceux-là n’arrive. Il n’y a pas de signal de marché en chemin, pas de politique en rédaction, pas d’échéance que quiconque aura à expliquer d’avoir ratée.

Ce qui la laisse là où elle a été tout le temps. Une allocation gratuite, posée dans un compte de registre avec le nom de votre entreprise dessus, et une quinzaine entre vous et avoir fait le travail correctement.

Personne ne vient vous y obliger. C’est exactement pourquoi ça compte.

Vous pouvez vérifier si c’est votre bâtiment. Le script est dans le téléchargement en haut du billet.

Sources

Tout ce qui suit a été consulté le 27 août 2026.

Les données dont j’ai mesuré. Chaque chiffre de moi vient de celles-ci. Elles sont gratuites, publiques, et vous pouvez répéter le tout en un après-midi.

Les mesures d’autres gens.

Normes. Les rustines, dans l’ordre où elles ont été publiées.

  • RFC 3056 — tunnelage automatique 6to4, février 2001.
  • RFC 3701 — le plan de retrait du 6bone, fixant son extinction au 6 juin 2006.
  • RFC 7526 — dépréciant les relais anycast de 6to4 et les passant en Historique, mai 2015.
  • RFC 4864 — ce que le NAT donne et ne donne pas, et pourquoi le pare-feu que les gens croient avoir est « un artefact arbitraire », 2007.
  • RFC 4941, RFC 7217 et RFC 8981 — adresses temporaires et opaques, ce qui est pourquoi l’adresse IPv6 d’un appareil n’est pas un identifiant stable.
  • RFC 801 — le plan de transition NCP/TCP de Jon Postel, novembre 1981, fixant le jour du drapeau au 1er janvier 1983.
  • RFC 1883 — la spécification IPv6 originale, décembre 1995.
  • RFC 6333 — DS-Lite, 2011.
  • RFC 6056 — randomisation du port source, la défense que le CGN affaiblit, 2011.
  • RFC 6269 — Issues with IP Address Sharing, juin 2011. Le propre catalogue de l’IETF de ce que le CGN casse, y compris la journalisation d’abus, les mises au coin, le blocage, la randomisation de ports et la traçabilité.
  • RFC 791 et RFC 8200 — les deux formats d’en-tête, et pourquoi IPv6 a laissé tomber la somme de contrôle, la longueur variable et la fragmentation en vol.
  • RFC 6583 — épuisement du cache de découverte de voisins sur un /64, et la division plan de retransmission contre plan de contrôle qui décide ce qui coûte du CPU à un routeur.
  • RFC 6177 — combien d’espace d’adressage un site terminal devrait obtenir, 2011. Rend obsolète le /48 systématique du RFC 3177, écarte le /64 unique, et remet le chiffre réel à la communauté opérationnelle.
  • RIPE-690 — la propre réponse des opérateurs européens à cette question, octobre 2017 : /48 ou /56 à un utilisateur final, jamais un /64.
  • RFC 6302 — journaliser le port source, l’horodatage et le protocole, 2011.
  • RFC 6598 — espace d’adressage partagé, 2012.
  • RFC 6877 — 464XLAT, 2013.
  • RFC 6888 — exigences du NAT à l’échelle opérateur, 2013.
  • RFC 7021 — l’impact du NAT à l’échelle opérateur sur les applications, 2013.
  • RFC 7422 — correspondance déterministe pour rabattre la journalisation du CGN, 2014.
  • RFC 7597 et RFC 7599 — MAP-E et MAP-T, 2015.
  • World IPv6 Launch, 6 juin 2012.
  • Le tunnel broker gratuit de Hurricane Electric — là où beaucoup d’entre nous ont eu IPv6 pendant que nos propres FAI n’en avaient aucun.

Droit et politique.

Fournisseurs, dans leurs propres mots.

  • Akamai, juin 2022 — la double pile est le défaut et les clients doivent s’en désinscrire.
  • AWS, 2023 — la charge IPv4 publique, et pourquoi.

Reportage et dossier.