Résumé

  • La RFC 3736 permet à un nœud déjà doté d’une adresse IPv6 de demander d’autres paramètres par un échange DHCPv6 Information-request / Reply, sans solliciter l’attribution d’une adresse.
  • « Sans état » signifie que le serveur n’a pas besoin de conserver un état dynamique par client pour ce service ; un identifiant facultatif, la politique locale et le relais continuent de compter.

Une adresse et un résolveur : deux tâches

L’autoconfiguration sans état d’IPv6 peut fournir une adresse à partir des annonces de routeur. Elle ne répond pas à toutes les questions de configuration d’un hôte : celui-ci peut encore avoir besoin d’adresses de serveurs DNS récursifs, d’informations sur des serveurs SIP ou d’autres options. On peut facilement imaginer DHCP comme un seul bloc : demander une adresse au serveur et recevoir en même temps toute la configuration du réseau.

La RFC 3736 sépare ces fonctions. Le client possède déjà son adresse par un autre moyen — généralement l’autoconfiguration sans état ou une configuration manuelle — ainsi qu’au moins une adresse link-local pour communiquer. Il envoie Information-request avec une option de demande qui désigne les types d’options souhaités. Le serveur répond par Reply et les paramètres qu’il a retenus. Ce mode ne demande pas d’association d’identité d’adresse et n’attribue pas d’adresse.

L’échange est volontairement réduit à deux messages : Information-request, puis Reply. Un hôte peut demander sa configuration DNS sans transformer cette opération en bail d’adresse. Un même ensemble de serveurs peut répondre aux clients qui demandent des adresses et à ceux qui ne demandent que d’autres paramètres ; les agents relais fonctionnent comme dans le DHCP avec état.

Mais « sans état » ne signifie pas que le serveur est dépourvu de configuration ou de politique. La RFC 3736 dit qu’il n’a pas besoin de garder un état dynamique sur chaque client. Elle autorise aussi un identifiant de client lorsque l’administrateur souhaite personnaliser la réponse. Le serveur choisit toujours les options selon sa politique de configuration, et un relais peut toujours acheminer les messages. La limite précise est l’absence de liaison d’adresse par client à créer ou suivre pour ce service d’information.

Cette distinction aide à lire les indicateurs des annonces de routeur IPv6. Dans la RFC 4861, le drapeau Managed indique que DHCPv6 peut fournir des adresses ; le drapeau Other signale d’autres informations disponibles par DHCPv6. Lorsque Managed est activé, Other devient redondant. Ces drapeaux signalent une disponibilité : ils ne prouvent ni qu’un échange DHCP a abouti, ni que l’hôte a installé un résolveur, ni que celui-ci est joignable.

En supprimant le bail d’adresse, on perdait son horloge

Les adresses attribuées ont des durées de vie : elles indiquent quand une adresse est préférée, valide ou ne doit plus être utilisée. D’autres paramètres n’ont pas nécessairement une telle durée. La RFC 3736 laissait explicitement ouverte la question du moment où l’hôte devait renvoyer Information-request pour actualiser ses valeurs ; elle ne fixait pas non plus de règle après un changement de lien.

La RFC 4242 a ensuite ajouté l’option Information Refresh Time : une limite supérieure au délai avant une nouvelle demande d’informations DHCPv6. Sa raison est révélatrice. Sans bail d’adresse ou de préfixe dans l’échange, aucune durée de vie ne dit forcément au client quand revenir. La RFC 8415 a plus tard regroupé le DHCPv6 et rendu obsolètes les RFC 3736 et 4242, tout en conservant l’échange d’information en deux messages.

L’histoire n’est donc pas « DHCP a disparu dès que SLAAC a produit une adresse ». Adresse et paramètres complémentaires pouvaient être obtenus séparément. Cela réduisait l’état par client nécessaire au serveur d’information, mais la configuration devait toujours gérer la priorité des sources, le renouvellement, l’interface concernée et l’installation du résolveur par l’hôte. Un Reply prouve que le protocole a renvoyé des options ; il ne prouve pas, à lui seul, qu’elles ont été installées ou qu’une requête DNS a réussi.

Ces RFC ne disent pas à quelle fréquence les clients actuels utilisent ce mode ni comment un réseau donné le configure. Elles spécifient le mécanisme et ses limites, pas sa prévalence ni le résultat d’un service.

Sources