IPv6 : activer sans panne sur un réseau existant

On va se le dire. IPv6, on en parle depuis longtemps. Trop longtemps. Et pourtant, dans pas mal de réseaux réels, surtout en établissement scolaire ou PME, le sujet est encore traité comme un projet « plus tard ». Sauf que « plus tard », ça finit par devenir un lundi matin à 8h quand un service cloud impose IPv6, quand un opérateur commence à pousser du CGNAT, ou quand vous mettez en place des labos modernes (containers, Kubernetes, VPN récents, services Microsoft ou Google) qui, eux, ont déjà un pied dedans.

Le problème n’est pas IPv6 en lui même. Le problème, c’est la peur de la panne. La crainte de toucher à un réseau existant, qui tourne, qui rend service, et de tout casser avec un truc « nouveau ».

Bonne nouvelle : on peut activer IPv6 sans coupure. Sans migration brutale. Sans « big bang ». En douceur. En dual stack, en contrôlant, en observant, en revenant en arrière si besoin.

Dans ce billet, je te propose une méthode très pragmatique, celle qu’on peut appliquer sur un réseau existant, en mode BTS SIO option SISR, mais totalement valable en prod. Et si tu veux d’autres labs du même genre, tu peux passer sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) : l’idée du site, c’est justement d’avoir des procédures propres, testées, reproductibles.

Pourquoi activer IPv6 maintenant (sans dramatiser)

Quelques raisons concrètes, pas le discours « l’avenir d’internet ».

• Les OS préfèrent IPv6 quand il est disponible (Happy Eyeballs). Donc dès que tu l’actives, tu changes une partie du trafic. Il vaut mieux le faire volontairement, pas par accident.
• Plus besoin de NAT en interne (même si on garde souvent des firewalls stricts). Dépannage plus simple quand c’est bien fait.
• Les environnements modernes l’utilisent déjà : mobiles, certains FAI, cloud, VPN, outils de sécu, IoT.
• La sécurité : IPv6 n’est pas « plus sécurisé » par magie, mais il force à revoir des choses (filtrage, logs, visibilité). Et ça, c’est sain.

L’objectif du billet : te faire activer IPv6 sur un réseau IPv4 existant, sans panne, et en gardant la maîtrise.

Les erreurs classiques qui provoquent des pannes

On va les sortir tout de suite, ça évite des sueurs froides.

1. Activer IPv6 partout sans filtrage : sur un firewall, sur un routeur, sur des VLAN, et oublier que les postes vont tenter IPv6.
2. Laisser les RA (router advertisements) partir n’importe où : et là, un VLAN reçoit une passerelle IPv6 non prévue.
3. Oublier DNS : AAAA publiés, mais pas de reverse, pas de résolution correcte, ou DNS qui répond mal. Résultat : lenteurs, applis qui « moulinent ».
4. Se baser uniquement sur le ping : ping OK, mais HTTP, SMB, AD, impression, tout peut échouer autrement.
5. Ne pas prévoir de rollback : alors qu’en dual stack, on peut désactiver IPv6 proprement sur une interface si besoin.

Bref. L’approche safe, c’est : activer progressivement, observer, et contrôler qui annonce quoi.

Prérequis : ce qu’il faut vérifier avant de toucher

1) Inventaire rapide

• Routeur ou firewall en bordure : support IPv6, version firmware, possibilités de filtrage IPv6.
• Switch L3 ou routeurs internes : gestion des VLAN, RA, DHCPv6 relay si besoin.
• Serveurs clés : AD DS, DNS, DHCP, supervision, SIEM, NAS, imprimantes.
• Postes : Windows, Linux, macOS, mobiles.

2) Choix du plan d’adressage IPv6

Si tu as un préfixe fourni par un FAI (souvent /56 ou /48), utilise le. Sinon, en labo, tu peux prendre un ULA (Unique Local Address) en fd00::/8.

En pratique :

• Un /64 par VLAN. C’est la règle de base, et elle simplifie la vie.
• Nommage logique : par exemple, VLAN 10 = 2001:db8:10::/64 (exemple doc), VLAN 20 = ...:20::/64, etc.

Petit conseil : évite les trucs trop « jolis » qui finissent illisibles. Un plan simple gagne.

3) Décider comment les clients reçoivent leur IPv6

Tu as trois grands modes, souvent mélangés :

• SLAAC (RA) : les clients génèrent leur adresse, simple, efficace.
• DHCPv6 : utile pour donner des options (DNS), et parfois pour de la traçabilité. Attention, DHCPv6 ne donne pas la passerelle, c’est le RA qui le fait.
• Statique : pour serveurs, équipements réseau.

