Résumé

  • RFC 9686 permet à un appareil de déclarer au service DHCPv6 une adresse IPv6 qu’il a lui-même sélectionnée par SLAAC ou configuration statique. RFC 9915 décrit la création, côté serveur, d’un bail pour cet enregistrement, sans faire de ce bail la preuve d’une attribution DHCPv6.
  • Bail et binding doivent rester distincts : RFC 9915 expose un modèle de cycle de vie dans lequel le serveur crée le bail, tandis que RFC 9686 dit seulement que le serveur devrait enregistrer une liaison entre Client Identifier et adresse.
  • Pour SLAAC, le calcul d’un instant nominal à 80 % du Valid Lifetime, désynchronisé par un facteur compris entre 0,9 et 1,1, ne programme pas initialement un rafraîchissement. L’absence de message au passage de ce seuil ne signale donc pas, à elle seule, une défaillance.
  • ADDR-REG-REPLY atteste la réception d’un ADDR-REG-INFORM valide et oblige le client à cesser ses retransmissions. Il ne garantit ni persistance, ni validité de l’adresse, ni identité, ni joignabilité, ni observation d’un paquet.
  • Un audit crédible doit conserver séparément les événements, leurs horodatages, le contexte du relais ou du lien, les transformations en aval et les règles de suppression. L’expiration opérationnelle d’un état n’est pas synonyme d’effacement immédiat de son journal historique.

Le problème apparaît souvent après la suppression

La demande adressée à l’équipe de conformité paraît modeste : retrouver qui utilisait une adresse IPv6 pendant une fenêtre précise. Pourtant, cette question oblige à rapprocher plusieurs mémoires techniques qui n’ont ni le même objet, ni la même force probante, ni la même durée de vie.

Un journal d’application peut montrer une requête. IPFIX peut décrire un flux. Un pare-feu peut enregistrer une adresse source. Une Neighbor Cache historique peut associer cette adresse à une adresse de couche liaison. Un relais DHCPv6 peut apporter un contexte d’interface ou de topologie. Les données d’un point d’accès peuvent situer une association au réseau radio. RADIUS peut relier une session d’accès à un compte. RFC 9686 ajoute une autre pièce : la déclaration au serveur DHCPv6 d’une adresse auto-générée ou configurée statiquement.

Ces éléments ne sont pas interchangeables. Une Neighbor Cache ou le contexte d’un point d’accès renseigne sur un voisinage ou un attachement ; il ne prouve pas qu’un paquet ou un flux particulier a effectivement été émis. Cette preuve doit venir d’une observation distincte, telle qu’un journal applicatif, un pare-feu ou des données de flux.

Si les périodes de conservation divergent, la reconstruction devient asymétrique. L’organisation peut encore voir le trafic, mais plus son contexte d’accès ; conserver un Client Identifier, mais plus les données permettant de l’interpréter ; ou retrouver une réponse DHCPv6 sans pouvoir démontrer qu’une liaison a été inscrite dans la base. Ce qui subsiste finit alors par sembler plus probant que ce qui a disparu. C’est un biais documentaire, pas une propriété du protocole.

La gouvernance des données doit donc précéder l’incident. Il ne suffit pas de fixer une durée générique pour « les journaux réseau ». Il faut savoir quelle assertion contient chaque source, quel événement déclenche sa création, quelle horloge la date, quels traitements la modifient, quand son état opérationnel expire et quelles données complémentaires sont nécessaires pour l’interpréter.

Un bail créé pour une adresse choisie ailleurs

RFC 9686 est un document Standards Track de l’IETF, issu du groupe DHC et publié en décembre 2024. Il permet à l’infrastructure DHCPv6 de connaître des adresses qu’elle n’a pas sélectionnées.

Le point terminologique est essentiel. RFC 9915, qui remplace RFC 8415 comme spécification DHCPv6 courante, décrit dans sa section 6.6 un mécanisme dont la particularité est que l’adresse n’est pas sélectionnée par le serveur DHCP, mais par l’appareil lui-même. Elle indique ensuite qu’un bail est créé par le serveur, que l’appareil accomplit des opérations périodiques pour obtenir son renouvellement et que le bail peut finalement expirer. Cette formulation décrit le modèle ; elle n’emploie pas un MUST au sens de RFC 2119.

Il existe donc bien un bail côté serveur. Pour une adresse SLAAC, l’appareil a formé ou sélectionné l’adresse dans le cadre de l’auto-configuration. Pour une adresse statique, la sélection résulte d’une configuration locale. DHCPv6 n’a attribué ni l’une ni l’autre. Le bail représente l’état et le cycle de vie de leur enregistrement auprès du serveur ; il ne transforme pas rétroactivement cette adresse en allocation DHCPv6.

La précision est également nécessaire dans l’autre sens : le bail décrit par RFC 9915 ne doit pas être confondu avec la liaison de base de données définie par RFC 9686. Cette dernière dit que le serveur devrait enregistrer un binding entre le Client Identifier fourni et l’adresse IPv6. La création du binding est donc un SHOULD, non une présence garantie par tout échange réussi.

