IPv4 vs IPv6 sur les serveurs dédiés : comparaison et guide de décision 2026

Chaque serveur dédié pas cher Kimsufi livre avec une IPv4 dédiée et un /64 IPv6, donc la question n'est pas IPv4 ou IPv6, mais lequel activer et quand. IPv4 est la ressource rare et facturée ; IPv6 est abondante et incluse. Ce guide les compare sur la performance, la sécurité, le coût et la compatibilité, puis propose une matrice pour votre cas.

IPv4 vs IPv6 : instantané 2026

La différence tient à la rareté. Une adresse IPv4 est un actif transactionnel avec un prix, raison pour laquelle Internet la régule au compteur. Un /64 IPv6 est un arrondi comptable.

Fonctionnement d'IPv4 et d'IPv6 : différences techniques fondamentales

IPv6 n'est pas IPv4 avec une version d'IP plus longue. L'en-tête est fixe à 40 octets sans checksum : les routeurs avancent avec moins de travail par paquet, et un flow label identifie un flux sans inspecter les couches supérieures.

Les routeurs ne fragmentent plus le trafic. Les hôtes s'en chargent via la découverte de MTU par le chemin, une opération ICMP, raison pour laquelle l'ICMP doit atteindre votre machine. ARP a disparu aussi, remplacé par la découverte de voisins sur ICMP. Pas de broadcast : ce qui criait sur le segment passe par un groupe multicast.

Les en-têtes d'extension sont là où les deux versions divergent le plus. IPv4 entassait les options dans un en-tête de longueur variable que chaque routeur devait parser. IPv6 garde l'en-tête central fixe et chaîne tout l'optionnel derrière, les sauts intermédiaires ne lisent que ce dont ils ont besoin. Certains middleboxes traitent mal les longues chaînes d'extensions : ça se teste avant de faire dépendre de l'IPv6 des chemins critiques.

Adressage, sous-réseaux et formatage (IPv4 vs IPv6)

IPv4 écrit quatre octets en décimal, comme 203.0.113.10 avec un masque /24. IPv6 écrit huit groupes de 16 bits en hexadécimal, avec possibilité de comprimer une suite de zéros :

2001:0db8:85a3:0000:0000:8a2e:0370:7334 devient 2001:db8:85a3::8a2e:370:7334

Deux règles comptent. Un /64 est la taille standard de sous-réseau pour un segment et SLAAC la présume : ne découpez pas le vôtre plus petit. Et un /64 contient 18 quintillions d'adresses, donc un hôte de virtualisation donne à chaque invité une IP unique, sans NAT.

Performance, latence et débit : comparaison

La latence se décide par le chemin de routage, pas par la version d'IP. Un paquet n'est pas plus rapide pour une IP sur 128 bits : la performance n'est pas le facteur décisif.

Une différence va dans l'autre sens : un en-tête IPv6 fait 40 octets contre 20 en IPv4, donc sur des petits payloads vous transportez marginalement plus de surcoût par paquet. Ça ne se voit pas dans le trafic IPv6 réel. Là où la version récente aide, c'est le travail que chaque extrémité évite : pas de recherche NAT, pas d'état de traduction, un en-tête plus simple. Là où elle perd, c'est la maturité du peering, certains chemins prenant plus de sauts. Sur un réseau bien connecté, la réponse est la parité, avec des gains sur les opérateurs qui passent par du CGNAT.

Implications sécurité : pare-feu, NAT et multicast

Le NAT n'a jamais été un contrôle de sécurité, mais il cachait les hôtes par accident. Sous IPv6, chaque adresse est joignable depuis Internet : le pare-feu fait tout le travail.

Trois règles. Écrivez les deux politiques : une règle iptables ne fait rien pour l'IPv6, doublez-la en ip6tables ou passez à nftables. Refusez tout en entrée par défaut, puis n'ouvrez que ce que vous servez. Et ne coupez pas tout l'ICMP : la découverte de voisins et la détection d'adresse dupliquée en ont besoin.

Regardez sur quoi les services s'attachent : un daemon sur 0.0.0.0 est IPv4 uniquement, tandis que le même outil sur :: peut accepter une connexion IPv6 que vos règles ont ratée.

Séparez tôt les services internes des services face Internet. Une base de données qui ne répond qu'à l'application sur la même machine doit s'attacher à la loopback ou à une plage IPv6 interne, pas globale, car l'IPv6 donne à chaque service une adresse routable dès que vous l'activez. Les adressages link-local et unique-local existent pour ce trafic interne : s'en servir ramène votre surface d'attaque aux seuls ports que vous publiez exprès.

Coût, disponibilité et location d'IPv4

Ici les protocoles cessent d'être équivalents. Les registres Internet ont épuisé leurs allocations IPv4 il y a des années : les nouvelles adresses viennent d'un marché secondaire, louées au mois. Ce coût s'inscrit d'abord dans la feuille de tout fournisseur cloud, puis dans la vôtre.

