Votre réseau est déjà en IPv6 — vous ne le savez juste pas encore

Le 6 juin 2012, les géants du web lancent le World IPv6 Launch et activent IPv6 de façon permanente sur leurs services. Le 26 juillet 2026, Google mesure 49,62 % de trafic IPv6 natif sur l’ensemble de ses utilisateurs mondiaux — la barre symbolique des 50 % est franchie en milieu d’année. Et pourtant, si vous demandez à un administrateur réseau aujourd’hui s’il a déployé IPv6 dans son entreprise, il y a de fortes chances qu’il vous réponde que c’est « prévu pour l’année prochaine ». Le paradoxe est vertigineux : la moitié du trafic mondial passe en IPv6, mais une fraction infime des déploiements est intentionnelle.

Votre réseau est probablement déjà en dual-stack — votre Windows 11, votre MacBook, votre iPhone et votre imprimante réseau négocient des adresses IPv6 depuis des années sans que vous ayez levé le petit doigt. Le problème n’est pas l’absence d’IPv6. Le problème, c’est que vous ne la maîtrisez pas.

Un demi-Internet a migré tout seul

Les chiffres de Google sont sans appel. Au 26 juillet 2026, la courbe d’adoption IPv6 native atteint 49,62 % — 6to4 et Teredo, les mécanismes de transition des années 2000, affichent un score strictement nul. Tout le trafic IPv6 mesuré est du trafic natif, délivré par des FAI qui ont activé le protocole sur leurs infrastructures d’accès.

Les données APNIC (moyenne glissante 28 juin — 27 juillet 2026, 937 millions d’échantillons) racontent une géographie à deux vitesses. L’Inde caracole en tête des grands pays avec 79,20 % de clients capables en IPv6 ; la France suit à 83,53 %. L’Allemagne est à 72,08 %, les États-Unis à 60,40 %. L’Europe de l’Ouest dans son ensemble affiche 70,10 %. À l’autre bout du spectre, l’Afrique plafonne à 6,13 % et l’Europe de l’Est à 12,14 %.

Ce qui frappe dans ces chiffres, c’est que l’adoption IPv6 est presque entièrement tirée par les opérateurs grand public et les réseaux mobiles. Reliance Jio en Inde, Free et Orange en France, Deutsche Telekom en Allemagne — ces acteurs ont basculé leurs clients en IPv6 sans que ceux-ci ne s’en aperçoivent, parce que le CGNAT (Carrier-Grade NAT) qui épulse les IPv4 publiques devient intenable au-delà de quelques dizaines de millions d’abonnés mobiles. Le réseau mobile indien est à plus de 90 % IPv6. Les box françaises attribuent un préfixe /56 ou /48 à chaque abonné depuis près de dix ans.

Le monde de l’entreprise, lui, est resté au bord de la route.

Pourquoi personne ne déploie IPv6 dans l’entreprise

Le déploiement IPv6 en entreprise bute sur quatre obstacles qui, pris isolément, semblent anodins — et qui, cumulés, paralysent tout.

Le firewall comme angle mort. La quasi-totalité des pare-feux d’entreprise sont configurés avec des règles IPv4 explicites et des règles IPv6… inexistantes. Résultat : un poste Windows en dual-stack qui obtient une adresse IPv6 via SLAAC contourne silencieusement le pare-feu pour tout son trafic sortant. Le firewall ne voit même pas passer les paquets, parce que l’administrateur n’a jamais écrit de règle pour ::/0. C’est le scénario cauchemar que le SANS Institute documente depuis 2021 : des réseaux d’entreprise qui croient être protégés parce qu’ils filtrent 0.0.0.0/0, mais qui laissent passer ::/0 par défaut.

SLAAC contre DHCPv6 — la guerre de religion qui dure. IPv6 propose deux mécanismes d’attribution d’adresse incompatibles. SLAAC (Stateless Address Autoconfiguration, RFC 4862) laisse le routeur annoncer un préfixe et le client générer sa propre adresse — sans état, sans log centralisé, sans contrôle. DHCPv6 (RFC 8415) reproduit le modèle IPv4 avec un serveur qui attribue des adresses et enregistre les baux. Le problème : Android ne supporte pas DHCPv6 — décision historique de Lorenzo Colitti chez Google en 2012, jamais révisée depuis. iOS le supporte partiellement. Windows le supporte. Résultat : un réseau d’entreprise uniforme doit choisir entre couvrir tous ses clients (SLAAC, mais adieu la traçabilité) ou garder le contrôle (DHCPv6, mais adieu Android).

