Non, ce n’est pas une blague ni une faute de frappe. Après des années à entendre “IPv6 c’est l’avenir”, un ingénieur a déposé un brouillon à l’IETF pour proposer… IPv8. L’idée ? Plutôt que de continuer à pousser IPv6 (que personne n’arrive à déployer complètement depuis 25 ans), on repart sur une base IPv4 étendue. Et honnêtement, sur le papier, c’est plutôt prometteur.
IPv6, le problème#
Avant de parler d’IPv8, rappelons pourquoi on en est là. IPv4 offre environ 4,3 milliards d’adresses. Ça semblait énorme dans les années 80, beaucoup moins aujourd’hui avec des milliards d’appareils connectés. Les adresses IPv4 sont officiellement épuisées depuis 2011, dans les faits c’est un peu plus compliqué que ça.
IPv6 a été conçu pour résoudre ce problème avec des adresses sur 128 bits, soit un nombre d’adresses tellement gigantesque qu’on pourrait attribuer une IP à chaque grain de sable de la planète (pour plus facilement se représenter la différence). Sur le papier, c’est parfait.
Dans la pratique ? Après plus de 25 ans, IPv6 représente toujours une minorité du trafic mondial. Le déploiement est lent (aujourd’hui ce sont principalement les opérateurs qui l’utilisent), complexe et impose de gérer un dual-stack (IPv4 + IPv6 en parallèle) pendant la transition. Résultat : on bricole avec du NAT, du CGNAT, et on fait comme si IPv4 allait tenir éternellement.
IPv8, c’est quoi ?#
Le brouillon a été soumis à l’IETF le 14 avril 2026 par James Thain. L’idée centrale est assez élégante : au lieu de tout casser avec un nouveau format d’adresse incompatible (comme IPv6), on étend IPv4 en passant de 32 à 64 bits.
Une adresse IPv8 se compose de deux parties :
| Partie | Taille | Rôle |
|---|---|---|
| r.r.r.r | 32 bits | Préfixe de routage (numéro ASN) |
| n.n.n.n | 32 bits | Adresse hôte (format IPv4 classique) |
Concrètement, chaque système autonome (ASN) disposerait de son propre espace de 4,3 milliards d’adresses. On passe de 4,3 milliards d’adresses au total à… 4,3 milliards × 4,3 milliards. Autant dire qu’on a de la marge (ça ferait toujours beaucoup de grains de sable).
La compatibilité avec IPv4#
C’est probablement le point le plus malin du brouillon. Une adresse IPv8 avec le préfixe 0.0.0.0 est tout simplement… une adresse IPv4. Pas de dual-stack, pas de tunnel, pas de traduction. L’IPv4 devient un sous-ensemble natif d’IPv8.
En théorie, aucun appareil, aucune application, aucun réseau existant n’aurait besoin de modification pour continuer à fonctionner. L’adoption pourrait se faire progressivement, ASN par ASN, sans “jour J” imposé et c’est probablement ça le point le plus intéressant pour que la solution puisse être nativement adoptée.
Les services intégrés#
Le brouillon ne s’arrête pas à l’adressage. IPv8 propose un concept de Zone Server qui centraliserait :
- DHCP8 : attribution d’adresses
- DNS8 : résolution de noms
- NTP : synchronisation temporelle
- OAuth2 / JWT : authentification et sécurité
- WHOIS8 : validation de routes
- Télémétrie : monitoring intégré
L’idée c’est d’avoir un point de gestion unique par zone réseau, au lieu de la dizaine de services qu’on doit aujourd’hui déployer et maintenir séparément.
Mon avis (et quelques réserves)#
Soyons clairs : c’est un brouillon. Pas une RFC, pas un standard, pas une feuille de route. C’est un document de travail soumis à discussion. Il y a un fossé immense entre un brouillon IETF et un protocole déployé en production.
Cela dit, l’approche est intéressante. Le constat de départ est lucide : IPv6 n’arrive pas à s’imposer après 25 ans, et le dual-stack est un cauchemar opérationnel, sur le papier IPv6 résout tous les soucis d’IPv4 mais il change radicalement le fonctionnement par rapport à l’actuel, probablement un peu trop. Si on faisait une comparaison c’est comme si on devait passer des voitures actuelles aux voitures volantes, ça résoud forcément les problèmes d’embouteillages mais aucune infrastructure n’est adaptée et surtout la transition douce est impossible. Proposer une évolution rétrocompatible avec IPv4 plutôt qu’une révolution incompatible, c’est pragmatique.
Les réserves :
- La centralisation via le Zone Server pose des questions de résilience et de gouvernance
- Le brouillon est porté par un seul auteur, sans le poids d’un consortium ou d’un grand acteur
- L’IETF reçoit des centaines de drafts, très peu deviennent des RFC
Mais bon, si ça peut enfin nous sortir du NAT… et des problématiques induites, ça laisse rêveur.