L'IPv6 n'a pas un tel marché. Chez Kimsufi, IPv4 et /64 arrivent avec la machine : l'IPv6 est une capacité Internet gratuite que vous possédez. L'écart se creuse : les loyers IPv4 ne vont que d'un seul côté, tandis que l'allocation IPv6 que vous détenez coûte le même zéro pour toujours. Construire beaucoup d'endpoints Internet en IPv6 évite la facturation par IP et reste scalable à mesure que l'usage pousse.

Déploiements dual stack : quand et pourquoi ils ont du sens

Le dual stack, c'est les deux protocoles sur une seule interface, chacun avec ses adresses, ses routes et ses règles. Un client résout un nom, reçoit un enregistrement A et un AAAA, et Happy Eyeballs fait courir les deux : l'utilisateur obtient la connexion qui répond d'abord.

C'est le bon choix pour tout ce qui est sur Internet. Les équipements anciens continuent en IPv4 pendant que les réseaux mobiles IPv6-only vous atteignent nativement : votre déploiement couvre tout Internet. Le coût est opérationnel : deux politiques de filtrage, deux enregistrements DNS, deux contrôles.

Chemin de migration : activer IPv6 sur votre serveur dédié

Cinq étapes, aucune ne réclame de downtime :

• Lisez votre préfixe. Prenez IP, préfixe et passerelle dans votre control panel ; la passerelle se termine d'habitude par ff:ff:ff:ff:ff.

• Configurez l'interface. Ajoutez adresse et préfixe, puis la route par défaut, via netplan ou systemd-networkd.

• Doublez vos règles de filtrage. Couvrez l'IPv6 avant de publier quoi que ce soit.

• Publiez un enregistrement AAAA. Tant qu'il n'existe pas, rien ne vous atteint par le protocole récent.

• Testez depuis l'extérieur. Contrôlez la connectivité depuis un réseau IPv6, pas depuis la boîte, avant de déclarer le déploiement terminé.

Vérifiez depuis l'extérieur avant d'annoncer quoi que ce soit. Un test d'accessibilité en ligne vous dit si Internet voit votre adresse IPv6, ce qu'un ping local ne peut pas. Confirmez que l'enregistrement AAAA se résout, vérifiez que l'IP répond sur les ports publiés, et relancez les mêmes tests en IPv4 pour distinguer une panne de protocole d'une panne applicative. Les suites en ligne couvrent les deux versions d'IP en une passe et confirment que votre support IPv6 est actif.

💡 Astuce : SLAAC gère l'adressage tout seul. DHCPv6 ne sert que si vous devez décider centralement de l'IP reçue par chaque équipement. Sur une machine unique, un réglage statique est plus simple.

Compatibilité avec les plateformes et applications populaires

Les logiciels modernes sont compatibles. Nginx, Apache et Postfix supportent IPv6 de série, et chaque distribution mainstream inclut le support : le support fabricant bloque rarement un rollout.

Docker n'activera pas l'IPv6 pour les conteneurs à moins que vous ne le demandiez : il faut un réglage daemon explicite. Certaines API SaaS, passerelles de paiement et plateformes de licence publient encore des endpoints IPv4 only : une route sortante IPv4 reste nécessaire. Une application ancienne peut ne s'attacher qu'en IPv4, où la mise à jour est la seule issue. Rien de tout ça ne bloque un rollout dual stack, mais ça explique pourquoi un setup IPv6-only reste rare.

À la couche application, la panne habituelle n'est pas le protocole mais le code autour : une IP validée par une regex écrite pour quatre octets, ou une colonne dimensionnée à 15 caractères. Ces bugs surgissent à la première connexion IPv6, pas avant.

Anticiper : adoptions IPv6 et épuisement d'IPv4

L'épuisement d'IPv4 n'est pas une prévision. Les registres Internet ont atteint leurs limites et sont passés aux listes d'attente, et les opérateurs ont répondu en faisant tourner IPv6 en interne avec du NAT64 et des passerelles de tunnel en bordure. C'est la situation actuelle, et la raison pour laquelle l'adoption grimpe pendant que personne ne coupe IPv4.

L'essentiel de la croissance d'Internet arrive désormais en IPv6, car c'est ce que distribuent les FAI mobiles et résidentiels. Si votre service est IPv4-only, ces utilisateurs vous joignent quand même, mais par une traduction opérateur dont vous héritez le surcoût et les angles morts de journalisation.

Pour une machine dédiée, la conséquence est simple : IPv4 devient lentement plus cher, IPv6 reste gratuit. L'activer maintenant est un moyen peu coûteux de se préparer au futur. La même limite vaut pour une baie ou un datacentre entier, car tous les datacentres achètent sur le même marché.

Matrice de décision rapide : IPv4, IPv6 ou dual stack

Conclusion

Il ne reste pas de décision IPv4 vers IPv6 pour la plupart des projets, seulement un ordre d'exécution. Gardez IPv4 pour les clients et API qui en ont besoin, allumez le /64 IPv6 que vous ne payez pas, et écrivez les deux politiques de pare-feu avant de publier. Le travail de compatibilité grandit chaque année.

Prêt à construire sur les deux protocoles ? Les machines Kimsufi démarrent à 9,99 €/mois, avec une IPv4 dédiée, un /64 IPv6, l'Anti-DDoS et l'accès root inclus.

FAQ