Dans beaucoup de réseaux pédagogiques ou PME : SLAAC + DNS via RA (RDNSS) ou via DHCPv6. Sur Windows, DHCPv6 est parfois plus simple pour pousser DNS de manière uniforme, mais ça dépend de l’infra.

Stratégie recommandée : dual stack d’abord, IPv6 only plus tard (peut être jamais)

Le dual stack, c’est avoir IPv4 et IPv6 en parallèle. C’est ce qui permet d’activer IPv6 sans couper IPv4.

Le principe :

• Tu gardes IPv4 tel quel.
• Tu ajoutes IPv6 sur les interfaces L3.
• Tu annonces IPv6 aux clients progressivement.
• Tu filtres IPv6 correctement.
• Tu observes quel trafic passe en IPv6.

Et si ça coince : tu désactives l’annonce IPv6 sur un VLAN, sans toucher à IPv4. Retour à la normale.

Étape 1 : préparer le DNS (sinon, tu vas croire qu’IPv6 « casse tout »)

Côté interne

Si tu as un DNS interne (AD DNS ou BIND) :

• Assure toi que le serveur DNS écoute en IPv6.
• Crée les enregistrements AAAA pour les serveurs qui doivent être joignables en IPv6.
• Mets en place le reverse IPv6 si possible (zones ip6.arpa). Ce n’est pas obligatoire pour démarrer, mais utile.

Point important : au début, n’ajoute pas de AAAA pour tout et n’importe quoi. Commence par une petite liste, contrôlée.

Côté clients

Décide comment ils recevront les DNS :

• DHCPv6, ou
• RA avec option RDNSS (selon équipements), ou
• DNS IPv4 conservé, mais accessible aussi via IPv6.

Dans une phase de transition, tu peux laisser les clients utiliser DNS IPv4 tout en ayant IPv6 pour le trafic. Ce n’est pas « pur », mais ça marche et ça évite des surprises.

Étape 2 : activer IPv6 sur le cœur réseau (mais sans l’annoncer aux clients tout de suite)

C’est un truc que j’aime bien : on active IPv6 sur les liens d’infrastructure, puis seulement ensuite sur les VLAN utilisateurs.

Exemple de séquence

1. Activer IPv6 sur le lien entre firewall et switch L3.
2. Activer IPv6 sur les SVIs des VLAN serveurs.
3. Tester depuis un serveur, pas depuis les postes.
4. Ajouter les règles de firewall IPv6.
5. Ensuite seulement, ouvrir les RA sur un VLAN pilote.

L’idée : éviter que 200 postes se mettent à tenter IPv6 pendant que tu configures encore les ACL.

Étape 3 : firewalling IPv6, la base (et oui, ça pique un peu)

En IPv4, on a souvent une posture « NAT = barrière ». En IPv6, si tu fais n’importe quoi, tu peux exposer des machines. Donc on filtre.

Politique simple de départ

• Entrant WAN vers LAN : bloqué par défaut, sauf services publiés explicitement.
• Sortant LAN vers WAN : autorisé selon la politique habituelle (web, DNS, NTP…), comme en IPv4.
• ICMPv6 : ne pas tout bloquer. ICMPv6 est vital (PMTUD, neighbor discovery). Bloquer ICMPv6 au hasard, c’est s’acheter des pannes bizarres.

À autoriser a minima en interne :

• Neighbor solicitation / advertisement
• Router solicitation / advertisement (là où c’est voulu)
• Packet too big
• Time exceeded
• Echo request/reply (selon politique)

Chaque firewall a ses menus, ses objets. Mais l’idée reste la même.

Étape 4 : choisir un VLAN pilote (pas le plus critique)

Choisis un VLAN :

• avec peu d’utilisateurs,
• avec des machines que tu peux toucher,
• idéalement ton VLAN IT, ou une salle de TP dédiée.

Active IPv6 sur ce VLAN seulement. Et observe.

Points à valider sur un poste pilote

Sur Windows :

• ipconfig /all
• ping -6 ipv6.google.com
• tracert -6 ipv6.google.com
• nslookup -type=AAAA bts-sio2.example (remplace par ton domaine)

Sur Linux :

• ip -6 a
• ip -6 r
• ping -6
• dig AAAA

Sur le poste, tu veux voir :

• une adresse IPv6 globale ou ULA selon ton choix,
• une default route IPv6,
• un DNS qui répond,
• et surtout, de la navigation web fluide.

