IPv6 fête ses 30 ans… mais il reste encore du chemin à parcourir
Bon anniversaire (et bonne année) !
30 ans, une éternité pour Internet et le numérique… et pourtant, le protocole IPv6 est loin d’avoir remplacé IPv4 qui est malgré tout à bout de souffle (à cause de la pénurie d’adresses). Si les internautes français sont plutôt bien lotis, ce n’est pas le cas partout dans le monde.
En décembre 1995, l’Internet Engineering Task Force publie la RFC 1883 intitulée « Internet Protocol, Version 6 (IPv6) Specification ». Elle fixait au passage le nom de ce qui était parfois appelé IP Next Generation ou IPng. Les spécifications d’IPv6 ont été finalisées quelques années plus tard, en décembre 1998 avec RFC 2460.
En guise d’introduction, il était précisé que l’« IP version 6 (IPv6) est une nouvelle version du protocole Internet, conçue pour succéder à IP version 4 (IPv4) », dont la RFC 791 datait de septembre 1981. La principale nouveauté était le passage des adresses de 32 à 128 bits. D’autres changements étaient aussi de la partie, comme une simplification du format d'en-tête. IPv6 intègre aussi « des fonctionnalités permettant de renforcer la sécurité par défaut et d’optimiser le routage », explique l’Arcep (le gendarme des télécoms en France).
667 millions d’adresses IPv6… par mm² !
La différence est très importante puisqu’on passe de 4,3 x 10⁹ (soit 4,3 milliards) à 3,4 x 10³⁸ adresses possibles, soit une quasi-infinité à l'échelle de la Terre, puisque cela correspond à environ 667 millions d’adresses IPv6 pour chaque millimètre carré de surface terrestre.
4,3 milliards d’adresses peuvent sembler beaucoup, mais ce n’est pas le cas. Le RIPE NCC (Network Coordination Centre, en charge de l'Europe, du Moyen-Orient et de certaines régions d’Asie centrale) est « à court d’adresses IPv4 » depuis fin 2019. Les alertes avaient été lancées des années auparavant et la solution existait déjà depuis longtemps avec IPv6. Mais la transition est longue, très longue… elle n’est toujours pas terminée en 2026.
Cette même année, l’Arcep a décidé « d’initier la création d’une Task-Force IPv6, co-pilotée avec Internet Society France ». Son but est de « favoriser l’accélération de la transition vers IPv6 en permettant aux participants d’aborder des problèmes spécifiques et de partager les bonnes pratiques ».
La France en tête du taux d’utilisation d’IPv6 !
L’Arcep tient à jour une carte du taux d’utilisation d’IPv6, qui correspond au « pourcentage d'utilisateurs raccordés en IPv6 par leur fournisseur d'accès à internet ». Selon le dernier décompte de décembre 2025, la France est… en première position avec 75,1 %, devant l’Inde à 73,1 % et la Malaisie à 67 %.
Les États-Unis sont 11ᵉ avec 56,4 %. Les pays africains sont dans le bas du classement avec 27 % au maximum pour la République du Congo, contre 0,2 % seulement en Algérie.
En Afrique d’ailleurs, la situation était compliquée en 2025 avec des doutes sur des élections à l’AfriNIC et une question d’influence de brokers d’IP, le tout sur fond de bataille juridique et de pénurie d’IPv4. Il faut dire que l’« AfriNIC est le dernier registre internet régional à avoir des blocs d’adresses IPv4 à distribuer », nous expliquait Pierre Bonis, le directeur général de l’Afnic qui gère les noms de domaine en France. Cela attise donc les convoitises.
Risque de scission d’Internet : IPv4 et IPv6 « ne sont pas compatibles »
En France, l’Arcep publie chaque année un baromètre de la transition vers IPv6. Le dernier date de juillet 2025. Le régulateur y rappelait que IPv4 et IPv6 « ne sont pas compatibles », ce qui implique un risque de scission d’Internet. En effet, un service ou un site en IPv6 seulement (c’est-à-dire sans adresse IPv4) n’est pas accessible aux utilisateurs qui n’ont qu’une adresse IPv4, et vice-versa.
IPv6 : la France passe en tête au niveau mondial, mais la route est encore longue
Ce n’est pas qu’une chimère, comme l’expliquait l’Arcep : « Bien que ce ne soit pas encore le cas en France, en Inde, des sites web indiens importants ne sont actuellement plus accessibles qu’en IPv6 et la Chine a planifié l’arrêt complet d’IPv4 en 2030 ».
En République tchèque, le gouvernement a annoncé la fin des services officiels accessibles en IPv4 à partir du 6 juin 2032. Un compte à rebours est lancé. Il reste 2346 jours.
Cinq grandes étapes, la première d’ici 2 à 3 ans ?
L’Arcep prévoit cinq grandes étapes de la transition mondiale vers IPv6 :
- IPv6 est activé par défaut sur la quasi-totalité des offres grand public
- IPv6 est activé par défaut sur la quasi-totalité des offres grand public, pro et entreprises
- Une part non négligeable des sites web sont hébergés en IPv6 uniquement
- Une part non négligeable des FAI ne proposent plus d’IPv4
- La majorité des sites abandonnent IPv4
La première étape « devrait être atteinte au cours des trois prochaines années ». En France, Bouygues Telecom, Orange et Free sont à plus de 90 % de clients activés en IPv6 sur le grand public. Sur le pro, Orange était à la traine au dernier décompte avec 57 % fin 2024. Restait SFR à 54 % sur le grand public et 10 % sur le pro, mais la marque au carré rouge prévoyait de dépasser les 90 % de clients activés fin 2026.
Sur le mobile, Free était pendant longtemps le vilain petit canard, mais le fournisseur d'accès à Internet a enfin activé ses clients en mars 2025.
Si vous vous demandez comment fonctionne Internet, nous avons pour rappel publié un long dossier sur le sujet :
- [Dossier] Internet, mode d’emploi : une URL c’est quoi ? (partie 1)
- [Dossier] Internet, mode d’emploi : de l’URL à l’IP avec le DNS (partie 2)
- [Dossier] Internet, mode d’emploi : trouver le bon chemin avec BGP (partie 3)
- [Dossier] Internet, mode d’emploi : les CDN, quels sont leurs réseaux ? (partie 4)
- [Dossier] Internet, mode d’emploi : peering, transit, points d’échange (partie 5)
- [Dossier] Internet, mode d’emploi : fibres optiques et câbles sous-marins (partie 6)
Commentaires (93)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 02/01/2026 à 15h05
D'après les données, on est quand même à 42 % d'adoption, avec un gros push dans les 5 dernières années.
Le 02/01/2026 à 15h14
Le 02/01/2026 à 15h21
Faire aussi comme nos amis tchèques, et mettre une date butoir à la désactivation d'IPv4 sur tous les sites gouvernementaux.
Le 02/01/2026 à 18h30
Le 02/01/2026 à 15h19
Le 02/01/2026 à 15h22
Le 02/01/2026 à 18h31
Le 03/01/2026 à 12h45
Le 03/01/2026 à 13h39
Dans l'autre sens, un reverse proxy nginx dans un bastion fonctionne bien. Il faut par contre penser à utiliser des adresses ULA dédiées pour la communication en « proxy protocol » entre le reverse proxy et le serveur web.
Le serveur web doit donc écouter normalement sur son adresse de service et écouter en proxy protocole avec restriction d'adresse source, sur une adresse ULA.
Pour attribuer les adresses de service, les blocs supplémentaires sont les bienvenus car ce ne sont pas les mêmes blocs et cela permet d'avoir des adresses de service très différentes des adresses d'administration.
A domicile, il est déjà possible d'utiliser la délégation pour utiliser un préfixe différent pour ces deux usages.
Le 03/01/2026 à 14h22
Il faudra probablement attendre la migration de GitHub sur azure pour s'éviter cette peine.
Modifié le 04/01/2026 à 00h13
Du coup j'ai une question pour les pros de l'IPv6 ici. Il me semble que le problème à résoudre est que tout le monde soit en IPv6, mais pas que tous soient obligatoirement en IPv6 only.
A mon sens, il faut d'abord que les serveurs soient en IPv6. Je suis d'accord avec vous qu'il y en a marre de ces gros services et hébergeurs qui n'ont pas d'IPv6, c'est là-dessus qu'il faut avancer en premier. Et en toute logique ça devrait être facile puisqu'il y a des gens du métier derrière.
Pour ce qui concerne les utilisateurs, je ne comprends pas pourquoi mettre en place tout le bazar de transition cité ici pour pouvoir accéder à un service resté en IPv4, alors qu'il suffit de laisser tourner IPv4 sur son réseau local. Il fonctionnait déjà, ne gênait personne, et même si on se retrouve souvent derrière un CGNAT de nos jours, je ne trouve pas ça grave car il ne sert qu'en secondaire et on ne l'utilise pas pour les connexions entrantes.
Je ne comprends pas votre problème avec la double stack, au point d'ajouter tous les machins cités pour ne pas l'utiliser alors qu'elle est déjà de base dans tous les OS. Pour ma part je ne rencontre aucun problème à l'utilisation d'IPv4 et IPv6 chez moi en double stack. Quand les fournisseurs d'accès commenceront à vouloir supprimer IPv4, je comprendrai, mais d'ici-là, si vous pouvez m'expliquer votre démarche...
Le 04/01/2026 à 10h25
C'est la théorie des jeux appliquée aux changements:
- les sites disent: « tant que les clients ne seront pas majoritairement en IPv6, je n'ai pas intérêt personnel à offrir mon service en IPv6 » ;
- les FAI disaient: « tant qu'il n'y a pas de sites nécessitant IPv6, je n'ai pas besoin de mettre en place IPv6 pour mes clients ».
Si on regarde la complexité:
- Côté clients fixe, gérer une double pile est très simple : Mme Michu n'a rien à raire de particulier ;
- Côté client mobile: certains opérateurs proposent de la double pile (SFR), et d'autres imposent le 464XLAT (Bouygues), qui est géré nativement par android depuis plus de 10 ans donc, cela marche pour les téléphones, mais ce protocole ne fonctionne pas bien sur les modem 4G ;
- Côté serveurs, c'est déjà plus complexe car l'architecture est radicalement différente: les services sont gérés dans des machines virtuelles ou des conteneurs protégés derrière des bastions.
- Côté opérateurs, gérer un cœur de réseau en double pile est par contre trop complexe donc on préfère encapsuler un protocole dans un autre.
La transition se passe donc dans les fait en deux phases:
1 - la création des chemins directs IPv6: avec les anciens protocoles de transition comme terredo, on a pu créer des chemins capables de faire transiter des paquets IPv6 dans des réseaux IPv4 only, en les encapsulant si nécessaire dans des paquets IPv4 ;
2 - la disparition des chemins directs IPv4: avec des protocoles de transition comme DNS64, NAT64, 464XLAT, on fait le transport des paquets IPv4 dans un réseau IPv6 only.
La bascule a déjà eu lieu depuis environ 2008 (de mémoire), nous somme donc en phase 2 et la plus-part des cœurs de réseau opérateurs sont passé d'IPv4 à IPv6 désormais. Cela a permis au passage de récupérer toutes les plages d'adresses IPv4 internes pour les utiliser pour les clients.
Quand on compare les problématiques restantes, il est plus simple de débuter par les clients et c'est pour cela, je pense, que l'ARCEP a mis la pression sur les opérateurs pour qu'ils se bougent sur IPv6.
Côté mondial, les clients IPv6 sont très nombreux donc il devient difficile de justifier la position de gens comme github.
Si je résume donc:
- Les cœurs de réseau opérateur sont en IPv6 et les transitaires sont à 100% opérationnels pour IPv6 ;
- Les clients sont en cours de passage à IPv6 sauf dans certains cas où les opérateurs font de la me
- Les services web n'ont plus aucune excuse valable pour ne pas proposer leurs services en IPv6.
Par rapport à tes questions spécifiques:Le problème à résoudre est de terminer la transition vers IPv6 pour mettre fin à la complexité d'avoir à gérer les deux.
En fait, c'était plus simple d'ajouter la connectivité IPv6 aux clients et c'est là que les plus gros progrès ont été fait.
Pour cela, le besoin immédiat est effectivement de faire passer en IPv6 les services résistant encore à cette transition. A chaque époque ses dinosaures...
Certaines personnes se disant du métier sont réfractaires à IPv6, un signe manifeste qu'ils ne sont pas si spécialistes que cela. Le problème est que savoir configurer un NAT44 et un DHCP ne suffit pas pour pouvoir prétendre être un spécialiste.
Malheureusement, encore très récemment, des profs en école d'ingé faisaient l'impasse sur IPv6 donc pas mal de gens « du métier », sont en fait des quiches en réseau. On les repère facilement quand ils sont en plein déni de leur manque de compétence et disent: « IPv6, ça sert à rien ».
Si tu n'a pas de serveurs qui tournent chez toi et que tu ne fait pas appel à un modem 4G avec une puce Bouygues, tu n'as pas besoin de ce bazar de transition.
C'est le rôle des opérateurs de se débrouiller pour que tout soit transparent de ton côté jusqu'au jour où ils n'auront plus d'obligation de te fournir une connectivité IPv4.
C'est plus simple à gérer pour une grosse infrastructure. Un complément de réponse par Moji pourrait être utile pour avoir le point de vue hébergeur.
Modifié le 05/01/2026 à 11h03
Même en ayant des serveurs qui tournent chez toi, pas besoin de protocoles de transition, on peut le faire écouter sur les 2 adresses. Après je fais peut-être pas des trucs aussi avancés que vous avec des serveurs HTTP et proxys de toute sortes, moi en IPv4 c'est 1 port externe = 1 serveur sur 1 machine, je route le port depuis le NAT et voilà, et en IPv6 on fait ce qu'on veut sans proxy vu qu'on n'est plus limité par les "ports externes".
Après que les opérateurs de réseau préfèrent encapsuler un protocole dans l'autre, ça les regarde, mais de mon côté j'ai une adresse IPv4 et je ne vois pas l'intérêt de refuser de l'utiliser au profit de protocoles de transition complexes. Si je me retrouvais en CGNAT (pas le cas actuellement), alors mes serveurs ne seraient simplement plus accessibles qu'en IPv6. Et le jour où je n'aurai plus d'IPv4, là je commencerai à me poser la question des protocoles de transition s'ils sont encore utiles.
Le 05/01/2026 à 19h24
Pour être accessible en IPv4 et en IPv6, chaque service écoute donc sur deux adresses:
- une adresse IPv6 directe ;
- une adresse IPv6 sur laquelle est renvoyée le trafic IPv4 concernant le service.
Ce n'est donc pas si différent de ta configuration.
Le 05/01/2026 à 21h28
Le 02/01/2026 à 15h50
Le 02/01/2026 à 18h31
Le 02/01/2026 à 20h47
J'ai une infrastructures perso étalée dans plusieurs zones géographiques en plus des infras aws de mes clients donc je ne me vois pas faire un convertisseur maison à chaque point de sortie.
Le 03/01/2026 à 13h53
Mais on est bien d'accord que c'est à github de se sortir les doigts.
Le 02/01/2026 à 17h16
Le 02/01/2026 à 18h38
Et chez Bouygues, c'est pareil car ils imposent le protocole 464XLAT pour avoir IPv4 et IPv6 et ils brident en IPv4 les appareils qui ne sont pas compatibles, même si on sélectionne IPv6 only.
Quelle bande de
Modifié le 02/01/2026 à 20h51
*standardisé à prendre avec des guillemets pour tous ceux qui connaissent un peu le milieu des télécoms malgré le travail du 3gpp/gsma
Le 03/01/2026 à 13h33
Sur un modem 4G, la compatibilité VoLTE n'a aucun sens vu que ce genre d'appareil de gère du tout pas la voix.
Du coup, pas mal de monde attend avec impatience la fin du contrat d'itinérance entre free et Orange pour avoir enfin un accès à IPv6, quel que soit le terminal.
Modifié le 03/01/2026 à 17h08
Le 02/01/2026 à 18h47
Quelques petits exemples:
- les services dns de systemd
- samba
- mysql ou mariadb
- docker
- virtualbox
Avec samba, j'ai du faire de l'ingénierie inverse sur la config de mon synology pour trouver la bonne syntaxe pour avoir des partages windows IPv6 only, mais c'est possible au moins.
Avec docker, il était impossible de se passer d'IPv4 la dernière foi que j'ai tenté le coup. Du coup, c 'est du bricolage.
Et les commandes sous linux comme dig: par défaut, dig utilise IPv4 et renvoie les enregistrements A. Moi, ce qui m'intéresse c'est d'avoir en standard une requête en IPv6 et les enregistrements AAAA
Il va vraiment falloir que les administrateurs système se bougent les fesses.
Le 02/01/2026 à 20h01
Le 03/01/2026 à 13h25
Docker, c'est uniquement sous linux et plus dans un environnement de production il me semble
Le 03/01/2026 à 13h39
Podman est un gestionnaire de containers basé containerd, compatible OCI, rootless et entièrement compatible Docker (on peut faire alias docker=podman sans problème). Le projet reçoit des contribs de Red Hat (c'est même le système de container par défaut il me semble dans cette famille), IBM, Suse ou Debian.
Tous mes containers tournent avec ça à titre perso et j'en ai qui ont de l'IPv6 sans rien leur avoir demandé.
Le 03/01/2026 à 14h00
Peux-tu administrer des conteneurs à distance comme je le fais avec mes VM via libvirt et virtual machines manager ?
Modifié le 03/01/2026 à 14h33
Mais les containers podman sont administrables via Cockpit.
Pour ma part, ils sont gérés en tant que services par systemd et je les gère via un bot Discord maison.
Le 03/01/2026 à 14h55
Le 03/01/2026 à 16h07
podman run ...), et mes containers sont sur un serveur physique (un micro PC qui est mon ex-HTPC remplacé par un Steam Deck).Le 03/01/2026 à 13h44
Non plus. Après, Docker sous Windows présente quand même moins d'intérêt, car passe par de la virtualisation.
Et pour les environnements de dev/prod, je ne suis pas assez spécialiste pour ça, mais de ma vision, c'est clairement utilisé dans les deux cas : et pour tester, et pour déployer. Après tout, ce sont des technologies qui sont très efficace avec une bonne CI/CD !
Le 03/01/2026 à 14h53
Jusqu'à présent, les conteneurs Dockers, c'était plus pour faire tourner des services genre base de données, serveur web ou autre, sur un pur serveur et donc sans interface graphique. Un usage très différent et complémentaire en fait.
Le 02/01/2026 à 19h54
Le 06/01/2026 à 15h41
Le 03/01/2026 à 10h11
Il va y avoir un gros taf pour les pointage de toutes les zones DNS également.
Le 03/01/2026 à 10h44
Le 04/01/2026 à 11h13
pour fonctionner, les adresses Additional IPv6 ne peuvent être utilisées qu'avec le réseau vRack. Il s’agit de la plus grande différence par rapport aux adresses Additional IPv4 qui peuvent également être directement attachées à des serveurs ou des instances ;
Je vais demander des précisions au support. Le RZO n'est clairement pas mon fort.
J' n'utilise que des serveurs dédiés.
Le 03/01/2026 à 10h40
Le 03/01/2026 à 12h27
Le 06/01/2026 à 13h03
Le 03/01/2026 à 13h28
Du coup, ceux qui ne sont pas impactés par cette pénurie se contentent de dire « je m'en fout, je n'en ait pas besoin ».
Il serait temps d'élargir le sujet et Next est le lieu idéal pour cela.
Modifié le 03/01/2026 à 17h54
L'idée de mettre de l'hexadécimal est mauvaise.
Les adresses sont aussi devenues trop longues.
A cause de tout ça le cerveau des admins n'est pas capable de mémoriser les adresses.
Le 03/01/2026 à 18h16
Voilà pour l'utilisateur 119612 de Next aussi nommé linconnu.
Le 03/01/2026 à 18h41
Le 03/01/2026 à 18h56
Les dns avec dns-sd, mdns et autres, ça merdoie parfois et dans ces cas là t’es bien content d’avoir ton ipv4.
Le 03/01/2026 à 19h32
Le 04/01/2026 à 08h54
Le 03/01/2026 à 21h00
En ce qui concerne mDNS, c'est avec IPv4 que cela merdoie vu que cela repose sur les adresses APIPA. En IPv6, ce ne sont pas les mêmes adresses donc il n'y a jamais de conflit entre DNS et mDNS.
Pour le firewall, windows en comporte un par défaut depuis XP SP3 donc les PC ne sont pas à poil. Et avec la magie de uPnP, les ports s'ouvrent tout seuls sur la box pour permettre aux services des ordinateurs de recevoir du trafic externe. Et cela marche même quand on a rien demandé.
Mme Michu n'est donc pas mieux protégée en IPv4 qu'en IPv6.
Le 04/01/2026 à 09h56
Bien sûr que tout fonctionne aussi en ipv6. C’est juste que si tu analyses le ratio bénéfice / perte, tu as d’un côté :
* ipv4, déjà en place, avec des solutions de contournement fonctionnelles pour tous les problèmes, et des docs pour tous tes produits
* ipv6, qui te demande de tout réapprendre, a des adresses non mémorisables, et est plus complexe, avec une doc hasardeuse (dhcpv6, on en parle ?)
Pas étonnant que la transition soit si longue. La seule chose qui force la bascule, au final, c’est la pénurie.
Modifié le 04/01/2026 à 11h15
En entreprise, si tu es sous windows et que tu n'a pas les droits admin, quand tu passe en APIPA, tu dois redémarrer ton ordi pour retrouver le réseau en Ipv4. Pas top en fait.
Dans les faits, même avec des solutions de contournement, cela ne fonctionne pas si bien. Cela devient criant avec les solutions de conférence pour lesquelles on doit déployer des belles usines à gaz bien complexes pour tenter de faire discuter des ordinateurs logés derrières des NAT44.
C'est complexe, cela engendre des coûts car le NAT44, les serveurs TURN, cela consomme des ressources processeur.
IPv6 demande de penser autrement car il faut apprendre à oublier les bidouilles créées pour contourner les problèmes d'IPv4: le NAT, DHCP, TURN...
Concernant la mémorisation des adresses, c'est juste un running gag. Tu peux néanmoins te faire des adresses ULA mémorisables si tu le souhaites: fd33:dad:cafe:1605::53 pour un serveur DNS par exemple.
La doc hasardeuse n'est pas le fait des créateurs d'IPv6 mais des réfractaires qui ajoutent leurs grains de sable en désespoir de cause.
DHCPv6, c'est une chose immonde demandé par les inconditionnels d'IPv4 et que les groupes de travail IPv6 on accepté par erreur. Ils le regrettent désormais. Mais on peut très bien vivre sans.
Si tu regarde les choses objectivement, IPv6 est plus simple à mettre en œuvre car il rend caduque tous les bricolages qu'il était nécessaire de configurer avec IPv4.
Modifié le 04/01/2026 à 12h05
Dans la boîte où je bosse (~50 personnes), ça va prendre au minimum une semaine de boulot à l’admin sys, pour zéro valeur ajoutée immédiate pour l’entreprise, et un rajout de maintenance à long terme. Tu m’étonnes qu’il ne soit pas pressé.
À la maison, le bilan du déploiement d’ipv6, c’est que j’ai dû passer à un proxy sni, car sinon il faut déployer les certificats sur deux machines (le serveur pour ipv6 et le reverse proxy pour ipv4), ce qui est la merde avec let's encrypt. Ça m’a là aussi pris beaucoup de temps, pour zéro valeur ajoutée au final. Je connais les adresses ipv4 de mes serveurs assignées par dhcp, en v6 avec slaac, aucune idée.
Je comprends la nécessité d’ipv6, et je ne nie pas ses qualités. Mais faut être réaliste, si c’était aussi simple à déployer que certains le disent et que ça réglait des problèmes qu’on ne sait pas régler autrement, ça fait 20 ans que la transition aurait été faite. L’inertie a ses raisons.
Le 04/01/2026 à 13h38
Pour la maison, j'ai moi même des serveurs derrière un proxi IPv4 et il n'y a qu'un certificat let's encrypt pour IPv4 et IPv6 sur le serveur uniquement. Le proxy n'a pas besoin de s'en occuper.
Je pense donc que ton problème vient d'une mauvaise architecture et je peux t'aider à la corriger si tu veux.
Utiliser SLAAC pour des adresses de services n'est pas une bonne pratique mais tu peux tout de même prévoir quelles adresses seront données dès lors que tu enlève la confidentialité. Tu as alors des adresses créées selon l'adresse MAC de ta machine.
L'idéal est de séparer les adresses IPv6 servant à administrer des adresses sur lesquelles tu va accueillir du public. Tu peux donc ajouter des adresses statiques simples à tes serveurs pour tes services et tu aura la maîtrise de ton réseau.
Les difficultés auxquelles tu fais face sont liées à la transition : c'est la cohabitation entre les deux protocoles et les protocoles de transition qui occasionnent ces difficultés. C'est la même chose partout: cela coûte de changer tout simplement.
Si on reprend ton réseau avec tes serveurs, avec IPv4, tu dois utiliser un reverse proxy et un NAT44 alors que tu n'as qu'un pare-feu et des routes à annoncer en IPv6. C'est bien plus simple à mettre en place et à administrer. Le gain est donc bien réel.
Au niveau des problèmes que l'on ne sait pas régler autrement, il y a le « roaming ». Avec IPv6, tu peux avoir simultanément plusieurs routeurs ver Internet et donc plusieurs préfixes. Un ordinateur peu passer progressivement de l'un à l'autre. Pour un téléphone, cela permet de passer d'une antenne à l'autre sans perte de connexion quand on se déplace.
Modifié le 04/01/2026 à 17h41
C’est possible. J’ai cherché, je n’ai pas trouvé. J’ai plusieurs ipv6 publiques, pour chaque VM que je veux accessible à l’extérieur, avec chacun leur nom enregistré par DNS (et pas forcément sur le même domaine), mais une seule ipv4 publique, là aussi enregistrée sur un dns (plusieurs enregistrements, donc). En ipv4, ça passe par un reverse proxy, via l’enregistrement A. En ipv6, ça tape direct la bonne VM via l’enregistrement AAAA. Pour faire du https, en ipv6, je n’ai pas le choix, le certificat doit être sur la VM finale. Mais en ipv4, soit je fais du proxy sni, avec les problèmes que ça engendre, soit je fais de la terminaison ssl sur le reverse proxy (ce que je voulais éviter). Et si je fais la terminaison ssl, ça m’oblige à dupliquer le certificat. Si tu as une autre solution, je suis preneur. Pour mon usage, le proxy sni en ipv4 fait le taf.
Tu as en tout cas raison sur un point : c’est bien la cohabitation qui fout la merde. En pur ipv6, je n’aurais pas de problème. Mais je n’ai pas le choix : je dois continuer de fonctionner avec ipv4.
C’est ce que je fais, et tu as probablement raison, je devrais plutôt en assigner des fixes. Sur ce point j’ai probablement fait un mauvais choix. J’essaierai de m’en souvenir pour les prochaines VMs.
Ça par contre ça me semble effectivement un très bon argument. Cela dit, il me semble que pour la téléphonie ils ont trouvé des solutions sans ipv6.
Le 04/01/2026 à 18h31
Il faut par contre que le serveur écoute sur deux adresses distinctes:
- une adresse globale pour les flux IPv6 directs
- une adresse pour les flux en proxy protocol : je te conseille une adresse ULA.
Dans nginx, tu déclare ton proxi de flux dans le répertoire /etc/nginx/modules-available
Tu peux appeler ta config : « 60-http-IP4-proxy.conf » et y mettre l'exemple suivant:
stream {
# map services
map $ssl_preread_server_name $next_hop {
www.mondomaine.com to_www;
# on peut ajouter d'autres noms de machines et de domaines
default to_www;
}
# main web server
upstream to_www_http {
server wwwproxy:80;
}
upstream to_www_https {
server wwwproxy:443;
}
# https proxy
server {
listen 10.0.0.80:443;
ssl_preread on;
proxy_protocol on;
proxy_pass "${next_hop}_https";
}
# log configuration
log_format mini '$remote_addr "$upstream_addr" "$next_hop"'
access_log /var/log/nginx/stream-46proxy-access.log mini;
error_log /var/log/nginx/stream-46proxy-error.log;
}
Il te faudra remplacer 10.0.0.80 par l'adresse IPv4 de ton serveur de proxi, le nom wwwproxy par le nom dns correspondant au port d'écoute proxy protocol de ta vm et, tu l'auras deviné, www.mondomaine.com par le tiens.
Côté serveur web, il va falloir quelques lignes supplémentaires pour accepter le flux venant du proxy. Voici un début de config pour le serveur https:
# https server configuration
server {
# base server configuration
server_name www.mondomaine.com;
root /var/www/www.mondomaine.com;
# HTTPS configuration
listen www.mondomaine.com:443 ssl http2;
listen wwwproxy:443 ssl http2 proxy_protocol;
set_real_ip_from my_proxy_machine;
real_ip_header proxy_protocol;
ssl_certificate /etc/letsencrypt/live/www.mondomaine.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.mondomaine.com/privkey.pem;
Dans cet exemple, www.mondomaine.com correspond dans ton fichier hosts à ton adresse IPv6 globale, wwwproxy correspond dans ton fichier hosts à ton adresse de réception du flux (une IPv6 ULA idéalement), et my_proxy_machine correspond dans ton fichier host à l'adresse qui sera utilisée par le proxy pour envoyer le flux (une IPv6 ULA idéalement).
Modifié le 04/01/2026 à 22h31
real_ip_header proxy_protocol; . Il faut que j’essaie ça, si avec ça j’ai bien les ips source et non l’ip du reverse proxy pour les connexions ipv4 dans mes logs serveur, je te dis un grand merci !
edit : autre différence, depuis le proxy j’attaque le serveur en ipv4. Peut-être qu’il faut que je change ça aussi.
Le 07/01/2026 à 18h10
Le 06/01/2026 à 15h45
Modifié le 04/01/2026 à 00h33
Ca se fait donc très bien sur une box préconfigurée pour des particuliers, et reste compatible avec UPnP pour ouvrir des ports à la volée, sans qu'il ne soit nécessaire de toucher à la config si on n'en a pas envie. Les box le proposent d'ailleurs déjà. Avec quelle qualité de protection, par contre je ne sais pas, mais leurs NAT ont aussi leurs trous de sécurité qui permet de passer au travers.
Par contre, franchement arrêtez de dire qu'on n'a jamais à taper une IPv6 parce qu'il y a le DNS. Y a plein de cas où il n'est pas utilisable, surtout quand on travaille dans les couches un peu basses ou quand on dépanne, et alors oui c'est casse-pied ces adresses hyper longues. La théorie c'est bien, mais la réalité c'est pas la théorie. Ça veut pas dire qu'on doit tout jeter pour ça, mais c'est un inconvénient et il ne faut pas le nier sinon le gens se braquent et c'est certainement une des causes majeures de la lenteur d'adoption.
Le 04/01/2026 à 11h23
Par exemple, pour tes DNS: préfixe::531 et préfixe::532
Et y il a le fichier host pour les machines qui ne peuvent pas compter sur le DNS. Cela fonctionne aussi bien qu'en IPv4.
As tu un exemple qui t'a demandé de taper une adresse super longue en ligne de commande ?
Modifié le 05/01/2026 à 11h33
- il faut aller sur le serveur lui-même ou s'y connecter à distance pour changer son IP
- si le préfixe change, il faut changer sur tous les serveurs. En théorie on devrait pouvoir spécifier la fin de l'adresse et que ça prenne le préfixe du RA, mais en pratique je ne crois pas avoir déjà vu où faire ce genre de config, mais j'ai peut-être raté un truc
- il faut tenir à jour le DNS local quand on change des IPs
Même si vous ne l'aimez pas, le DHCPv4 permettait de faire ces 3 choses depuis un même endroit centralisé, en plus d'avoir une liste des machines actuellement présentes sur le réseau avec leur MAC, leur IP et souvent leur nom, sans risque d'en oublier, chose que l'on n'a pas sans DHCP. On ne peut pas nier que c'est plus simple pour les admins.
Pour les adresses IPs à rentrer, je ne sais pas pourquoi tu précises "en ligne de commande" mais parmi les cas où on doit utiliser des adresses, sans être exhaustif :
- modification de la table de routage
- configuration des adresses d'écoute des serveurs
- configuration des routes des VPN, soit manuellement au montage, soit dans la config du VPN
- modification des entrées DNS ou du fichier host
- problème avec le DNS, où on peut vite être bloqué à devoir courir d'une machine à l'autre à recopier les adresses à la main alors qu'en IPv4 on peut encore espérer faire appel à ses souvenirs (toutefois sans garantie non plus) ou les recopier bien plus facilement
- réseau sans DNS, souvent le cas sur les petits réseaux locaux, on peut remplir le fichier host mais c'est à faire une fois par machine, et quand c'est un besoin ponctuel on le fait souvent pas
Tu me diras sûrement que ce sont des choses assez peu courantes. En effet, pour moi oui donc je ne m'en formalise pas plus que ça, mais pour un admin réseau qui fait ça toute la journée, je pense que c'est une charge supplémentaire, peut-être surévaluée, mais pas inexistante.
Le 05/01/2026 à 20h51
Pour les serveurs, il faut désactiver la confidentialité IPv6 qui va générer des adresses aléatoires et temporaires. Tu as alors le choix d'utiliser EUI64 qui va utiliser tes adresses MAC ou un autre mode qui va toujours générer la même adresse. Avec le mode EUI64, tu as mécaniquement une adresse IP liée à ton adresse MAC et sans prise de tête.
Si tu sais quelles adresses les machines vont s'attribuer automatiquement, tu n'as pas à aller sur chaque machine faire une recherche de son adresse. Un simple fichier excel permet ainsi de créer ton fichier host à partir de tes adresses MAC.
Formule excel pour avoir une EUI64 à partir de l'adresse mac notée en A2:
=SI($A2="";"-";MINUSCULE(CONCATENER(DECHEX(BITOU(HEXDEC(STXT($A2;1;2));2));STXT($A2;4;5);"ff:fe";STXT($A2;10;5);STXT($A2;16;2))))
Les adresses auxquelles tu va te connecter à tes serveurs en ssh seront donc fixes si tu es en interne. Si tu es chez un hébergeur, le préfixe ne va pas changer non plus.
Dès lors qu'un DNS est configuré sur le réseau, il est possible d'utiliser le nom dns pour configurer les services, de ssh à https.
Perso, pour me connecter à une machine en ssh, je n'utilise que des noms de machine.
En plus de cette adresse de base de machine, tu va pouvoir ajouter des adresses de services, globales ou locales, au choix, dont la partie machine peut se résumer à un numéro de port.
Le script d'attribution d'adresse peut faire une réolution dns pour déterminer l'adresse à partir de ton enregistrement DNS.
Les adresses qui peuvent changer sont donc les adresses de service: tes serveurs peuvent avoir des adresses fixes de services que tu peux changer dynamiquement via un service systemd si ton préfixe global est amené à changer. Il faut en suite redémarrer les services qui écoutent sur les adresses globales pour prendre en compte ces changements.
Pour éviter les problèmes lors de ces changements, il faut permettre aux service d'écouter sur des adresses que le noyau n'a pas encore:
echo 'net.ipv6.ip_nonlocal_bind = 1' | sudo tee /etc/sysctl.d/99-nonlocal_bind_ipv6.conf
Pour le routage, les annonces de route par défaut ou non, permettent aux machines de configurer automatiquement leurs tables de routage IPv6. Je n'ai jamais eu besoin de configurer manuellement ces tables chez moi alors que j'ai plusieurs préfixes délégués et des VLAN donc largement de quoi nécessiter du routage.
Mise à part dans les fichiers hosts ou config DNS, je n'utilise donc pas d'adresses IP codées en dur du tout.
Modifié le 05/01/2026 à 22h07
Chez un hébergeur ça arrive de changer de préfixe, si on change d'offre ou d'hébergeur. Ce serait mieux alors de pouvoir changer le préfixe une seule fois plutôt que sur chaque machine ou VM. C'est ce que fait le RA, mais pas sur des adresses courtes sauf si la réponse à ma première question est ci-dessus est oui.
Moi aussi au quotidien j'utilise mon DNS local et des noms de machines. Mais s'il n'est plus là je suis un peu embêté en IPv6, pas trop car les machines sont proches mais je m'embête un peu plus à recopier une adresse IPv6 de 16 caractères qu'une adresse IPv4 de 3 chiffres (préfixes exclus dans les 2 cas). C'est pas souvent pour nous mais plus souvent pour d'autres.
Oui il y a des automatismes pour les tables de routage, mais quand ça rate il faut bien mettre le nez dedans. Or il se trouve que réparer des trucs de toutes sortes qui foirent fait partie du quotidien des admins réseau, c'est pas une fois de temps en temps comme nous. Et y a pas de DNS pour les sous-réseaux.
Concernant les adresses de services, désolé je n'ai rien compris.
Tiens autre chose, comment faire pour donner au niveau d'un firewall de sortie de réseau des règles différentes en fonction de la machine qui communique ? L'adresse IPv6 qu'elle va utiliser est imprévisible car, entre toutes les adresses générées (j'en ai par exemple 8 à l'instant sur cette machine) dont certaines changeantes, on ne peut pas savoir laquelle va être utilisée pour du trafic sortant, et certaines adresses générées ne sont pas désactivables (cf l'adresse aléatoire de confidentialité sur Android non désactivable ou celle sur Windows qui demande une manip absconse pour la désactiver). On pourrait faire des VLAN ou utiliser les adresses MAC, mais on baisse de niveau, ce n'est plus de l'IP.
J'avais aussi des problématiques de multi-WAN avec équilibrage automatique mais je vais pas rajouter ça maintenant, peut-être plus tard.
Le 06/01/2026 à 00h20
Avec le script suivant, tu peux te reposer sur le dns pour l'attribution de tes adresses de service :
Avec DHCP, tu as besoins de connaître tes adresses MAC donc cela revient au même.
Pas besoin de rechercher une bidouille du système, tu peux faire cela toit-même et facilement avec un simple script bash: Tu peux faire un script lancé par cron qui va scanner les préfixes publiques et ajuster les adresses d'écoute de tes services puis redémarrer les services.
Le principe est simple: séparer les adresses d'écoute des adresse de machine.
Ta machine physique ou virtuelle ou ton conteneur possède à minima deux adresses IPv6: une link local et une globale ou ULA. Ces adresses sont configurées automatiquement par le système.
Le noyaux linux peut prendre en charge jusqu'à 16 adresses IPv6 par port réseau donc on peut s'en servir pour en ajouter d'autres en //.
En admettant que tu as appelé ton serveur « toto » et qu'il possède une adresse globale sur ton domaine publique « mondomaine.com », le nom dns de ton serveur sera donc:
- toto.local : en mDNS sur l'adresse link local
- toto.mondomaine.com : en dns sur l'adresse globale
Tu va pouvoir configurer ssh pour écouter sur toto.mondomaine.com avec sshkey mais en interdisant les mots de passe.
Si tu ajoute un serveur web, tu va créer un enregistrement dns www.mondomaine.com pointant sur une adresse courte de service que tu va attribuer à ton serveur via une commande
ip address addqui va bien en récupérant la sortie dedig -6 AAAA www.mondomaine.com.Au final, tu auras juste configuré ton DNS et les machines iront y chercher leurs adresses de services.
Avec les machines des utilisateurs, pour avoir le contrôle de ce qui sort et de qui vient la demande, il faut un proxy et android sait très bien les détecter et s'en servir. C'est ce que font 100% des sociétés à ma connaissance.
Après, tu peux deviner localement quelle adresse est utilisée pour les connexions sortantes :
- sous linux, la comande
ip ate liste des adresses marquées « temporary » qui sont sortantes et basées sur un algo aléatoire ; elles ont un paramètre preferred_lft qui indique pendent combien de temps elles sont encore préféré si c'est > 0 ;- sous windows, la commande
ipconfig /allva te lister des adresses temporaires dont certaines sont marquées « (déprécié) » et une seule marquée « (préféré) ».Le 06/01/2026 à 01h03
Non en DHCPv4 je n'ai pas besoin de connaître mes adresses MAC car je me souviens de quelle IP j'ai mis en bail statique pour les machines principales, ou au pire c'est une très petite plage que j'ai vite fait de balayer à la main. D'ailleurs en cas de panne totale du DHCP/DNS je peux remettre ces quelques IPs en statique sur ces machines et retrouver le réseau que je connais.
Merci pour l'explication sur les adresses de services, j'avais pas compris ce que tu voulais dire mais je fais déjà ça à au moins un endroit.
Le proxy pour contrôler en sortie ça m'emballe pas, c'est rajouter un logiciel et une couche et des problèmes potentiels de compatibilité. Je préfère des règles de firewall, et même avec le proxy je ne sais toujours pas comment reconnaître les machines. En effet je peux voir sur une machine quelle est son IP de sortie préférée (mais pas sur Android ou un appareil réseau encore moins ouvert), mais le firewall ou proxy qui est sur une autre machine n'en sait toujours rien.
Le 06/01/2026 à 14h14
Cela permet de dépasser les possibilités offertes de base et c'est même cumulable dans le cas d'IPv6, c'est là que cela devient super: pas besoin de choisir, on peut tout avoir en même temps.
Modifié le 06/01/2026 à 15h03
Une idée pour mon souci de reconnaître les machines depuis le routeur/firewall/proxy ? Car ça m'avait vraiment embêté à l'époque, j'avais pas trouvé de solution totalement fonctionnelle.
Modifié le 06/01/2026 à 20h31
Le 07/01/2026 à 11h27
Le 04/01/2026 à 20h17
Le 04/01/2026 à 20h22
Modifié le 03/01/2026 à 20h37
IPv6 a été pensé longuement par des gens qui s'y connaissent très bien et on largement pesé le pour et le contre de chaque choix.
Cela nécessite par contre de s'adapter et de penser autrement. Je conçois que cela puisse être difficile de redevenir apprenant dans un domaine où l'on pense être un cador mais rien n'est immuable dans la vie et quel que soit le métier.
Il va falloir que tu passe toutes les étape du deuil de ton statut de pro du réseau. Je constate que tu en est encore à l'étape dénis. N'attend pas trop pour passer aux suivantes car le monde avancera avec ou sans toi.
Le 04/01/2026 à 00h58
Même sans DNS, le copier-coller avec un bloc-notes sur le PC, ça fonctionne bien.
Le 03/01/2026 à 19h19
Le 03/01/2026 à 20h50
Après, les histoires d'abondance sont là pour essayer de faire briller les yeux mais masquent en fait tous les autres avantages. Je n'y prête pas attention.
L'attribution des blocs IPv6 est avant tout bien mieux gérée que celle des blocs IPv4. L'objectif est d'éviter la fragmentation énorme qui est devenue la norme avec IPv4. La taille des blocs est définie selon les besoins réels présents et futurs du requérant. Le bénéfice en terme de routage est énorme.
Avec la conjugaison de la diminution du coût de routage d'un paquet IPv6 vs IPv4 avec la diminution du temps de routage lié à la baisse de fragmentation des blocs, c'est un bénéfice en terme de puissance de calculs et en consommation énergétique.
Modifié le 04/01/2026 à 00h57
Du coup tout le monde oublie les raisons d'avoir fait comme ça, se dit simplement que c'est overkill tout ça, qu'il nous manquait juste 1 ou 2 octets pour supprimer la pénurie d'adresses, et fait sa sauce qu'il pense plus raisonnable mais qui ne respecte qu'à moitié la norme du coup. Ou ne fait rien du tout en se disant que c'est trop compliqué. Alors qu'au final ça ne l'est pas tant que ça quand on commence à vraiment s'y mettre. La marche paraît simplement trop haute, et on se sent forcé de passer d'une Twingo à une Ferrari alors qu'on pense n'avoir besoin de d'une Clio et ne pas être capable de conduire la Ferrari.
Le 04/01/2026 à 12h31
Par contre, trouver qu'un utilisateur à déjà trop avec un /64, c'est faux car il faut pouvoir séparer son réseau et il faut plusieurs préfixes pour cela. Le /60 de free convient déjà très bien même s'il s'agit en fait d'un /61 pour l'utilisateur car 1 préfixe est dédié à la box TV et 7 ne sont pas disponibles.
Je ne pense pas en revanche que les FAI se posent encore trop de questions car les bénéfices d'IPv6 sont assez nets pour eux.
Pour un admin réseau d'entreprise, le bénéfice devient évident dès lors que le réseau est étendu avec plusieurs sites et des routages entre sites. Quand on doit faire communiquer deux réseaux avec les mêmes plages IP, au hasard le 10.0.0/8 qui est le préféré des entreprises, il faut tout renuméroter.
La migration vers IPv6 dans les entreprises est donc plus facilement vendable dans les grosses structures comme EDF. Cela peut se chiffrer en terme d'économies de matériel, d'énergie et de résilience du réseau.
Le 05/01/2026 à 09h37
S'ils avaient été moins gourmands sur le nombre d'adresses possibles, et que la lecture en soit facilité, on serait déjà en IPv6...
Le 05/01/2026 à 10h16
En IPv6, le scan exhaustif des IP sur internet est impossible, contrairement en IPv4. C'est une sécurité supplémentaire (certes pas infaillible, mais assez efficace pour les machines non annoncées sur le réseau).
Exemple : tu fous une machine en DMZ derrière ta box FAI Orange/Free/SFR/Bouygues, il faut en moyenne moins de 20min pour qu'elle soit scannée en IPv4.
En IPv6, c'est juste impossible.
Le 05/01/2026 à 14h42
Le 05/01/2026 à 16h50
Le 05/01/2026 à 17h58
Le 03/01/2026 à 22h32
Le 04/01/2026 à 09h06
* 7 × 10¹⁶ réseaux, il faut en donner au moins un a chacun des 10 milliards d’humains
* 2⁷², soit 4×10²¹ adresses par personne en question.
À ton avis, lequel a le plus de chances d’être épuisé en premier ? C’est ce choix que je ne comprends pas. Un /96 était largement suffisant pour les particuliers, et même pour les entreprises (rappel : c’est ce qu’on a pour tout internet en ipv4). C’est ça qui donne l’impression d’un gros gâchis d’une ressource abondante mais pas infinie.
Le 04/01/2026 à 13h51
Je pense au contraire que le protocole a été conçu pour permettre le "gâchis" au profit d'une facilité à concevoir ses plans d'adressage.
Mon point de vue est qu'IPv6 est critiquable, mais sûrement pas sur ce point là. Par exemple, il y a le problème de la taille des tables de routage (réglable par une conception hiérarchique de l'adressage, donc pas insurmontable), et du fait que des adresses en 128 bits nécessitent 2 à 4 passages dans un processeur de routeur pour être traitées (problème qui peut se résoudre en ajoutant des ASIC dans les routeurs, mais ce n'est pas aussi trivial que pour le pb précédent).
Le 04/01/2026 à 14h34
Premièrement, les processeurs réseau ne doivent plus être en 32 bits depuis longtemps donc les opérations en 128 bits ne sont pas si coûteuses. Au début d'IPv4, il y avait pas mal de piles IP sur des architectures 16 bits et cela ne posait pas de problèmes.
Et avec une moindre fragmentation des plages d'IP, le nombre de règles de routage entre AS chez les transitaires est largement réduit.
Côté charge processeur, il ne faut pas oublier que la somme de contrôle n'est calculée que sur l'entête en IPv6 contre tout le paquet en IPv4. Le gain est assez net.
Si on ajoute le fait que la gestion de la fragmentation est à la fois complexe et coûteuse également en terme de charge CPU, la charge IPv6 est encore plus légère.
Au final, le bénéfice est assez net pour IPv6 sur le routage dans sa globalité.
Le 06/01/2026 à 11h19
Sinon, pour pinailler :-P :
Il n'y a pas si longtemps qu'il y avait encore des processeurs 32 bits dans les routeurs (et il y en a encore un peu mais sur des trucs entre le switch et le routeur, donc pas dit que le proc 32 bits soit celui qui traite les adresses).
2 cycles au lieu d'un, c'est +100%.; compensé par les autres traitements en moins, certes.
On était loin des besoins actuels et le réseau était très limité même pour les usages très légers qu'on avait.
Mais, même en prenant tout ça en compte, IPv6 reste le protocole d'avenir (j'ai jamais dit le contraire), parce que les problèmes que j'ai décrits sont résolus/résolubles. Je disais juste que ce sont deux potentiels problèmes (ça nécessite/a nécessité de faire qqch) soulevés par IPv6, alors que l'absence de NAT ou la difficulté à retenir des IPv6 sont pour le coup réellement des faux problèmes (surtout NAT, c'est vraiment un mécanisme à la zob et le sentiment de sécurité est bien ça : juste un sentiment).
Le 03/01/2026 à 23h24
De plus, comme dit précédemment, en IPv4 une architecture basée sur du NAT, VLAN et Reverse Proxy (en désactivant UPnP bien sûr) est beaucoup plus simple à mettre en place et comprendre qu'avoir une IPv6 par périphérique et essayer de voir qui a accès à quoi.
J'ai quelques services auto-hébergés, et bossant dans l'IT tous mes contacts me conseillent de rester en IPv4 uniquement.
Modifié le 04/01/2026 à 01h11
Le NAT et reverse proxy peuvent se remplacer par un pare-feu situé au même endroit et pouvant fonctionner de la même manière niveau sécurité, sauf qu'on a plus de choix, contrairement au NAT qui impose ses contraintes. On choisit des règles par défaut pour tous et des règles spécifiques par IP, on voit bien au même endroit qui a accès à quoi. Les VLAN c'est uniquement en interne et en dessous d'IP donc ça ne change pas.
Conseiller de rester en IPv4 pour héberger des trucs en étant dans l'IT c'est être un peu réfractaire quand-même. Je ne suis pas encore un pro de l'IPv6 mais pour autant je ne pourrais que conseiller de l'apprendre et l'utiliser à quelqu'un qui me poserait la question, rien que parce qu'en IPv4 on est de plus en plus coincés par nos fournisseurs accès.
Le 04/01/2026 à 02h29
Non. C'est juste une question d'habitude.
L'IPv6, c'est compliqué quand on ne sait pas. Mais c'est là même chose avec IPv4.
Pour rappel, IPv6 résout pas mal de soucis d'IPv4. La pénurie d'adresse bien sûr, mais aussi :
- limite grandement le scan réseau
- évite le redécoupage des paquets
- facilite le routage
Le 04/01/2026 à 10h39
On voit bien que l'IPv6 a des avantages indéniables, mais j'ai l'impression qu'on ne peut pas juste configurer les mêmes composants qu'en IPv4 pour avoir les mêmes fonctionnalités, du coup ça oblige à réapprendre le réseau juste pour ça. Et comme actuellement ça marche correctement avec mon FAI, la motivation n'est pas vraiment là.
Merci pour vos remarques, je m'y repencherai à l'occasion en espérant avoir plus facilement les infos que je recherche.
Le 04/01/2026 à 22h50
J'ai suivi les apprentissages tuto/videos des bases IPv4 pour construire mon réseau domestique (routeur perso, bornes wifi, nas DIY, plusieurs domotiques, VPN,...), mais, pour avoir commencé la compréhension de l'IPv6, la marche n'est pas simple.
C'est vrai que le changement demande de l'investissement et on est tellement bien avec un truc qui marche globalement.
Pourtant, avec tjs plus de domotique et un réseau entièrement géré un cran en dessous de ma box, je pense que j'y gagnerai en sécurité en ipv6, peut-être même en simplification dans certains cas, encore faut-il que tous mes équipements soient compatibles.
Le truc est qu'il faut y passer x heures pour, à moyen terme, pas de gain mesurable voire des galères nouvelles inexistantes avec ipv4 pour le moment.
J'ai lu plusieurs fois la mention de pare-feu au lieu de NAT. Je comprends le principe mais je n'ai intuitivement pas l'impression que configurer un pare-feu complet soit aussi simple que quelques règles NAT.
Tout ça pour dire qu'en tant que particulier, sur mon réseau local, je ne perçois pas le gain à prendre de temps d'apprendre ipv6 pour recommencer mon architecture et gérer les nouvelles problématiques apportées.
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?