Pour l’audit, le bail documente un cycle d’enregistrement. Il ne constitue pas, à lui seul, un acte d’attribution faisant autorité sur l’origine de l’adresse, son usage effectif ou son détenteur humain.

Ce que la déclaration apporte

Le client commence par déterminer si l’infrastructure prend en charge le mécanisme. Il demande OPTION_ADDR_REG_ENABLE dans les échanges DHCPv6 prévus à cet effet. Lorsqu’il reçoit et traite une annonce de capacité dans un Advertise ou Reply, il peut démarrer l’enregistrement selon les règles de RFC 9686. Sans ce signal, il ne doit pas enregistrer ses adresses.

Cette annonce établit une capacité sur l’interface ou le lien considéré. Elle ne montre pas que tous les appareils participent, que tous les serveurs ont conservé les mêmes informations ou que le registre sera exhaustif. Après avoir découvert la prise en charge et commencé l’enregistrement, le client poursuit celui-ci jusqu’à sa déconnexion du lien, même si des réponses ultérieures n’incluent plus l’option.

Lorsqu’une adresse auto-générée ou statique devient valide, le client envoie un ADDR-REG-INFORM comportant son Client Identifier et exactement une option IA Address. Il émet un message distinct pour chaque adresse. Le paquet part de l’adresse enregistrée et de l’interface où celle-ci est configurée.

Si le message parvient directement au serveur, l’adresse de l’option IA Address doit correspondre à l’adresse source du paquet. S’il est relayé, la comparaison porte sur le peer-address du Relay-forward le plus interne. Cette concordance protège la cohérence de la déclaration dans son contexte de transport. Elle n’authentifie ni l’appareil au sens général, ni un abonné, ni une personne.

Les adresses link-local sont exclues du mécanisme. Les adresses obtenues par DHCPv6 ne doivent pas être réenregistrées par cette voie. Les ULA, qui ont une portée globale au sens de l’architecture de portée IPv6 malgré leur usage local, peuvent en revanche être concernées.

La force exacte des obligations

La reconstruction d’un audit dépend des verbes normatifs. Transformer un « devrait » en « doit » conduit à attendre des données ou des contrôles que la norme ne garantit pas pour chaque traitement.

Le serveur doit rejeter un ADDR-REG-INFORM dépourvu de Client Identifier, contenant un Server Identifier ou une Option Request, ne contenant pas l’IA Address requise, ou présentant une divergence entre l’IA Address et la source originale. Une fois ces contrôles franchis, il devrait vérifier que l’adresse convient au lien ou appartient à un préfixe délégué au client.

Cette vérification de pertinence topologique est un SHOULD. Si elle est effectivement exécutée et que l’adresse échoue, le serveur doit abandonner le message et devrait journaliser l’échec. Un dossier d’audit ne peut donc pas supposer que tout enregistrement accepté a nécessairement subi ce contrôle. Il doit conserver, si elle existe, l’information indiquant que la vérification a été effectuée et son résultat.

Pour un enregistrement accepté, le serveur doit journaliser les informations, sauf s’il est configuré pour ne pas le faire. Il devrait consigner le DUID et l’adresse de couche liaison lorsqu’elle est disponible. Il devrait créer une liaison entre le Client Identifier et l’adresse IPv6. Il devrait marquer l’adresse comme indisponible pour une attribution et ne pas l’inclure dans de futurs Advertise. Enfin, il doit envoyer un ADDR-REG-REPLY.

Ces prescriptions produisent quatre niveaux de connaissance différents. La journalisation est obligatoire par défaut, mais peut être désactivée. La création du binding est recommandée. Le marquage comme non allouable est lui aussi recommandé. La réponse est obligatoire pour l’enregistrement accepté. La présence d’un Reply ne permet donc pas d’inférer que les trois autres opérations ont toutes été exécutées ni que leurs résultats ont persisté.

RFC 9686 borne explicitement la portée du Reply : il indique uniquement que le ADDR-REG-INFORM a été reçu et que le client doit cesser de le retransmettre. Il ne valide pas l’adresse et n’est pas requis pour que celle-ci soit utilisable. Un relais ou un équipement qui observe cette réponse ne doit créer ni modifier un état de transfert ou de sécurité à partir d’elle.

Le temps n’est pas un simple compteur de renouvellement

Pour une adresse SLAAC, le client calcule NextAddrRegRefreshTime à partir de 80 % du Valid Lifetime courant. Il applique un multiplicateur aléatoire, AddrRegDesyncMultiplier, uniformément réparti entre 0,9 et 1,1, afin d’éviter que de nombreux clients se synchronisent. Cependant, le calcul initial de cet instant ne programme aucun rafraîchissement.

La programmation intervient lorsque le réseau modifie le Valid Lifetime de plus de 1 %. Le client calcule alors un nouvel intervalle et programme le rafraîchissement pour le plus proche des instants pertinents. Si les annonces du réseau laissent l’heure d’expiration attendue inchangée — par exemple lorsque la durée restante diminue simplement avec l’écoulement du temps — aucun rafraîchissement n’est nécessaire et aucun message peut n’être émis.

