Résumé

  • Dans le RFC 5007, LEASEQUERY ne modifie aucun bail : une réponse réussie décrit la vue d’un serveur DHCPv6, pas l’état présent du terminal.
  • Il faut conserver séparément le périmètre des serveurs interrogés, la forme de chaque réponse, les rapprochements, l’état local obtenu et le résultat réseau ou d’autorisation ensuite observé.

Après le redémarrage d’un concentrateur d’accès, une ligne de liaison réapparaît dans son état local. L’équipe de nuit marque le terminal « présent » et transmet le dossier.

Le RFC 5007 autorise la première opération, pas la seconde conclusion. Il définit une requête légère vers un serveur DHCPv6 afin d’obtenir les informations de liaison qu’il détient. Il précise que LEASEQUERY est purement interrogatif : le message ne change ni l’état d’une adresse ou d’un préfixe, ni la liaison associée.

La nuance porte sur la nature de la preuve. Le serveur produit une représentation administrative. Le réseau peut fournir l’observation d’un paquet. Un équipement applique ensuite une route ou un filtre. Un annuaire avance une identité. Un moteur d’accès rend une décision. Une même adresse peut circuler entre ces couches, sans que leur vérité se confonde.

Le cas d’usage « à la demande » commence souvent par un paquet IPv6 reçu. Le concentrateur cherche alors à rafraîchir ce qu’il sait du client auquel l’adresse est louée. L’ordre est important : le paquet déclenche la requête ; la réponse ne prouve pas rétroactivement l’origine légitime du paquet et ne garantit pas qu’un autre paquet suivra.

Le protocole distingue trois réussites. Avec des liaisons, le serveur renvoie OPTION_CLIENT_DATA et le demandeur actualise son état local. Avec des liaisons réparties sur plusieurs liens, il renvoie OPTION_LQ_CLIENT_LINK : il faut encore interroger chaque lien. Sans liaison connue, la réponse peut être réussie tout en ne contenant ni données client ni liste de liens. Un voyant unique « succès » efface donc la différence entre un résultat, un sommaire d’enquêtes restantes et une réponse vide.

Une erreur ne prouve pas davantage l’absence. Selon le code, le demandeur peut corriger la requête, sélectionner un autre serveur, utiliser l’adresse multicast de tous les serveurs DHCP ou s’arrêter selon sa politique locale. Le RFC demande de viser le serveur réputé faire autorité ; si celui-ci n’est pas connu, il recommande d’interroger tous les serveurs connus ou configurés. Un arrêt licite reste un arrêt, pas un consensus.

Les réponses multiples demandent un rapprochement. Les données disjointes—par exemple une adresse chez un serveur et un préfixe délégué chez un autre—devraient être fusionnées. Deux déclarations de même type et de même valeur se chevauchent et sont qualifiées de conflictuelles. Le demandeur devrait préférer celle dont OPTION_CLT_TIME est le plus récent.

Les errata vérifiés évitent une lecture trop brutale. L’erratum technique 3763 supprime la consigne initiale de jeter les données client dépourvues de OPTION_CLT_TIME. Dans un dispositif de bascule, le partenaire peut posséder la liaison sans avoir l’heure de dernière transaction. Si une autre réponse contient cette durée, elle est préférable ; si la réponse sans durée est la seule reçue, ses données restent recevables. L’erratum éditorial 4816 corrige en outre le nom en OPTION_LQ_CLIENT_LINK.

Cette durée n’est pas une preuve de présence. Elle mesure, du point de vue du serveur, le temps écoulé depuis sa dernière transaction avec le client au moment où la réponse est construite. Elle n’authentifie ni une personne, ni le propriétaire du matériel, ni le paquet courant. Elle ne dit pas qu’une règle d’accès a accepté le trafic.

Le préfixe délégué révèle un autre piège. Après redémarrage, aucun trafic ne peut parvenir au concentrateur s’il n’est pas encore capable d’injecter la route nécessaire. La requête à la demande attend alors un déclencheur que l’état incomplet empêche d’arriver. Le RFC 5007 évoque une reconstruction anticipée, puis la laisse explicitement hors de son périmètre. Le RFC 5460 traite plus tard l’interrogation en masse ; le RFC 7653 ajoute des notifications actives. Il ne faut attribuer ni l’une ni les autres à une réponse ponctuelle.

La protection de l’échange n’élargit pas son sens. Le texte discute authentification DHCP et IPsec, mais un relais de confiance peut transporter une demande d’origine non fiable. Le serveur peut refuser une requête relayée ou limiter les informations même pour un demandeur autorisé. Un serveur malveillant peut fournir de fausses données de bail ou de route. Authentifier l’émetteur d’une déclaration ne transforme pas sa déclaration en observation physique.

La mise en cache négative protège aussi la ressource, non la vérité. Le demandeur peut mémoriser qu’une requête récente n’a fourni aucune donnée client afin de ne pas surcharger le serveur. Cette mémoire possède un âge et un contexte. Elle ne démontre pas durablement qu’aucune liaison, machine ou personne autorisée n’existe.

Un reçu de vue de liaison devrait consigner :

  1. le déclencheur observé, la clé de requête, l’adresse ou le DUID et le lien ;
  2. l’ensemble des serveurs réputés faire autorité et la couverture réellement obtenue ;
  3. chaque échange, contexte d’authentification et de relais, reprise et raison d’arrêt ;
  4. la variante exacte de réponse et tout champ volontairement limité ;
  5. les requêtes par lien, fusions de données disjointes et arbitrages de conflits ;
  6. la présence ou l’absence de OPTION_CLT_TIME et la préférence appliquée ;
  7. la cache négative et la révision de l’état local ;
  8. la décision de routage, de filtrage ou d’accès ;
  9. l’effet réseau observé séparément.

Ce reçu est une recommandation de gouvernance, non une obligation cachée du RFC. Il suit la discipline des couches de réalité de Heng Lu : garder distincts le registre du serveur, l’échange, la mémoire locale, l’acte d’exécution et son effet.

Le RFC 7513 montre que Leasequery peut contribuer à restaurer des liaisons SAVI. Il ne fait pas du bail un certificat d’identité humaine. Les fondations DHCPv6 et délégation de préfixe figurent dans les RFC 3315 et RFC 3633, tandis que les RFC 8415 et RFC 9915 donnent le contexte ultérieur. Aucun ne permet de nommer « présence » la vue capturée d’un serveur.

Sources