Migration vers IPv6 : conduire le projet sans coupure

La Migration IPv6 ne consiste pas à remplacer tous les équipements en une nuit. Pour éviter une coupure, il faut maintenir les services IPv4 pendant que le réseau apprend à acheminer et sécuriser le nouveau protocole.

Le défi tient souvent moins aux adresses qu’aux dépendances oubliées : DNS, pare-feu, supervision, applications et engagements clients. Une Planification réseau progressive permet de les repérer avant les changements en production et de protéger la Continuité de service.

A retenir :

• Double pile IPv4/IPv6 pour préserver les accès existants
• Cartographie des dépendances avant toute modification en production
• Tests de compatibilité menés sur des services représentatifs
• Plan de retour arrière validé avant chaque bascule

Migration IPv6 sans coupure : préparer le réseau et les dépendances

Cette préparation transforme l’objectif de continuité en décisions concrètes, prises avant l’activation des nouvelles routes. Selon LARUS, le cadrage doit partir des services, des clients et des responsabilités opérationnelles déjà en place.

Cartographier les services avant la Migration IPv6

La première étape consiste à distinguer les services exclusivement IPv4, ceux qui acceptent déjà les deux protocoles et les éléments encore inconnus. Une plateforme de commerce peut, par exemple, disposer d’un frontal compatible IPv6, tandis qu’un outil de paiement ou un système de suivi reste dépendant d’IPv4.

Cette carte doit inclure les chemins réseau, le DNS, les règles de filtrage, les intégrations externes et les équipes chargées du support. Selon LARUS, identifier ces dépendances tôt réduit les surprises susceptibles de retarder un changement ou d’affecter les clients.

Les vérifications prioritaires avant le déploiement :

• Services publics, interfaces et intégrations dépendantes d’IPv4
• Enregistrements DNS, filtrage et équilibrage de charge
• Équipes responsables des validations et interventions d’urgence
• Parcours clients nécessitant une disponibilité permanente

Choisir une architecture Double pile IPv4/IPv6

Une fois les dépendances recensées, la Double pile IPv4/IPv6 permet de faire fonctionner les deux protocoles sur les mêmes équipements. Les clients se connectent selon leur capacité, tandis que les services existants conservent leur chemin IPv4.

Le préfixe IPv6 doit être obtenu auprès de l’opérateur ou du registre régional compétent, puis dimensionné selon l’organisation du réseau. Les sessions de routage IPv6, les enregistrements AAAA et les règles de sécurité doivent être préparés ensemble, plutôt qu’activés séparément sans coordination.

Planification réseau et bascule progressive en production

Avec une architecture définie, l’enjeu devient l’ordre des changements et la maîtrise de leurs effets. Une Bascule progressive limite le périmètre de chaque intervention et laisse aux équipes le temps d’observer les résultats.

Tester la compatibilité avant d’élargir l’accès

Les Tests de compatibilité doivent couvrir les parcours réellement utilisés : résolution DNS, établissement des connexions, authentification et échanges avec les services tiers. Un test réussi depuis un poste interne ne suffit pas si les clients mobiles ou les partenaires suivent d’autres chemins.

Selon le guide de planification de LARUS, les décisions doivent s’appuyer sur des preuves de préparation et des points de revue. Pour chaque service, l’équipe peut consigner le résultat attendu, le responsable de validation et la condition qui autorise l’étape suivante.

Les contrôles utiles à chaque étape :

• Résolution IPv6 des noms publics et cohérence des enregistrements
• Accessibilité des applications depuis plusieurs réseaux clients
• Respect des règles de filtrage et des exigences de sécurité
• Validation des procédures d’alerte et d’intervention

Associer Haute disponibilité et Redondance réseau

La Haute disponibilité dépend d’un fonctionnement cohérent des deux protocoles, pas seulement de serveurs redondants. Les chemins de secours, répartiteurs de charge et mécanismes de filtrage doivent aussi traiter IPv6 de façon attendue.

Le tableau ci-dessous relie chaque changement à une vérification pratique, sans imposer un calendrier identique à tous les environnements. Les jalons peuvent être adaptés au niveau de risque et aux contraintes de service.

Étape	Vérification	Condition de poursuite
Préparation	Préfixe, routage et responsabilités définis	Équipe et périmètre validés
Activation réseau	Connectivité IPv6 et routes observables	Chemins attendus disponibles
Publication des services	DNS, filtrage et accès applicatifs testés	Parcours représentatifs fonctionnels
Élargissement	Incidents et retours clients surveillés	Critères de service respectés

Supervision du trafic et retour arrière maîtrisé

Après les premiers tests, la Supervision du trafic permet de comparer les connexions IPv4 et IPv6 et de détecter rapidement les écarts. Cette observation prépare le dernier volet du projet : intervenir sans improviser si un service se dégrade.

Mesurer les résultats de la bascule IPv6

Les équipes suivent les erreurs de connexion, les délais de réponse, les alertes de sécurité et la répartition du trafic par protocole. Selon LARUS, les rôles de décision, de mise en œuvre, d’observation et de support gagnent à être attribués explicitement.

Une hausse des échecs IPv6 sur une application précise peut révéler un filtrage incomplet ou une dépendance tierce non recensée. Il faut alors isoler le service concerné, comparer les parcours et corriger la cause avant d’élargir le déploiement.

Les indicateurs à suivre pendant le déploiement :

• Disponibilité des services selon le protocole utilisé
• Erreurs, délais et incidents rapportés par les utilisateurs
• Évolution du trafic IPv6 sur les services publiés
• Alertes de sécurité et interventions des équipes réseau

Documenter le Plan de retour arrière

Un Plan de retour arrière précise qui peut interrompre une étape, quels paramètres rétablir et comment confirmer le retour au fonctionnement attendu. Il doit être testé avec les équipes concernées, car une procédure inconnue est difficile à appliquer sous pression.

La décision de revenir en arrière peut viser un service sans désactiver IPv6 partout. Cette approche conserve les parties stables et limite l’impact d’un incident à son périmètre, tout en fournissant des éléments utiles pour reprendre les essais.

Situation observée	Action opérationnelle	Point de contrôle
Échecs concentrés sur un service	Retrait temporaire de son accès IPv6	Accès IPv4 rétabli et testé
Règle de filtrage incorrecte	Restauration de la règle précédente	Flux autorisés et bloqués vérifiés
Route IPv6 instable	Retour à la configuration de routage validée	Chemins et alertes contrôlés
Incident client généralisé	Suspension du jalon et escalade prévue	Responsable et communication confirmés

Source : LARUS, « Planification de la transition IPv6 », LARUS.