IPv4 utilise des adresses sur 32 bits (environ 4,29 milliards au total), tandis qu'IPv6 utilise des adresses sur 128 bits (environ 3,4×10^38). C'est la réponse à l'épuisement des adresses IPv4 et la raison pour laquelle la plupart des infrastructures modernes font désormais tourner les deux protocoles côte à côte (« dual-stack », ou double pile). Les deux ne se distinguent pas seulement par la longueur des adresses : ils diffèrent aussi par la conception de l'en-tête, l'attribution des adresses et la nécessité même du NAT. Voici ce qui change concrètement lorsque vous passez de l'un à l'autre.
Quelle est la différence entre IPv4 et IPv6 ?
IPv4 a été défini dans la RFC 791 en 1981, avec des adresses de 32 bits écrites en notation décimale pointée, comme 203.0.113.42. Cela donne environ 4,29 milliards d'adresses uniques : un chiffre énorme en 1981, mais insuffisant pour un monde comptant des milliards d'appareils connectés.
IPv6, défini dans la RFC 8200, utilise des adresses de 128 bits écrites en groupes hexadécimaux, comme 2001:db8:85a3::8a2e:370:7334. L'espace d'adressage est si vaste (2^128) que son épuisement n'est pas une préoccupation réaliste, quel que soit l'horizon de planification.
| IPv4 | IPv6 | |
|---|---|---|
| Longueur d'adresse | 32 bits | 128 bits |
| Exemple | 203.0.113.42 | 2001:db8::1 |
| Nombre total d'adresses | ~4,29 milliards | ~3,4×10^38 |
| Taille de l'en-tête | 20–60 octets (variable) | 40 octets (fixe) |
| Fragmentation | Les routeurs peuvent fragmenter en transit | Seul l'hôte source fragmente |
| NAT | Courant, souvent indispensable | Généralement inutile |
| Configuration | DHCP ou statique | SLAAC ou DHCPv6 |
| Broadcast | Oui | Non, multicast uniquement |
Pourquoi a-t-on eu besoin d'IPv6 ?
Le stock central d'adresses IPv4 de l'IANA s'est épuisé le 3 février 2011, et les cinq registres régionaux (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) ont ensuite épuisé leurs propres allocations, chacun à son rythme. Depuis, le secteur s'appuie sur l'adressage privé (plages RFC 1918 comme 10.0.0.0/8 et 192.168.0.0/16) combiné à la traduction d'adresses réseau (NAT, RFC 3022) pour permettre à de nombreux appareils de partager une seule adresse IPv4 publique.
Le NAT fonctionne, mais il ajoute de la complexité : suivi des connexions, mappage de ports et casse-têtes pour les protocoles pair-à-pair. L'espace d'adressage d'IPv6 est suffisamment grand pour que chaque appareil (chaque serveur, chaque téléphone, chaque capteur IoT) obtienne sa propre adresse routable mondialement, sans traduction. C'est une solution structurelle, pas un correctif.
NoteCertains fournisseurs cloud facturent désormais les adresses IPv4 publiques, précisément parce que cet espace d'adressage est rare et coûteux à acquérir : une raison de plus pour laquelle l'adoption d'IPv6 continue de progresser côté serveur.
Comment l'attribution des adresses diffère-t-elle ?
Les hôtes IPv4 obtiennent une adresse via DHCP (RFC 2131) ou par configuration statique, et ils découvrent leurs voisins sur le réseau local grâce à ARP.
IPv6 remplace ces deux éléments par des mécanismes plus récents :
- SLAAC (Stateless Address Autoconfiguration, RFC 4862) : un hôte peut générer sa propre adresse à partir du préfixe réseau, sans aucun serveur DHCP.
- DHCPv6 (RFC 8415) : pour les réseaux qui préfèrent un contrôle centralisé et avec état.
- NDP (Neighbor Discovery Protocol, RFC 4861) : remplace ARP, en utilisant ICMPv6 (RFC 4443) au lieu de requêtes ARP en broadcast.
- Pas de broadcast : IPv6 abandonne complètement le broadcast au profit du multicast, plus efficace sur les réseaux commutés modernes.
Les sous-réseaux IPv6 sont également gérés différemment. Alors que le découpage en sous-réseaux IPv4 est flexible et se calcule en CIDR (RFC 4632) jusqu'au masque adapté, les réseaux IPv6 utilisent presque toujours un /64 par sous-réseau, car SLAAC dépend de cette limite pour fonctionner correctement. Si vous planifiez des plages d'adresses pour l'un ou l'autre protocole, passez les chiffres dans notre calculateur de sous-réseau gratuit plutôt que de faire les calculs binaires à la main.
À quoi ressemble réellement l'en-tête d'un paquet ?
L'en-tête IPv4 est variable (20 octets minimum, jusqu'à 60 octets lorsque des options sont présentes) et contient une somme de contrôle que chaque routeur doit recalculer à chaque saut.
IPv6 simplifie tout cela : un en-tête fixe de 40 octets, aucune somme de contrôle (cette tâche est laissée aux couches supérieures et aux vérifications de la couche liaison), et les fonctionnalités optionnelles déplacées dans des en-têtes d'extension plutôt que dans des options intégrées. Le traitement des paquets devient ainsi plus rapide et plus prévisible à grande échelle, ce qui compte pour les routeurs à haut débit et, de plus en plus, pour les répartiteurs de charge cloud.
La fragmentation a aussi changé. Les routeurs IPv4 peuvent fragmenter un paquet trop volumineux en cours de route. IPv6 supprime totalement cette possibilité : seul l'hôte d'origine fragmente, et il s'appuie sur la découverte du MTU de chemin (Path MTU Discovery, RFC 8201) pour déterminer la bonne taille de paquet en amont. C'est une différence de fiabilité notable si vous avez déjà traqué un mystérieux blocage de connexion lié au MTU.
Qu'est-ce que le dual-stack et pourquoi est-ce important ?
Le dual-stack (double pile), spécifié dans la RFC 4213, signifie qu'un appareil ou un serveur fait tourner IPv4 et IPv6 simultanément, avec des adresses indépendantes pour chacun. C'est la réalité pratique de presque tous les serveurs de production aujourd'hui : votre hôte dispose à la fois d'un enregistrement A et d'un enregistrement AAAA dans le DNS, et les clients se connectent via le protocole que leur réseau privilégie, généralement IPv6 d'abord, avec un repli sur IPv4 si ce chemin n'est pas disponible.
Le dual-stack est important parce que l'adoption d'IPv6 n'est pas encore universelle. Certains réseaux, notamment ceux des opérateurs mobiles, sont exclusivement IPv6 en interne et s'appuient sur la traduction (NAT64/DNS64, RFC 6146/6147) pour atteindre les destinations uniquement IPv4. D'autres sont exclusivement IPv4 et ne peuvent pas du tout joindre les points de terminaison IPv6. En adoptant le dual-stack, votre infrastructure reste joignable dans les deux cas, sans parier sur la victoire d'un protocole à court terme.
Si vous publiez des enregistrements DNS pour un hôte dual-stack, vous avez besoin des deux types d'enregistrement pointant vers les bonnes adresses : notre guide complet des enregistrements DNS explique précisément comment les enregistrements A et AAAA s'articulent.
Faut-il activer IPv6 sur vos serveurs ?
Pour la plupart des charges de travail, oui, ou du moins vous devriez l'anticiper. Quelques raisons pratiques :
- Les adresses IPv4 publiques coûtent de l'argent et se raréfient. Plusieurs grands fournisseurs cloud facturent désormais séparément les adresses IPv4 publiques des instances en cours d'exécution, conséquence directe de cette pénurie.
- Les réseaux mobiles et des FAI privilégient de plus en plus IPv6. Un serveur dual-stack offre un chemin plus court, et souvent plus rapide, aux clients IPv6 natifs.
- Le NAT ajoute une latence et une complexité inutiles si vous pouvez vous en passer. Les connexions IPv6 natives évitent entièrement la traduction.
Lorsque vous provisionnez des serveurs, vérifiez si votre fournisseur attribue IPv6 par défaut ou en option : cela varie beaucoup d'une plateforme à l'autre. Gérer cela de façon cohérente chez plusieurs fournisseurs, c'est exactement la vocation de notre fonctionnalité serveurs cloud : un seul tableau de bord pour visualiser et configurer l'adressage IPv4 et IPv6 de tous vos hôtes, au lieu de consulter cinq consoles de fournisseurs différentes.
IPv6 est-il moins sécurisé qu'IPv4 ?
Non, le niveau de sécurité est aujourd'hui essentiellement équivalent. Les premières spécifications d'IPv6 laissaient entendre que la prise en charge d'IPsec serait obligatoire, mais les recommandations actuelles (RFC 6434, alignée sur la base de la RFC 8200) considèrent IPsec comme recommandé plutôt qu'exigé pour les deux protocoles. En pratique, la sécurité dépend bien davantage des règles de pare-feu, des correctifs et de la configuration que de la version d'IP utilisée. Si vous auditez votre configuration, notre checklist de sécurité DNS et notre checklist de sécurité de l'infrastructure sont de bons points de départ, quel que soit le protocole utilisé par vos serveurs.
Un piège courant : oublier de protéger votre interface IPv6 par un pare-feu parce que vos règles existantes ne couvrent qu'IPv4. Si vous activez le dual-stack, votre adresse IPv6 mérite la même vigilance que votre adresse IPv4 : elle est tout aussi joignable depuis l'internet public.
Vérifiez l'adressage actuel de vos serveurs et votre plan de sous-réseaux avec notre calculateur de sous-réseau gratuit, ou gérez IPv4/IPv6 chez tous vos fournisseurs depuis un seul endroit avec les serveurs cloud.
Questions fréquentes
#Les appareils IPv4 et IPv6 peuvent-ils communiquer directement entre eux ?
Non : IPv4 et IPv6 ne sont pas interopérables nativement, car ils utilisent des formats d'adressage et d'en-tête différents. La communication entre eux nécessite un mécanisme de traduction tel que NAT64/DNS64, ou que les deux points de terminaison fonctionnent en dual-stack afin de partager un protocole commun.
#Mon domaine a-t-il besoin à la fois d'un enregistrement A et d'un enregistrement AAAA ?
Seulement si le serveur qui se trouve derrière dispose à la fois d'une adresse IPv4 et d'une adresse IPv6. Ajoutez un enregistrement A pour IPv4 et un enregistrement AAAA pour IPv6 : si vous n'en ajoutez qu'un, les clients utilisant l'autre protocole n'emprunteront tout simplement pas ce chemin pour vous joindre.
#IPv4 finira-t-il par disparaître ?
Pas de sitôt. IPv4 reste profondément ancré dans les infrastructures existantes : le scénario réaliste est donc des années de coexistence en dual-stack plutôt qu'une bascule brutale, même si l'adoption d'IPv6 continue de progresser.
#IPv6 est-il plus rapide qu'IPv4 ?
Pas intrinsèquement, mais il peut l'être en pratique : l'en-tête plus simple et de taille fixe d'IPv6, ainsi que l'absence de fragmentation dans le réseau, réduisent la charge de traitement des routeurs, et l'absence de NAT supprime une couche de latence liée à la traduction.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?