Les applications legacy qui plantent. Une adresse IPv6 ne rentre pas dans un champ varchar(15) de base de données. Un socket codé avec AF_INET en dur ne négociera jamais AF_INET6. Une regex de validation qui attend \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} rejettera 2001:db8::1. Ces bugs sont triviaux à corriger un par un, mais dans un SI de deux décennies avec des centaines d’applications internes, le coût de la correction globale paralyse les DSI.

Le préfixe /48 comme délégué de pouvoir implicite. Un préfixe IPv6 /48 contient 65 536 sous-réseaux /64. Un /64 contient 18 milliards de milliards d’adresses. La recommandation RIPE NCC est d’allouer un /48 à chaque site — ce qui donne à chaque chef de projet réseau un pouvoir d’adressage quasi illimité. Dans une organisation où le moindre VLAN IPv4 nécessite une demande de changement validée par trois comités, cette abondance est culturellement déstabilisante. Beaucoup d’entreprises préfèrent ne pas déployer plutôt que de déployer sans contrôle.

Dual-stack, le cheval de Troie qui est déjà chez vous

Le dual-stack — IPv4 et IPv6 actifs simultanément sur la même interface — est le mode de fonctionnement par défaut de tous les systèmes d’exploitation modernes. Windows l’active depuis Vista (2007). macOS et iOS depuis 2010. Linux depuis le kernel 2.6. Android depuis 2012. Votre imprimante HP, votre caméra de surveillance et votre NAS Synology l’activent aussi.

Quand un client dual-stack reçoit une annonce de routeur (RA, Router Advertisement) avec un préfixe IPv6, il configure automatiquement une adresse et l’utilise en priorité sur IPv4. C’est le comportement défini par le RFC 6724 (Happy Eyeballs v2) : si une résolution DNS retourne à la fois un enregistrement A (IPv4) et AAAA (IPv6), le navigateur essaie IPv6 en premier, et ne bascule sur IPv4 qu’en cas d’échec après 300 ms.

Voici ce qui se passe concrètement sur un réseau d’entreprise lambda en 2026 :

# Sur un poste Windows 11 connecté au réseau corporate
ipconfig
# Carte Ethernet Ethernet0 :
#    Adresse IPv4. . . . . . . . . . . . : 10.23.45.67
#    Adresse IPv6 . . . . . . . . . . . . : 2001:db8:cafe:1:a1b2:c3d4:e5f6:7890

Cette adresse IPv6 a été attribuée automatiquement, sans que l’équipe IT ne l’ait demandée, sans que le firewall n’ait de règle pour elle, et sans que les logs SIEM ne la surveillent. Le poste émet du trafic IPv6 vers Internet — et vers les autres postes du LAN — sur une pile réseau que personne n’administre.

NPTv6 (Network Prefix Translation, RFC 6296) ajoute une couche de complexité. Là où IPv4 utilise le NAT pour masquer des adresses privées derrière une adresse publique (et brise l’Internet de bout en bout au passage), IPv6 n’a pas besoin de NAT — chaque appareil a une adresse publique. Mais les entreprises qui veulent cacher leur topologie interne utilisent NPTv6 pour translater le préfixe source en sortie. Le problème : NPTv6 casse les checksums de couche transport qui incluent l’adresse source, rendant le débogage réseau nettement plus difficile qu’en IPv4.

IPv6-only, la cible que tout le monde évite

Si le dual-stack est un cheval de Troie, l’IPv6-only est le seul état vraiment maîtrisable — et presque personne n’y est.

Un réseau IPv6-only n’a pas de pile IPv4. Pas de NAT. Pas de RFC 1918. Pas de conflits d’adresses. Pas de double table de routage. Chaque appareil a une adresse publique unique, chaque flux est identifiable de bout en bout, et la topologie est d’une simplicité radicale. C’est l’état final promis par l’IETF depuis le RFC 2460 (1998).

Le problème, c’est la connectivité vers l’IPv4 résiduel. Les mécanismes existent : NAT64 + DNS64 (RFC 6146/6147) permettent à un client IPv6-only d’atteindre un serveur IPv4-only — le résolveur DNS synthétise un enregistrement AAAA à partir de l’A en l’encapsulant dans un préfixe /96 dédié, et le gateway NAT64 traduit les paquets. 464XLAT (RFC 6877) fait la même chose côté client pour les applications qui ouvrent des sockets IPv4 en dur.