Si tu as des lenteurs, souvent c’est DNS, ou un filtrage ICMPv6 trop strict, ou des routes manquantes.

Étape 5 : sécuriser les RA, sinon un stagiaire peut devenir routeur

Les RA, c’est ce qui annonce la passerelle IPv6 aux clients. Et un poste peut en émettre s’il est mal configuré ou si tu as un outil de partage de connexion.

Deux protections utiles :

• RA Guard sur les ports switch côté clients.
• DHCPv6 Guard si tu utilises DHCPv6 et que tu veux éviter les serveurs rogue.

Sur certains switches, c’est par VLAN, sur d’autres c’est par port. À défaut, au minimum : ne laisse pas n’importe quel port trunker des VLAN.

C’est typiquement le genre de sujet qu’on traite en lab sur BTS SIO2 SISR Tech Lab, parce que c’est concret : tu peux casser un VLAN juste avec un mauvais RA.

Étape 6 : supervision et logs, sinon tu voles à l’aveugle

Quand IPv6 arrive, il faut de la visibilité.

À mettre en place ou vérifier :

• Supervision : SNMP sur interfaces IPv6, état des routes, latence vers cibles IPv6.
• Syslog : logs firewall IPv6, drops IPv6.
• NetFlow / IPFIX si disponible : top talkers en IPv6.
• Serveurs : logs applicatifs qui montrent l’IP source, et qu’ils acceptent IPv6.

Petit détail qui compte : dans les règles, dans les logs, l’adresse IPv6 est longue. Donc pense à l’outillage. Un SIEM ou un syslog qui tronque, c’est vite pénible.

Étape 7 : étendre VLAN par VLAN, avec une checklist simple

Quand le VLAN pilote est stable, tu peux étendre.

Checklist par VLAN :

1. Préfixe /64 défini et documenté.
2. SVI ou interface L3 configurée.
3. RA activé uniquement sur le VLAN concerné.
4. DHCPv6 (si utilisé) : scope prêt, options DNS OK.
5. Firewall : règles LAN vers WAN IPv6 en place, inter VLAN contrôlé.
6. Tests : ping, DNS, web, applis métier.
7. Monitoring : drops, latence, incidents.

Oui, c’est répétitif. Mais c’est ça qui évite les pannes.

Cas particuliers qui font souvent trébucher

Active Directory

AD fonctionne très bien en IPv6, et Windows utilise IPv6 en interne. Le piège, c’est plutôt :

• DNS mal configuré,
• enregistrements AAAA incohérents,
• pare feu Windows qui bloque certains flux IPv6.

Commence par les DC et DNS. Vérifie que les clients résolvent les bons enregistrements.

Imprimantes et IoT

Beaucoup d’équipements ont IPv6 « sur le papier ». En vrai :

• certains activent IPv6 mais n’aiment pas SLAAC,
• certains changent d’adresse si privacy extensions,
• certaines interfaces web sont accessibles en IPv6 sans auth solide.

Recommandation : IPv6 statique ou DHCPv6 avec réservation, et firewall strict. Et ne publie pas ça hors LAN.

VPN

Certains VPN transportent IPv4 uniquement, d’autres supportent IPv6, certains créent des fuites si mal configurés.

Si tu as un VPN site à site ou remote access :

• vérifie si le tunnel transporte IPv6,
• sinon, prévois que le trafic IPv6 sorte directement sur internet, ce qui peut être un problème de politique.

Applications qui codent des IP en dur

Oui, ça existe encore. Ou des applis qui n’aiment pas les adresses littérales IPv6.

Dans ce cas : dual stack te sauve, tu gardes IPv4 pour l’appli, IPv6 pour le reste.

Plan de rollback : la vraie assurance anti panne

Tu veux une marche arrière simple, écrite, testée.

Rollback minimal par VLAN :

• Désactiver l’émission de RA sur le VLAN.
• Si nécessaire, retirer l’adresse IPv6 de l’interface SVI.
• Vérifier que les clients reprennent IPv4 uniquement (ils vont garder l’IPv6 un moment, mais sans route par défaut, ça retombe).

Rollback au niveau bordure :

• Désactiver la route par défaut IPv6 vers le FAI.
• Bloquer temporairement l’IPv6 sortant au firewall.

Important : documente ces commandes ou actions GUI avant de déployer. Pas pendant l’incident.

Un exemple de déroulé réaliste en 2 semaines (sans stress)

