IPv6 : éviter qu’un second réseau échappe aux contrôles
IPv6 ne consiste pas à ajouter des adresses. Son déploiement crée un second plan de contrôle pour le filtrage, le DNS, l’inventaire et les journaux. Dans une organisation régulée, cette parité doit être démontrée avant l’ouverture des flux.
Article rédigé automatiquement par une intelligence artificielle, à titre informatif. Il peut contenir des imprécisions et ne constitue pas un conseil juridique.
IPv6 est une technologie établie, souvent déjà présente avant toute décision formelle de déploiement. Les systèmes d’exploitation, équipements réseau et applications peuvent l’activer par défaut, générer des adresses locales au lien ou tenter une résolution DNS en IPv6. Le premier risque n’est donc pas une migration ratée, mais un réseau partiellement actif et mal observé. Désactiver IPv6 partout peut sembler plus simple. Cette décision devient toutefois fragile lorsque des services, des partenaires ou des composants internes commencent à en dépendre. L’enjeu consiste à choisir explicitement où IPv6 est autorisé, à lui appliquer les mêmes contrôles qu’à IPv4 et à produire les preuves correspondantes.
Deux protocoles, deux surfaces
Un déploiement en double pile ne remplace pas IPv4 : il ajoute IPv6. Chaque pare-feu, répartiteur de charge, sonde, résolveur DNS, mécanisme de découverte et chaîne de journalisation doit alors traiter les deux protocoles. Une règle correcte en IPv4 n’a pas nécessairement d’équivalent en IPv6. Une application publiée par un enregistrement DNS AAAA peut devenir accessible par un chemin différent de celui qui a été audité. Le fonctionnement d’IPv6 repose aussi sur ICMPv6 pour des mécanismes essentiels, notamment la découverte des voisins et la détermination du chemin. Bloquer ICMPv6 en bloc, par imitation d’une ancienne politique IPv4, provoque des pannes difficiles à diagnostiquer. Le bon contrôle est sélectif, documenté et testé.
Les contrôles à rendre équivalents
- Adressage et inventaire : définir les préfixes par zone, les règles d’attribution et les propriétaires. Le balayage exhaustif d’un sous-réseau IPv6 n’est pas une méthode d’inventaire crédible. La source de vérité doit venir de la gestion d’adresses, du DNS, de la configuration et de la télémétrie réseau.
- Filtrage : vérifier la parité des politiques entrantes, sortantes et interzones. Cette vérification doit porter sur les chemins réels, pas seulement sur la présence de règles. Les adresses locales au lien, le trafic multicast et les mécanismes de découverte nécessitent un traitement explicite.
- Attribution : choisir entre configuration statique, SLAAC et DHCPv6 selon les usages. Les annonces de routeur doivent être protégées contre les équipements non autorisés. L’identité d’un poste ne doit pas reposer uniquement sur son adresse, car certaines adresses clientes peuvent changer régulièrement.
- DNS et exposition : maîtriser la création des enregistrements AAAA et tester séparément les réponses en IPv4 et IPv6. Publier une adresse IPv6 avant que le filtrage, la supervision et la réponse aux incidents soient prêts revient à ouvrir un chemin non gouverné.
- Journaux et détection : confirmer que les pare-feu, applications, mandataires et outils d’analyse acceptent, normalisent et corrèlent les adresses IPv6. Plusieurs représentations textuelles peuvent désigner la même adresse ; sans normalisation, les recherches et règles de détection deviennent incomplètes.
- Exploitation : intégrer IPv6 aux procédures de diagnostic, aux captures réseau, aux tests de disponibilité et aux scénarios d’incident. Une équipe qui ne teste qu’en IPv4 peut déclarer un service disponible alors qu’une partie des clients suit un chemin IPv6 défaillant.
Adopter par zones, pas par décret
L’adoption est pertinente lorsque l’organisation doit exposer des services à des clients IPv6, interconnecter des environnements qui l’utilisent déjà, réduire sa dépendance à la traduction d’adresses ou préparer une croissance que l’adressage privé IPv4 complique. Elle ne justifie pas une activation générale et simultanée. Une trajectoire contrôlable commence par l’inventaire de l’IPv6 déjà actif, puis par une zone pilote dont les dépendances sont connues. Les critères de passage doivent inclure le filtrage, la résolution DNS, la collecte des journaux, la supervision, la sauvegarde des configurations et le retour arrière. Le double empilement apporte de la compatibilité, mais prolonge aussi la coexistence de deux politiques. À plus long terme, certaines zones peuvent devenir uniquement IPv6, avec des mécanismes de traduction tels que NAT64 et DNS64 pour les dépendances restantes. Ce choix réduit un plan de contrôle local, mais ajoute une traduction à exploiter et à tracer. Il doit donc être décidé service par service.
La conformité ne se déduit pas du fait qu’un équipement « prend en charge IPv6 ». Elle repose sur des preuves d’exploitation : matrice de flux couvrant les deux protocoles, tests de segmentation, journaux exploitables, responsabilités d’adressage et procédure de retour arrière. Avant tout projet, il faut aussi rechercher l’IPv6 implicite : interfaces locales, réseaux d’administration, tunnels, conteneurs et services publiés dans le DNS. Ce qui n’a pas été déployé officiellement peut néanmoins être actif.
IPv6 is an established technology and is often present before any formal deployment decision has been made. Operating systems, network devices and applications may enable it by default, generate link-local addresses or attempt DNS resolution over IPv6. The first risk is therefore not a failed migration, but a partially active and poorly observed network. Disabling IPv6 everywhere may appear simpler. However, that decision becomes difficult to sustain when services, partners or internal components begin to depend on it. The objective is to decide explicitly where IPv6 is permitted, apply the same controls as for IPv4 and retain the corresponding evidence.
Two protocols, two surfaces
A dual-stack deployment does not replace IPv4: it adds IPv6. Every firewall, load balancer, sensor, DNS resolver, discovery mechanism and logging pipeline must then handle both protocols. A correct IPv4 rule does not necessarily have an IPv6 equivalent. An application published through an AAAA DNS record may become reachable through a different path from the one that was audited. IPv6 also relies on ICMPv6 for essential functions, including neighbour discovery and path determination. Blocking ICMPv6 wholesale, by copying an old IPv4 policy, causes failures that are difficult to diagnose. The appropriate control is selective, documented and tested.
Controls that require parity
- Addressing and inventory: define prefixes by zone, allocation rules and ownership. Exhaustively scanning an IPv6 subnet is not a credible inventory method. The source of truth must come from address management, DNS, configuration and network telemetry.
- Filtering: verify parity across inbound, outbound and inter-zone policies. This verification must cover actual paths, not merely the presence of rules. Link-local addresses, multicast traffic and discovery mechanisms require explicit handling.
- Assignment: choose between static configuration, SLAAC and DHCPv6 according to the use case. Router advertisements must be protected against unauthorised devices. A workstation’s identity should not rely solely on its address, as some client addresses may change regularly.
- DNS and exposure: control the creation of AAAA records and test IPv4 and IPv6 responses separately. Publishing an IPv6 address before filtering, monitoring and incident response are ready amounts to opening an ungoverned path.
- Logging and detection: confirm that firewalls, applications, proxies and analysis tools accept, normalise and correlate IPv6 addresses. Several textual forms can represent the same address; without normalisation, searches and detection rules become incomplete.
- Operations: incorporate IPv6 into diagnostic procedures, packet captures, availability tests and incident scenarios. A team that tests only over IPv4 may declare a service available while some clients are taking a failing IPv6 path.
Adopt by zone, not by decree
Adoption is justified when the organisation must expose services to IPv6 clients, interconnect environments that already use it, reduce reliance on address translation or prepare for growth made difficult by private IPv4 addressing. It does not justify enabling IPv6 everywhere at once. A controllable path starts with an inventory of IPv6 that is already active, followed by a pilot zone with known dependencies. Exit criteria should cover filtering, DNS resolution, log collection, monitoring, configuration backups and rollback. Dual stack provides compatibility, but it also extends the coexistence of two policies. Over time, some zones may become IPv6-only, using translation mechanisms such as NAT64 and DNS64 for remaining dependencies. This removes one local control plane, but introduces translation that must be operated and traced. The decision should therefore be made service by service.
Compliance cannot be inferred from a device claiming to “support IPv6”. It depends on operational evidence: a traffic matrix covering both protocols, segmentation tests, usable logs, clear addressing responsibilities and a rollback procedure. Any project should also begin by looking for implicit IPv6: local interfaces, management networks, tunnels, containers and services published in DNS. Technology that was never formally deployed may still be active.