Résumé

  • Une adresse temporaire réduit la période pendant laquelle un même identifiant d’interface peut relier plusieurs sessions sortantes ; son successeur est préparé avant sa dépréciation.
  • Une adresse dépréciée reste valide : elle peut servir à une communication déjà établie, mais ne devrait plus lancer une nouvelle communication si une adresse préférée convient.
  • La rotation ne fournit ni anonymat, ni chiffrement, ni authentification. Préfixe, adresse stable, comptes, cookies, journaux et observation sur le lien demeurent exploitables.

La scène utile n’est pas celle d’une adresse qui disparaît. Une interface possède une adresse temporaire préférée. Avant la fin de cette préférence, elle commence à fabriquer la suivante et vérifie que celle-ci n’est pas déjà utilisée. L’ancienne devient ensuite dépréciée. Une nouvelle connexion devrait prendre la nouvelle adresse ; une connexion existante peut rester attachée à l’ancienne. Plus tard seulement, à l’expiration de la durée de validité, l’ancienne adresse devient invalide.

Cette succession permet de comprendre pourquoi les extensions de confidentialité d’IPv6 sont à la fois sérieuses et limitées. Elles retirent progressivement un identifiant du prochain choix de source. Elles ne rendent pas l’hôte invisible.

Le problème d’un identifiant trop durable

L’autoconfiguration sans état assemble un préfixe annoncé par le réseau et un identifiant d’interface. Au début d’IPv6, cet identifiant pouvait être dérivé d’un identifiant matériel globalement unique. Le préfixe variait avec le réseau, mais la partie basse de l’adresse pouvait accompagner une machine. Une observation faite dans deux lieux différents trouvait alors un point de raccordement commode.

En janvier 2001, la RFC 3041 a proposé des adresses supplémentaires construites avec des identifiants changeant au fil du temps. Elles devaient servir au démarrage des sessions sortantes, puis être dépréciées et remplacées. La décision importante était double : produire une adresse différente et lui donner la préférence au bon moment. Une adresse aléatoire jamais sélectionnée n’améliore rien ; une adresse temporaire jamais expirée devient simplement un autre identifiant stable.

La première version conservait le comportement de base de l’autoconfiguration. Elle n’effaçait pas l’adresse dite publique ou stable. Elle ajoutait un autre état à l’interface et confiait à la sélection d’adresse source le soin de l’utiliser. Déjà, une adresse dépréciée pouvait continuer une connexion établie. Le changement d’identifiant devait gêner la corrélation, pas casser immédiatement les échanges.

La RFC 4941 a remplacé la RFC 3041 en septembre 2007. Elle a exigé la détection de doublon pour chaque adresse temporaire, ajouté un réglage par préfixe, permis des identifiants distincts selon les préfixes et libéré la génération de son lien exclusif avec MD5. Elle recommandait toutefois de désactiver le mécanisme par défaut. Sa durée préférée suggérée était d’un jour, mais sa durée valide pouvait atteindre une semaine.

La RFC 8981, publiée en février 2021, a repris l’ensemble. Elle a supprimé la recommandation de désactivation par défaut. Elle a exigé que les identifiants des différentes adresses temporaires d’un même hôte soient statistiquement distincts, y compris entre préfixes. Elle calcule une désynchronisation propre à chaque adresse, afin que les renouvellements ne suivent pas un rythme fixe. Enfin, elle a ramené la validité maximale par défaut d’une semaine à deux jours, tout en conservant un jour comme durée préférée par défaut.

L’histoire ne va donc pas simplement d’une adresse matérielle à une adresse aléatoire. Elle passe d’un identifiant temporaire commun à plusieurs préfixes vers une séparation plus nette, d’un calendrier plus prévisible vers des échéances individualisées, et d’une longue traîne d’adresses valides vers un chevauchement plus court.

Les deux échéances

La RFC 4862 distingue précisément les états. Tant que sa durée préférée court, une adresse peut être utilisée sans restriction. À l’expiration de cette durée, elle devient dépréciée. Son usage est découragé, surtout comme source d’une nouvelle communication, mais elle reste valide. Les paquets qui lui sont destinés continuent d’être traités ; une connexion TCP existante peut la conserver si changer d’adresse provoquerait une rupture.

La durée valide est la seconde échéance. Quand elle expire, l’adresse n’est plus affectée à l’interface. Elle ne doit plus être utilisée comme source et ne doit plus être reconnue comme destination. Confondre ces deux moments produit deux erreurs opposées : croire que la rotation tue immédiatement les connexions, ou croire qu’une adresse dépréciée demeure une bonne source pour de nouvelles sessions.

