Résumé

  • L’omission ne vaut retrait que dans une Reply valide à Renew, Rebind ou Information-Request, lorsque le client redemandait une option reçue auparavant.
  • Elle établit le contenu de l’échange et l’obligation du client, non la suppression locale, le rechargement des processus ni la fin des flux vers l’ancienne destination.
  • Les IA suivent d’autres règles et une valeur identique peut venir d’une autre autorité ; la provenance est donc indispensable.

Une absence encadrée par trois pièces

La section 18.2.10.5 de RFC 9915 ne transforme pas chaque champ absent en commande. Il faut conserver la Reply initiale, la nouvelle demande où l’option figure dans les éléments souhaités, puis la Reply valide et corrélée qui ne la renvoie plus. Sans la demande intermédiaire, on ignore si le serveur devait répondre. Sans validation, on ignore si le client pouvait appliquer le message.

Lorsque ces conditions sont réunies, le client SHOULD cesser d’utiliser l’information, revenir à l’état par défaut pertinent et agir comme s’il n’avait jamais reçu l’option. C’est une exigence nette. Ce n’est toutefois pas une télémétrie du gestionnaire de configuration. Le serveur sait ce qu’il a envoyé ; il ne sait pas si un démon a relu son fichier ni si une connexion ancienne subsiste.

Deux exemples qui interdisent les raccourcis

La RFC autorise une persistance très limitée : aucun moyen viable d’effacer la valeur, aucune autre source et aucun impact externe. Le nom d’hôte issu de Client FQDN sert d’exemple, lorsque le système ne sait raisonnablement pas le désactiver. RFC 4704 décrit le rôle de cette option dans la coordination des mises à jour DNS.

L’adresse d’un serveur NTP est le contre-exemple. Si elle était fournie auparavant et disparaît d’une Reply qualifiante, le client MUST cesser d’utiliser cette adresse configurée. RFC 5908 précise qu’il s’agit d’une localisation de serveur pour le client de temps. Un flux persistant vers cette adresse devient donc un signal d’enquête, pas encore un verdict complet.

RFC 9915 demande aussi de rester ouvert à d’autres sources de la même information. Pour DNS, RFC 3646 fournit des résolveurs par DHCPv6 tandis que RFC 8106 les fournit par RDNSS dans les Router Advertisements. Une adresse inchangée peut avoir changé d’autorité. Comparer seulement les valeurs masque cette transition.

Les IA et Reconfigure ont leurs propres limites

La règle exclut expressément les options IA. Les adresses IA_NA et préfixes IA_PD relèvent de la section 18.2.10.1. Une alerte générique « option absente » ne doit pas réinterpréter leur cycle de bail.

Reconfigure n’est pas davantage le nouvel état. Il déclenche Renew, Rebind ou Information-Request. La RFC recommande de journaliser l’événement et permet d’avertir les applications, mais réception du déclencheur, échange réussi, application locale et résultat de service restent quatre preuves.

Fermer la preuve côté client

Un dossier solide relie l’ancienne attribution, la nouvelle demande, l’omission corrélée, la version locale de configuration, le rechargement des consommateurs, la provenance de toute valeur survivante et le dernier trafic vers l’ancienne destination. La norme établit le contrôle ; l’état d’exécution établit l’application ; les mesures établissent l’effet.

RFC 8415 portait déjà l’essentiel de cette règle. RFC 9915 lui donne une sous-section identifiable tout en remplaçant l’ancien texte de base. Il ne faut donc ni inventer une rupture historique en 2026, ni confondre la clarté de la citation avec une preuve de conformité sur le terrain.

Sources