IPv4 : un protocole à bout de souffle

21 févr. 2026 — Romain Grosos

Le prix d'une adresse IPv4 publique tourne aujourd'hui autour de 35 à 50 dollars sur le marché secondaire. C'est le symptôme le plus concret d'un épuisement qui ne date pas d'hier : l'IANA a distribué ses derniers blocs /8 aux registres régionaux en février 2011, et le RIPE NCC a épuisé son stock en novembre 2019. Depuis, les opérateurs européens jonglent entre CGNAT, transferts d'adresses et déploiement IPv6 — à des rythmes très inégaux.

L'épuisement, en chiffres

Les cinq registres régionaux (RIR) ont successivement atteint leur limite :

APNIC (Asie-Pacifique) : avril 2011
LACNIC (Amérique latine) : juin 2014
ARIN (Amérique du Nord) : septembre 2015
AFRINIC (Afrique) : 2017, en gestion serrée
RIPE NCC (Europe / Moyen-Orient / Asie centrale) : novembre 2019

Le RIPE NCC maintient une liste d'attente pour les LIR n'ayant jamais reçu d'allocation — uniquement des /24 (256 adresses), récupérés sur des organisations dissoutes. Ce n'est pas un retour à la normale, c'est de la récupération marginale.

La table de routage BGP globale dépasse désormais le million de préfixes IPv4, en partie à cause de la déaggregation liée aux transferts et aux micro-allocations. Chaque routeur de transit absorbe cette croissance en mémoire TCAM et en temps de convergence.

Les béquilles qui ont prolongé IPv4

CGNAT : la double peine opérationnelle

Le Carrier-Grade NAT (RFC 6888) permet à un opérateur de mutualiser une IPv4 publique entre plusieurs dizaines d'abonnés simultanément, en s'appuyant sur la plage dédiée 100.64.0.0/10 (RFC 6598). Les conséquences opérationnelles sont réelles :

Compliance et forensics : les logs de connexion ne permettent plus d'identifier un abonné unique sans corrélation avec les logs de port du CGNAT - contrainte RGPD significative pour les hébergeurs et les FAI
Hairpinning : la communication entre deux abonnés derrière le même CGNAT est souvent cassée ou non garantie selon les implémentations
Limites de ports par abonné : les applications à nombreuses connexions simultanées (jeux en ligne, VoIP multi-flux, P2P) heurtent rapidement le plafond alloué
Abus et blocage par IP : une IPv4 partagée rend le ban par adresse quasi inutilisable sans collatéraux

Le Port Control Protocol (PCP, RFC 6887) permet à un client de négocier des réservations de ports côté CGNAT, mais son déploiement reste marginal chez les opérateurs grand public.

Le marché de transfert IPv4

Depuis l'ouverture des politiques de transfert par l'ARIN (2011) et le RIPE NCC (2012), un marché secondaire structuré s'est développé. Les prix ont suivi une trajectoire claire : moins de 0,50 $/adresse en 2010, entre 35 et 50 $/adresse selon les régions et les tailles de blocs en 2025. Un /24 (256 adresses) se négocie aujourd'hui entre 9 000 et 13 000 dollars sur les principales bourses de transfert.

AWS a matérialisé cette réalité en facturant les IPv4 publiques depuis février 2024 — 0,005 $/h par adresse, soit environ 44 $/an. GCP et Azure ont suivi avec des ajustements tarifaires similaires. Pour les opérateurs cloud-heavy avec des milliers d'instances, la facture IPv4 est devenue un argument budgétaire tangible en faveur d'IPv6.

IPv6 : état de déploiement en 2025-2026

Taux d'adoption

Les mesures de Google indiquent qu'environ 46 % de leurs utilisateurs accèdent à leurs services en IPv6 début 2026, contre moins de 1 % en 2012. Les disparités géographiques sont marquées :

Inde : >70 % déploiement massif de Reliance Jio dès 2016, opérateur IPv6-natif par conception
France : ~70 % portée par Free (pionnière dès 2007) et Orange ; SFR et Bouygues plus tardifs
Allemagne : ~60 %
États-Unis : ~50 % T-Mobile et Comcast en tête
Afrique subsaharienne, Moyen-Orient : souvent <5 % retard structurel

Ce qui freine encore

Équipements legacy : imprimantes réseau, caméras IP, automates industriels, IPBX (souvent IPv4-only sans mise à jour firmware possible)
Applications hardcodant des IPv4 : configurations, ACL, parsers de logs qui supposent le format x.x.x.x
VPN split-tunnel ignorant IPv6 : le trafic IPv6 sort en clair pendant que IPv4 transite dans le tunnel (vecteur de fuite d'identité réseau non négligeable)
Compétences internes : les équipes formées exclusivement sur IPv4 sous-estiment souvent la portée des ajustements (IPAM, monitoring, politique firewall)

Implications opérationnelles du dual-stack

Double surface à administrer

Le dual-stack est la phase de transition dominante. En pratique, il double la surface à gérer : deux jeux de règles de firewall, deux plans d'adressage, deux configurations DHCP, des entrées DNS en A et AAAA. Les outils de monitoring doivent capturer les deux flux : un service disponible en IPv4 mais cassé en IPv6 sera préféré par le mécanisme Happy Eyeballs (RFC 8305) avant de tomber en fallback après un timeout, dégradant silencieusement l'expérience.

Prefix Delegation et gestion d'adresses

En environnement réseau managé, la délégation de préfixe (DHCPv6-PD) distribue typiquement des /48 ou /56 aux routeurs de site. Chaque sous-réseau reçoit un /64 : 2^64 adresses par segment. La relation à l'IPAM change : on raisonne en préfixes délégués, pas en adresses individuelles.

Les Privacy Extensions (RFC 4941) génèrent des adresses temporaires côté client, ce qui complique la corrélation dans les logs d'accès et les outils EDR. Le choix entre DHCPv6 stateful (adresses stables et traçables) et SLAAC avec Privacy Extensions doit être fait explicitement selon le contexte — pas laissé aux valeurs par défaut du système.

IPv6-only : tendances 2026

Plusieurs signaux indiquent une accélération vers l'IPv6-only dans certains segments :

Opérateurs mobiles : déploiements IPv6-only avec NAT64/DNS64 (RFC 6146) pour la traduction vers les services IPv4-only
AWS : possibilité depuis 2023 de déployer des instances sans IPv4 publique, avec accès aux services AWS via endpoints IPv6
Kubernetes : support IPv6-only en GA depuis la v1.23, clusters dual-stack depuis la v1.21

L'IPv6-only simplifie l'architecture — pas de NAT, pas de tables de translation, moins d'état dans les équipements réseau. Mais il présuppose que l'ensemble du stack applicatif, y compris les dépendances tierces, est compatible IPv6. Ce point reste rarement vérifié de manière exhaustive avant migration.