La RFC 8981 demande donc de lancer la régénération un peu avant la dépréciation, selon REGEN_ADVANCE. Ce délai doit couvrir la génération et la détection de doublon. Dans le fonctionnement normal, il n’existe qu’une adresse temporaire non dépréciée par préfixe et interface, sauf pendant ce court passage de relais. Plusieurs adresses plus anciennes peuvent rester valides pendant que les couches supérieures terminent leur travail.

Les valeurs d’un jour pour la préférence et de deux jours pour la validité ne décrivent pas tous les systèmes. Ce sont des valeurs configurables. La durée annoncée du préfixe peut encore les raccourcir. DESYNC_FACTOR, recalculé pour chaque adresse, réduit de manière aléatoire la durée préférée. L’opérateur doit donc lire les minuteries réellement configurées avant d’interpréter une trace.

Un changement de réseau forme une autre frontière. Lorsqu’une interface rejoint un lien différent, ses anciennes adresses temporaires doivent être retirées et de nouvelles doivent être produites. Les deux liens reçoivent ainsi des identifiants aléatoires différents. Une implémentation peut toutefois reconnaître qu’une simple coupure suivie d’un retour concerne le même lien, afin de ne pas transformer chaque incident radio en nouvelle identité temporaire.

La protection exacte

Une adresse IP doit rester visible pour acheminer une réponse. Le correspondant la voit ; les équipements sur le trajet la voient ; un service peut la conserver dans ses journaux. Lorsque la partie identifiant reste inchangée pendant longtemps, elle devient une clé de jointure gratuite. Plusieurs transactions, puis plusieurs réseaux, peuvent être rapprochés sans comprendre l’application.

La rotation découpe cette clé en intervalles plus courts. Les nouvelles sessions sortantes utilisent normalement l’adresse temporaire actuellement préférée. Les sessions ultérieures utilisent une autre adresse. La collecte fondée uniquement sur l’identifiant d’interface devient plus coûteuse et moins certaine. L’adresse révélée au cours d’une communication reste également joignable moins longtemps.

Mais la partie préfixe peut rester stable et identifier un foyer ou un très petit réseau. Une adresse stable peut encore exister et être employée par d’autres flux. Un nom DNS peut relier les adresses. Un cookie ou un compte authentifié peut relier les sessions. Les journaux d’un correspondant peuvent reconstituer la continuité. Le routeur par défaut voit les anciennes et les nouvelles adresses. Un observateur sur le chemin peut comparer tailles et rythmes de paquets, même lorsque la charge utile est chiffrée.

L’adresse temporaire ne chiffre donc ni l’en-tête ni le contenu. Elle n’authentifie personne. Elle ne garantit pas l’anonymat et ne retire pas les informations déjà communiquées. Si l’utilisateur se connecte à un compte, le service qui reçoit l’authentification peut associer ce compte à l’adresse temporaire du moment.

La RFC 8981 permet même une configuration ne comportant que des adresses temporaires ; elle ne rend pas obligatoire la coexistence d’une adresse stable. L’observation d’un paquet ne suffit donc pas à dresser l’inventaire de l’interface. La prudence vaut dans les deux sens : la présence d’une adresse temporaire ne prouve pas l’absence d’un état stable, et son changement ne prouve pas la cause du changement.

L’observation opérationnelle

Pour les équipes réseau, le coût est concret. Une machine peut apparaître sous plusieurs adresses dans les journaux. Un défaut récurrent peut ressembler à plusieurs hôtes. Certains équipements de sécurité peuvent interpréter une régénération rapide comme une usurpation. Plusieurs adresses simultanées consomment des entrées de voisinage et des groupes multicast. Une application qui exige la même adresse pour plusieurs connexions peut mal supporter une sélection qui évolue.

La bonne unité de preuve devient une affectation bornée : adresse, horodatage, préfixe, interface ou lien, état de préférence et, si nécessaire, flux ou session applicative. Une adresse observée à midi prouve ce paquet et ce contexte. Elle ne constitue pas le nom permanent d’un équipement. Une adresse dépréciée encore active ne montre pas un échec de rotation ; elle peut simplement achever le travail que la norme lui permet de conserver.

L’autorité reste distribuée. Le routeur annonce les durées du préfixe. L’hôte génère, déprécie et invalide. L’administrateur active le mécanisme globalement ou par préfixe. L’application et la politique système participent au choix de source. Les correspondants gardent leurs propres traces. La norme ordonne les transitions sans offrir à un acteur une vue universelle.

L’apport durable de ces RFC tient à cette modestie. Elles n’ont pas caché l’adresse IPv6. Elles ont décidé qu’un identifiant visible ne devait pas rester indéfiniment le choix naturel de la prochaine connexion.

Sources