• Jour 1 : inventaire, choix du préfixe, doc.
• Jour 2 : DNS prêt, firewall IPv6 prêt (règles de base).
• Jour 3 : activer IPv6 sur liens d’infra, pas de RA clients.
• Jour 4 : VLAN pilote, 2 ou 3 postes test.
• Jour 5 : corrections (souvent ICMPv6, DNS, RA Guard).
• Semaine 2 : déploiement progressif sur VLAN non critiques, puis VLAN utilisateurs.

Tu peux faire plus vite. Mais honnêtement, prendre le temps, c’est ce qui évite les « incidents pédagogiques ».

Mini boîte à outils de tests (à garder sous la main)

• Tester la connectivité : ping -6, traceroute -6, Test-NetConnection -ComputerName ... -Port ...
• Tester DNS : nslookup, dig AAAA, Resolve-DnsName
• Voir les routes : ip -6 route, route print -6
• Vérifier l’adresse : ipconfig /all, ip -6 a

Et côté équipements : surveiller la table ND (neighbor discovery), les RA, les routes, et les drops firewall.

Conclusion : IPv6 sans panne, c’est surtout une question de méthode

Activer IPv6 sur un réseau existant, ce n’est pas une bascule. C’est une série de petites activations contrôlées. Dual stack, VLAN pilote, RA maîtrisés, DNS propre, firewall IPv6 pensé dès le début, supervision. Et un rollback prêt.

Si tu es en train de monter des labs, de préparer des compétences SISR, ou juste de fiabiliser ton réseau, c’est typiquement le genre de chantier qui te fait passer un cap. Et si tu veux d’autres tutos et retours terrain du même style, tu peux aller faire un tour sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) : il y a de quoi construire un vrai parcours, pas juste un article isolé.

Prochaine étape logique après ce billet, si tu veux pousser : segmenter proprement, filtrer inter VLAN en IPv6, et tester un service interne en IPv6 only. Mais une chose à la fois.

Questions fréquemment posées

Pourquoi devrais-je activer IPv6 maintenant et pas plus tard ?

Activer IPv6 dès maintenant permet d'éviter les surprises lorsque des services cloud, opérateurs ou environnements modernes (containers, Kubernetes, VPN récents) l'exigent. Les systèmes d'exploitation privilégient IPv6 quand il est disponible, donc mieux vaut le gérer volontairement. Cela facilite également la suppression du NAT interne et prépare votre réseau aux technologies actuelles et futures.

Comment activer IPv6 sans provoquer de pannes sur un réseau existant ?

La clé est d'activer IPv6 en douceur, en mode dual stack, c'est-à-dire en conservant IPv4 actif. Il faut procéder progressivement, contrôler les annonces des routeurs (RA), filtrer le trafic IPv6 sur les firewalls et VLAN, observer le comportement des clients et prévoir un rollback possible pour désactiver proprement IPv6 si besoin.

Quelles sont les erreurs classiques à éviter lors de l'activation d'IPv6 ?

Les erreurs fréquentes incluent : activer IPv6 partout sans filtrage adapté, laisser partir des Router Advertisements non contrôlés sur tous les VLANs, oublier la configuration complète du DNS (notamment les enregistrements AAAA et la résolution inverse), se baser uniquement sur le ping pour tester la connectivité, et ne pas prévoir de plan de retour arrière.

Quels sont les prérequis avant de déployer IPv6 sur un réseau ?

Il faut réaliser un inventaire rapide des équipements clés (routeurs/firewalls en bordure avec support IPv6 et filtrage, switches L3, serveurs AD DS, DNS, DHCP), vérifier la compatibilité des postes clients (Windows, Linux, macOS), choisir un plan d'adressage IPv6 clair (souvent un /64 par VLAN), et décider comment les clients recevront leur adresse (SLAAC, DHCPv6).

Comment choisir un plan d'adressage IPv6 adapté ?

Si vous disposez d'un préfixe fourni par votre FAI (souvent /56 ou /48), utilisez-le. Sinon pour un laboratoire vous pouvez utiliser une plage ULA (fd00::/8). La règle générale est d'attribuer un /64 par VLAN pour simplifier la gestion. Utilisez une nomenclature logique et simple pour faciliter la compréhension et la maintenance.

Quels sont les avantages sécuritaires liés à l'activation d'IPv6 ?

IPv6 n'est pas intrinsèquement plus sécurisé qu'IPv4 mais son activation oblige à revoir les règles de filtrage, la gestion des logs et la visibilité du trafic. Cette révision est bénéfique car elle améliore globalement la sécurité du réseau en adaptant les protections aux nouveaux protocoles utilisés.