Résumé

  • Une renumérotation IPv6 suit une logique « établir avant de couper » : ancien et nouveau préfixes doivent coexister pendant que routes, filtres, adresses, DNS et dépendances applicatives avancent à des rythmes différents.
  • Inférence opérationnelle : les durées préférée et valide, celles des préfixes délégués et de la configuration DNS, les caches positifs et négatifs, le choix d'adresse source et les sessions longues forment une même frontière de changement. Le retrait ne devrait être autorisé qu'après convergence démontrée de la dépendance déclarée la plus lente.
  • Le retour arrière n'est pas une transaction atomique fournie par le protocole. Il doit être exercé avant que l'ancien préfixe, sa zone inverse ou son chemin ne sortent du contrôle de l'opérateur.

Une bascule déjà divisée

Dans une succursale, le nouvel agrégat est visible en amont et la zone faisant autorité publie la nouvelle adresse AAAA. Une sonde atteint le service. Pourtant, le routeur du site conserve l'ancien préfixe délégué, un résolveur récursif sert encore l'ancienne réponse et une session de base de données reste attachée à l'ancienne adresse. Les nouveaux flux évitent cette source dès qu'elle devient déconseillée ; la session existante, elle, ne migre pas d'elle-même.

Chaque équipe peut formuler une observation exacte : la route fonctionne, le DNS est à jour, l'hôte possède une nouvelle adresse, le service répond. L'ensemble reste fragile parce que ces constats se rapportent à des horloges différentes.

Le RFC 4192 décrit une renumérotation sans jour de rupture : installer le nouveau préfixe tout en maintenant l'ancien, atteindre un état stable à deux préfixes, déplacer les usages, puis retirer l'ancien. Le texte présente un canevas à adapter, pas une automatisation universelle. Les mécanismes sont normalisés ou documentés ; la preuve de changement reste à la charge de l'opérateur.

Le préfixe traverse toute l'exploitation

Une adresse IPv6 se retrouve dans le plan d'adressage, les interfaces de routeurs, les Router Advertisements, DHCPv6, les préfixes délégués, les filtres d'entrée et de sortie, les ACL, les configurations de service, le DNS direct et inverse, les listes d'autorisation, la supervision et les caches applicatifs. Le RFC 6879 insiste sur les configurations manuelles, les sessions longues et les systèmes placés hors de l'autorité directe de l'équipe.

L'inventaire fait donc partie de la preuve. Ne trouver aucun littéral est utile mais insuffisant : une adresse peut être dérivée d'un préfixe, mémorisée par un processus, copiée dans le filtre d'un partenaire ou conservée sur un site resté hors ligne. Le reçu doit préciser la surface inspectée, la version du changement, l'acteur et les exceptions.

Préférée, valide, utilisée : trois notions distinctes

Le RFC 4862 attribue deux durées à une adresse autoconfigurée. À l'expiration de la durée préférée, l'adresse devient déconseillée. À l'expiration de la durée valide, elle devient invalide. Le RFC 6724 demande au choix d'adresse source d'éviter une adresse déconseillée lorsqu'une adresse préférée convient.

La dépréciation agit donc sur les nouvelles communications. Elle ne prouve ni la fin des sessions existantes, ni le rafraîchissement des pairs enregistrés, ni l'expiration d'une ancienne réponse AAAA chez un client entrant. Maintenir l'ancienne adresse valide préserve une voie de reprise, mais peut masquer les dépendances si les flux ne sont pas ventilés par préfixe et par âge.

La règle des deux heures du RFC 4862 limite aussi la réduction brutale d'une durée valide par une Router Advertisement non authentifiée. Cette protection contre le déni de service signifie qu'une commande centrale d'urgence ne constitue pas nécessairement un interrupteur universel. Le plan doit suivre le comportement observé des hôtes, pas seulement la consigne du contrôleur.

Succursale, service et résolveur n'ont pas la même heure

Le RFC 8415 transporte les durées préférée et valide des adresses et préfixes délégués, avec renouvellement et rebinding. Un routeur client peut donc conserver un ancien IA_PD alors que la route amont, un hôte SLAAC et la zone faisant autorité ont changé. Un site absent pendant tout le chevauchement peut revenir avec un état local jamais testé.

Le RFC 8978 décrit le maintien possible de préfixes SLAAC périmés lors d'événements de renumérotation rapide. Le RFC 9096 recommande de coordonner les durées pertinentes des Router Advertisements avec la validité résiduelle d'un préfixe délégué. Ce sont des considérations d'exploitation, non l'affirmation que tous les équipements de bord réagissent de la même façon.

Le DNS ajoute plusieurs horloges. Les TTL des enregistrements gouvernent les réponses AAAA et PTR en cache. La propagation entre serveurs faisant autorité a son propre délai. Les adresses de résolveur et listes de recherche apprises par Router Advertisement possèdent des durées RDNSS et DNSSL définies par le RFC 8106. Renuméroter le service et renuméroter le résolveur qui permet de le trouver sont deux opérations.

Les réponses positives ne suffisent pas. Le RFC 2308 encadre le cache négatif. Un résolveur ayant interrogé un nom avant sa création peut continuer à répondre négativement après publication. Mesurer seulement le TTL de l'enregistrement AAAA ne borne pas ce défaut.

Le RFC 4472 rappelle aussi qu'une application de longue durée peut conserver un résultat DNS au-delà du TTL de l'enregistrement. Cette observation justifie de mesurer les applications ; elle ne fixe pas une durée de cache universelle.

Le RFC 4861 complète la surface locale : Router Advertisements, routeurs et informations de préfixe sont interprétés dans le temps par les hôtes. Il faut vérifier ce qu'ils ont appris, pas seulement ce que l'équipement devait annoncer.

La convergence est un maximum

Inférence opérationnelle : le bon modèle prend le maximum des délais encore ouverts : route, filtre, PIO, IA_PD, RDNSS, cache positif, cache négatif, cache applicatif et session, auxquels s'ajoute toute exception statique sans minuterie.

Une moyenne efface la succursale hors ligne, le résolveur au cache négatif plus long, l'ACL d'un partenaire traitée par ticket et l'appliance qui ne résout son serveur qu'au démarrage. Le dénominateur doit couvrir toutes les dépendances et tous les points d'observation annoncés.

Une sonde prouve la joignabilité du nouveau préfixe. Une requête DNS prouve la réponse actuelle d'un résolveur. Un export de flux prouve un usage observé. Aucune preuve isolée n'autorise le retrait. Elles deviennent décisionnelles lorsqu'elles portent la même version de changement et le même registre d'exceptions.

Sources