Résumé

  • Une Reconfigure authentifiée demande au client de lancer Renew, Rebind ou Information-request ; son envoi ne prouve pas que le client possède une nouvelle configuration.
  • La réception par le serveur de la requête demandée satisfait sa demande Reconfigure, mais le Reply, l’installation locale et les effets réseau restent des preuves distinctes.

Dans un tableau d’exploitation, l’ordre peut disparaître derrière une formule séduisante : « reconfiguration terminée ». Pourtant, le protocole conserve plusieurs faits. La RFC 9915 fait de Reconfigure une sollicitation du serveur vers un client afin que celui-ci ouvre un échange déterminé. Elle ne confond pas cette sollicitation avec les informations qui pourraient être renvoyées ensuite ni avec l’usage réel de ces informations.

Le premier seuil est celui de l’acceptation et de la validité. L’option Reconfigure Accept annonce si le client accepte de recevoir ce type de message ; sans elle, le comportement par défaut est le refus. La RFC oblige également le client à écarter une Reconfigure non unicast, dépourvue de l’identifiant serveur ou client requis, de l’option correspondante, d’un type de message valable ou d’une authentification vérifiée. Un enregistrement d’émission reste donc l’observation d’une initiative du serveur, non une réception validée.

Lorsqu’une Reconfigure valable parvient au client, le fait suivant reste précis. Son option désigne Renew, Rebind ou Information-request. Le client engage l’échange ainsi désigné et ignore les nouvelles Reconfigure pendant la transaction. Le texte appelle le message initial un « trigger » : il met une procédure en mouvement. Il ne transporte pas à lui seul une adresse, un préfixe, un résolveur ou une politique devenue effective.

Le serveur peut ensuite tenir un constat utile, mais limité. La RFC 9915 lui permet d’interpréter la réception du Renew, Rebind ou Information-request demandé comme la satisfaction de sa demande Reconfigure. Cette réception prouve que le serveur a obtenu le type de message attendu. Elle ne prouve pas qu’un Reply a été envoyé ou reçu, ni que son contenu a été accepté, ni que le système local a appliqué quoi que ce soit.

Les trois suites possibles ne dispensent pas de cette distinction. Renew et Rebind ont chacun leur propre échange et leurs conditions de liaison ; Information-request vise des informations de configuration sans demander d’adresse ni de préfixe. Le Reply est l’objet qui porte les informations de configuration dans ces échanges. Pour affirmer un changement déterminé, il faut donc le Reply et ses options pertinentes. Pour affirmer l’installation, une route, l’usage du DNS, un flux ou un résultat applicatif, il faut encore les observations propres à ces faits.

L’authentification ne rend pas tous ces passages interchangeables. Elle est obligatoire dans Reconfigure en raison du risque de déni de service. La RFC 9096, elle aussi coécrite par Volz, traite d’améliorations de sécurité et de confidentialité DHCPv6. Ces textes établissent une condition de confiance pour un bord de message ; ils ne produisent pas un certificat général de disponibilité ou de succès opérationnel.

Le dossier d’exploitation devrait conserver les jointures : DUID du client, identifiant du serveur, émission et validation de Reconfigure, msg-type demandé, requête client correspondante vue par le serveur, Reply et valeurs concernées, puis une observation locale ou d’exécution lorsque le résultat est invoqué. Le registre IANA identifie les codes DHCPv6 ; il ne transforme pas un code inscrit dans un journal en preuve des étapes qui suivent.

La méthode rejoint les notes de Heng Lu sur la spécification minimale et la primauté du code exécuté : ne conserver que le plus petit fait observé. « Reconfigure envoyée » n’est pas « client configuré ». « Requête demandée reçue » n’est pas « configuration appliquée ». Les conclusions plus fortes doivent être attachées à leur propre trace.

Volz est ici l’un des cinq noms d’un standard collectif, non l’opérateur d’un client, d’un serveur ou d’un réseau déterminé. La précision de la RFC est précisément ce qui évite de convertir une relation causale plausible en résultat établi.

Sources