IPv6 dans le réseau d'entreprise : planifier la coexistence avec l'IPv4

Réseaux · 4 min

Articles de Tomás Romão

De nombreux réseaux transportent déjà l'IPv6 sans que personne ne l'ait planifié. Découvrez comment évaluer, sécuriser et introduire le protocole de manière progressive, sans compromettre l'exploitation.

IPv6 dans le réseau d'entreprise : planifier la coexistence avec l'IPv4

TL;DR

L'IPv6 circule déjà dans des réseaux qui ne l'ont pas planifié

Pendant des années, l'IPv6 a été traité comme un projet à reporter, à lancer lorsqu'un besoin concret se présenterait. Entre-temps, l'espace d'adressage IPv4 s'est épuisé, les opérateurs et les fournisseurs de cloud ont étendu le support du nouveau protocole, et les systèmes d'exploitation les plus courants ont commencé à l'activer par défaut. Pour un responsable IT, la question centrale se déplace : il ne s'agit plus seulement de décider si l'organisation va adopter l'IPv6, mais de comprendre si l'IPv6 déjà présent sur le réseau est sous contrôle. Comme l'IPv6 n'est pas rétrocompatible avec l'IPv4, son introduction oblige à revoir l'infrastructure, les systèmes et les processus, comme le souligne le guide du NIST sur le déploiement sécurisé de ce protocole.

Un réseau géré en IPv4 peut avoir du trafic IPv6 invisible

Lorsqu'un équipement a l'IPv6 activé, il peut obtenir des adresses automatiquement et communiquer avec d'autres appareils du même segment, même si l'équipe réseau n'a jamais configuré le protocole. Si les pare-feux, les systèmes de détection et les outils de supervision n'inspectent que l'IPv4, ce trafic peut circuler sans politique ni journalisation. Il existe également des risques spécifiques, comme des annonces de routeur illégitimes (rogue router advertisements) capables de détourner du trafic au sein du réseau local, ou des mécanismes de tunneling qui traversent le périmètre sans être reconnus. Désactiver l'IPv6 sur tous les équipements semble la réponse la plus simple, mais peut provoquer des comportements inattendus sur des systèmes et applications qui l'utilisent en interne, d'où la nécessité d'une évaluation au cas par cas.

Le point de départ est l'inventaire et le plan d'adressage

Avant toute décision technique, il convient de savoir où l'IPv6 est déjà activé, quels équipements le supportent pleinement et quelles applications dépendent d'adresses IPv4 fixes dans le code ou la configuration. Vient ensuite le plan d'adressage. L'IPv6 élimine la pénurie qui a conduit à l'usage intensif du NAT, mais exige une structure hiérarchique pensée par localisation, fonction et niveau de confiance. Reproduire la logique des sous-réseaux IPv4 est une erreur fréquente, qui complique l'agrégation des routes et la rédaction des règles de filtrage. Dans les cycles de renouvellement des réseaux LAN et WAN, le support effectif de l'IPv6, incluant les fonctionnalités de sécurité et de gestion, doit figurer parmi les critères d'acceptation des équipements.

Dual-stack ou traduction : choisir le modèle de coexistence

Dans la plupart des organisations, la coexistence avec l'IPv4 s'étend sur plusieurs années. Le modèle dual-stack, dans lequel chaque équipement fait fonctionner les deux protocoles simultanément, est souvent le plus simple à introduire, mais il double les politiques, la supervision et le diagnostic. Les approches centrées sur l'IPv6, avec des mécanismes de traduction comme NAT64 et DNS64 pour atteindre des services qui n'existent qu'en IPv4, réduisent cette duplication, mais exigent des tests minutieux avec les applications héritées. Dans ces scénarios, le DNS gagne encore plus d'importance, car des enregistrements AAAA incorrects ou des synthèses mal configurées peuvent dégrader les services, ce qui renforce l'importance d'un DNS résilient. Le choix peut varier par segment : le réseau invité ou les postes de travail peuvent avancer en premier, tandis que les systèmes industriels ou hérités restent en IPv4.

La sécurité doit être équivalente dans les deux protocoles

C'est une bonne pratique de garantir que chaque règle appliquée en IPv4 a une correspondance explicite en IPv6, des listes de contrôle d'accès au filtrage périmétrique, en passant par la segmentation et la journalisation des événements. L'absence de NAT n'implique pas l'absence de protection, à condition que le pare-feu applique une politique de refus par défaut au trafic entrant. Sur les segments d'accès, des fonctionnalités des commutateurs comme RA Guard et DHCPv6 Guard peuvent aider à réduire les attaques sur le réseau local. Les services publiés en IPv6 doivent également entrer dans l'analyse de la surface d'attaque externe, car des adresses exposées uniquement dans ce protocole échappent parfois aux vérifications habituelles. Les équipes d'exploitation ont enfin besoin de formation et d'outils traitant les deux protocoles avec le même niveau de détail.

Une adoption progressive, adaptée au contexte

L'IPv6 n'a pas besoin d'être un projet de remplacement total, mais l'ignorer tend à créer une partie du réseau sans gestion. Une démarche raisonnable commence par rendre visible ce qui existe déjà, établir un plan d'adressage et aligner les règles de sécurité, pour ensuite étendre le protocole par segments. Le rythme et le modèle de coexistence dépendent du support des opérateurs et fournisseurs, de l'importance des applications héritées, des compétences disponibles et du risque que chaque organisation est prête à accepter, d'où la nécessité d'une évaluation au cas par cas.

Connexe

Références

  1. NIST SP 800-119 — Guidelines for the Secure Deployment of IPv6 (cópia não oficial no Academia.edu; o limite de pesquisa foi atingido antes de se obter o URL do NIST, que deve substituir este na revisão)