Il serait donc erroné de traiter le passage du seuil nominal de 80 % sans nouveau ADDR-REG-INFORM comme un indicateur de panne. Ce seuil contribue au calcul d’état ; il n’est pas une échéance imposant systématiquement une transmission. L’audit doit examiner l’évolution du Valid Lifetime et de l’expiration attendue, pas seulement comparer deux horodatages à une fraction théorique.

Une adresse statique suit une logique différente. Sa durée de validité est considérée comme infinie et n’est pas modifiée par les Router Advertisements. Son inscription est rafraîchie selon StaticAddrRegRefreshInterval, dont la valeur par défaut est de quatre heures et qui devrait être configurable. Ces quatre heures constituent uniquement un intervalle de rafraîchissement de l’inscription : elles ne sont ni la durée de vie de l’adresse statique, ni la durée du bail.

Lorsque le client signale une IA Address dont le Preferred Lifetime et le Valid Lifetime sont nuls, le serveur doit agir comme si l’adresse avait expiré. Lorsque le binding Client Identifier-adresse arrive à expiration, le serveur doit le retirer et considérer l’adresse de nouveau disponible.

Cette suppression concerne l’état opérationnel du binding. Elle ne définit pas à elle seule la durée de conservation des journaux historiques. Un système peut retirer une liaison active tout en conservant, selon sa politique, un événement d’enregistrement, de mise à jour ou d’expiration. À l’inverse, un réglage de journalisation ou de rétention peut faire disparaître la trace historique alors que le protocole a correctement géré l’état en son temps. Confondre ces deux plans fausse toute analyse rétrospective.

Un schéma de preuve pour la mémoire d’audit

Le dossier devrait conserver des assertions séparées plutôt qu’un identifiant composite supposé répondre à toutes les questions.

Objet conservé Ce qu’il permet d’établir Limite à inscrire dans le dossier
Annonce OPTION_ADDR_REG_ENABLE Le mécanisme était proposé dans ce contexte de réseau Ne prouve ni participation universelle ni exhaustivité
ADDR-REG-INFORM Un Client Identifier a déclaré une adresse et ses durées Assertion du client, non attribution DHCPv6
Source ou peer-address interne La déclaration a été reçue depuis un contexte déterminé Ne constitue pas une identité de personne ou d’abonné
Résultat du contrôle topologique L’adresse a réussi ou échoué à un contrôle de lien ou de préfixe Contrôle recommandé, donc potentiellement non exécuté
Bail d’enregistrement Le serveur maintient l’état de cycle de vie décrit par RFC 9915 Ne prouve pas que le serveur a choisi l’adresse
Binding Client Identifier-adresse Une liaison a été inscrite dans la base Création seulement recommandée par RFC 9686
ADDR-REG-REPLY Le message valide a été reçu et les retransmissions cessent Ne prouve ni persistance, ni validité, ni identité
Neighbor Cache, SAVI, port ou point d’accès Un voisinage ou un attachement local a été observé Ne démontre pas l’émission d’un paquet ou d’un flux donné
Pare-feu, application ou IPFIX Un paquet, une requête ou un flux a été observé Une adresse source n’identifie pas son auteur
RADIUS ou système d’accès Un compte ou abonné était associé à une session Ne prouve pas qui a causé chaque paquet
Registre de décision Une mesure a été autorisée selon une politique N’améliore pas la véracité des faits techniques

Chaque objet devrait conserver sa source, l’horloge utilisée, le fuseau ou la normalisation temporelle, la méthode de collecte, le contexte de relais ou de topologie, sa période opérationnelle, les transformations appliquées et la règle de suppression. Une correction ultérieure doit compléter l’historique, non remplacer silencieusement la valeur ancienne.

Unicité, attachement et identité

La Duplicate Address Detection de RFC 4862 cherche à établir qu’une adresse est probablement unique sur le lien. Elle n’est pas parfaitement fiable et n’authentifie pas le nœud. Une adresse ayant franchi DAD n’est donc ni certifiée ni attribuée à une personne.

FCFS SAVI, défini par RFC 6620, apporte une assurance d’une autre nature dans son propre périmètre. Il lie une adresse source à un binding anchor suivant un principe de premier arrivé, premier servi. Dans le modèle FCFS SAVI, seuls les ports de commutateur sont autorisés comme binding anchors. La force de l’observation dépend donc de la capacité de ce port à représenter correctement l’attachement dans le périmètre où la fonction est appliquée. Un système n’est pas plus fiable que son binding anchor ; un port de commutateur n’est pas une identité humaine et ne constitue pas, à lui seul, une observation de trafic applicatif.

RFC 9099 recommande par conséquent de corréler plusieurs ensembles : journaux applicatifs, pare-feu, IPFIX, Neighbor Cache historique, DHCPv6, événements SAVI, ports de commutation, authentification et comptabilité RADIUS. Cette pluralité reflète la diversité des questions. L’annonce décrit une capacité ; le client formule une assertion ; le serveur reçoit et gère un état ; un capteur peut observer un paquet ou un flux ; un système d’accès connaît une session ; une politique distincte autorise ou refuse une action.

Sources