Ces mécanismes fonctionnent — les réseaux mobiles T-Mobile US et Reliance Jio tournent en IPv6-only avec 464XLAT pour des centaines de millions d’abonnés. Mais les déployer dans une entreprise requiert une refonte complète du plan d’adressage, des règles de firewall, des logs, du monitoring et de la formation des équipes. C’est un projet de 18 à 36 mois pour une organisation de taille moyenne — et le ROI n’est pas immédiat.

Ce qu’il faut faire maintenant

Le risque n’est pas que votre réseau ne supporte pas IPv6. Le risque, c’est qu’il la supporte sans que vous le sachiez — et qu’un attaquant le découvre avant vous.

Première action : auditez votre exposition IPv6 involontaire. Lancez un scan sur votre plage d’adresses publiques et cherchez des réponses sur le port 80/443 en IPv6. Utilisez curl -6 https://votre-domaine.com pour chaque service exposé. Si ça répond, vous avez une surface d’attaque non documentée.

# Vérifier l'exposition IPv6 d'un domaine
curl -6 -sI https://ettayeb.fr | head -5
# Si vous obtenez une réponse HTTP, le service est exposé en IPv6

Deuxième action : vérifiez vos règles de pare-feu IPv6. Si vous gérez un firewall d’entreprise, listez les règles qui concernent ::/0. S’il n’y en a aucune, votre réseau est grand ouvert en IPv6. Bloquez explicitement ce que vous ne voulez pas autoriser — le modèle « allowlist » est le seul tenable.

# Sur un firewall Linux avec nftables : lister les règles IPv6
nft list ruleset ip6
# Si la sortie est vide, votre firewall ne filtre pas l'IPv6

Troisième action : décidez entre SLAAC et DHCPv6. Si vous avez un parc mixte (Android + Windows + iOS), la réponse est SLAAC — c’est le seul dénominateur commun. Compensez la perte de traçabilité par des logs au niveau du switch (MAC → adresse IPv6 via les Neighbor Discovery messages) et par un SIEM capable de corréler les adresses IPv6 temporaires.

Quatrième action : planifiez la migration IPv6-only. Même si vous ne la faites pas maintenant, concevez votre plan d’adressage IPv6 comme s’il était destiné à être le seul protocole actif. Attribuez un /48 à chaque site, un /64 à chaque VLAN, et documentez la correspondance. Activez NAT64+DNS64 dans une DMZ de test et validez que vos applications critiques fonctionnent.

Verdict

Si votre entreprise compte moins de 500 postes et que vous n’avez pas de compétence IPv6 en interne, votre priorité est simple : désactivez IPv6 proprement sur tous les postes et sur tous les firewalls. Un réseau IPv4 proprement filtré est plus sûr qu’un réseau dual-stack non administré. Utilisez une GPO pour Windows, un profil MDM pour macOS/iOS, et ipv6.disable=1 au boot pour Linux. Ce n’est pas glorieux, mais c’est honnête.

Si vous êtes au-delà de 500 postes, vous n’avez pas le choix : le dual-stack est déjà actif sur une partie de votre parc, que vous le vouliez ou non. Votre migration IPv6 a commencé sans vous. La seule question est de savoir si vous allez la rattraper avant qu’un incident de sécurité ne vous y force.

Références

1. Google IPv6 Statistics — https://www.google.com/intl/en/ipv6/statistics.html, consulté le 26 juillet 2026
2. APNIC IPv6 Measurement Maps — https://stats.labs.apnic.net/ipv6 (moyenne 30 jours au 27 juillet 2026)
3. RFC 4862 — IPv6 Stateless Address Autoconfiguration, IETF, septembre 2007
4. RFC 8415 — Dynamic Host Configuration Protocol for IPv6 (DHCPv6), IETF, novembre 2018
5. RFC 6296 — IPv6-to-IPv6 Network Prefix Translation (NPTv6), IETF, juin 2011
6. RFC 6146 — Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers, IETF, avril 2011
7. RFC 6724 — Default Address Selection for IPv6 (Happy Eyeballs v2), IETF, septembre 2012
8. SANS Institute — « IPv6 Security: The Hidden Threat », ISC Paper, 2021
9. RIPE NCC — « Best Current Operational Practice for IPv6 Address Assignment », ripe-690, 2019
10. World IPv6 Launch — https://www.worldipv6launch.org/ (archivé, redirige vers Internet Society Pulse)