Jetez vos bouquins sur l’IPv6 et arrêtez vos projets de migration : l’IPv8 est là ! Non, je déconne. Par contre, il y a bien eu un document de travail soumis à l’IETF le 14 avril 2026 à propos de l’IPv8. Qu’est-ce qui se cache réellement derrière ce terme ?

Un document de travail très récent (Internet-Draft) soumis à l’IETF le 14 avril 2026 par un ingénieur du nom de James Thain mérite une attention particulière. Publié sous le nom de , ce document de 27 pages propose une vision différente pour l’avenir de nos infrastructures.

Dès l’introduction de son draft, l’auteur part d’un constat assez sévère à propos du protocole IPv6 : “Après 25 ans d’efforts de déploiement, l’IPv6 ne représente qu’une minorité du trafic Internet mondial. Le coût opérationnel du modèle de transition en double pile, associé à l’absence d’amélioration de la gestion, s’est avéré commercialement inacceptable.”

Aujourd’hui, la difficulté réside dans la cohabitation obligatoire entre IPv4 et IPv6, ce qui alourdit la charge opérationnelle. En réponse à “cette usine à gaz”, IPv8 tente de proposer une solution “tout-en-un”. Pas question de tirer un trait sur IPv4, mais plutôt de l’étendre.

IPv8 : l’adressage sur 64 bits et la rétrocompatibilité totale

IPv8 ne propose pas un espace d’adressage sur 128 bits comme IPv6, mais un format sur 64 bits. Soit le double d’une adresse IPv4, puisqu’elles sont codées sur 4 octets, soit 32 bits.

Concrètement, une adresse IPv8 serait divisée en deux parties strictes :

1. Un préfixe de routage de 32 bits qui correspond au numéro d’AS (Autonomous System Number).
2. Une adresse hôte de 32 bits qui est ni plus ni moins qu’une adresse IPv4 !

“IPv4 est un sous-ensemble de IPv8. Une adresse IPv8 dont le champ de préfixe de routage est défini sur zéro est une adresse IPv4. Aucun appareil, aucune application ni aucun réseau existant ne nécessite de modification. La suite est 100 % rétrocompatible.”, peut-on lire. Côté mathématique, IPv4 devient un simple sous-ensemble d’IPv8.

Selon l’auteur de ce document, IPv8 résout la pénurie d’adresses en attribuant plus de 4 milliards d’adresses IP hôtes (4 294 967 296 pour être précis) par numéro d’AS, sans casser l’existant. En effet, chaque AS disposerait d’un pool IPv4 complet qui lui serait dédié, tandis qu’aujourd’hui il est commun à l’échelle mondiale.

L’autre avantage, ce serait un allégement de la table de routage BGP mondiale, car elle serait structurellement limitée à une entrée par ASN. Il y a des choses qui ne changeraient pas, comme le fait de réserver le réseau 127.0.0.0/8 pour la boucle locale.

Note : un Autonomous System Number (ASN) est un identifiant unique au monde attribué à un grand réseau ou un groupe de réseaux (comme ceux d’un fournisseur d’accès ou d’une grande entreprise) géré par une seule entité, ce qui lui permet d’annoncer ses propres règles de routage et de communiquer avec le reste d’Internet via le protocole BGP.

Le serveur de zone de l’IPv8

C’est ici que l’approche se détache d’une simple mise à jour réseau : IPv8 se définit comme une “suite de protocoles gérée”. Le cœur de ce modèle est un concept appelé le Zone Server (Serveur de Zone).

Dans une architecture IPv8, fini le serveur DHCP sous Windows Server, le DNS sous BIND et le serveur NTP sous Linux. Le Zone Server (en cluster actif/actif) centralise tout ce dont le réseau a besoin : DHCP8, DNS8, NTP8, NetLog8 (pour la télémétrie), OAuth8 (pour l’authentification) et XLATE8 (pour la traduction IPv4/IPv8).

Quand une machine se connecte, elle envoie un unique paquet “DHCP8 Discover”. En retour, elle reçoit un bail qui contient tous les endpoints des services dont elle a besoin pour fonctionner dans sa zone. Le document précise bien que le client doit disposer de clients compatibles, en particulier un client DHCP8.

La sécurité “By Design” à base de jetons JWT

Dans le modèle IPv8, il y a une approche Zero Trust native implémentée au niveau du réseau. En réalité, chaque élément de votre réseau est soumis à des règles de contrôle d’accès et doit s’authentifier via des jetons JWT basés sur le protocole OAuth2.

“Les jetons sont validés localement par le cache OAuth8 sur le serveur de zone, sans aller-retour vers des fournisseurs d’identité externes. Un appareil situé à distance dont le fournisseur d’identité cloud est temporairement inaccessible continue de s’authentifier normalement : le cache OAuth8 contient toutes les clés publiques et valide les signatures localement en moins d’une milliseconde.”, peut-on lire.

Faut-il enterrer IPv6 ?

Bien sûr que non. Ce document n’est qu’un Draft IETF : c’est un premier jet, une idée soumise publiquement par un ingénieur. A voir comment il évolue ! Le jour où il y aura un projet de RFC ou une véritable feuille de route officielle pour ce projet d’IPv8, ce sera différent, mais nous n’en sommes pas là. Ce qui est intéressant avec ce document, c’est l’approche proposée et la mise en lumière de certaines “douleurs” relatives à l’IPv6.

La proposition IPv8 de James Thain veut résoudre l’épuisement des IP tout en gardant le format IPv4 (que nous apprécions tous, n’est-ce pas ?). L’avenir nous le dira si c’était une vraie bonne idée ou uniquement une belle utopie technique. Mais bon, rien que par curiosité, je trouve que c’est intéressant de parcourir ce type de document.

Voici le lien pour ceux qui veulent y jeter un coup d’œil : ietf.org/ipv8.

Qu’en pensez-vous ?