Résumé

  • Dans le parcours d'attribution courant, le DHCPACK engage la liaison côté serveur ; le client n'entre dans BOUND qu'après une dernière vérification de conflit. Il obtient un usage temporaire, pas un droit de propriété.
  • Le bail organise la suite : renouvellement auprès du serveur initial à T1, rebind possible auprès d'autres serveurs à T2, puis abandon immédiat de l'adresse à l'expiration sans nouvel acquittement.
  • Une réponse DHCPACK à DHCPINFORM n'attribue aucune adresse, ce qui interdit de déduire la nature de l'acte du seul nom du message.

L'instant où une location prend l'apparence d'un bien

Un terminal arrive sur un réseau sans configuration IPv4 exploitable. Il découvre les serveurs, choisit une offre, formule sa demande et reçoit un DHCPACK. Quelques secondes plus tard, l'adresse figure dans l'interface et les applications communiquent. Tout pousse à raconter que le réseau « a donné » l'adresse.

La RFC 2131 parle plutôt d'une liaison entre un client et des paramètres de configuration. Le serveur choisi inscrit cette liaison, mais le client doit encore vérifier que l'adresse n'est pas déjà employée sur le lien. En cas de réponse contradictoire, il envoie DHCPDECLINE et reprend le processus. Le message positif du serveur ne supprime donc pas l'épreuve du terrain local.

Ralph Droms est l'auteur de cette RFC. Sa notice IETF précise qu'il a organisé, en 1989, le groupe de travail qui a conçu DHCP. On peut lui attribuer la formalisation de ce dialogue dynamique, de ses états et de ses échéances. Il serait en revanche excessif de le présenter comme l'auteur unique de toutes les extensions, mises en œuvre et pratiques accumulées depuis.

Une autorité mesurée par une horloge

Le client peut suggérer une adresse ou une durée ; le serveur n'est pas tenu d'accepter. Le DHCPACK indique la configuration que sa politique consent effectivement. L'option de durée transforme cette décision en intervalle exploitable plutôt qu'en possession sans terme.

À T1, normalement placé à la moitié du bail, le client passe en RENEWING et sollicite directement le serveur d'origine. Sans succès, T2 survient normalement aux sept huitièmes : l'état REBINDING permet de demander une prolongation à tout serveur capable de répondre. Ces valeurs sont relatives à la durée et peuvent être remplacées par celles que communique le serveur.

L'expiration constitue la limite ferme. Si aucun DHCPACK n'a prolongé le bail, la RFC impose l'arrêt immédiat du traitement réseau avec cette adresse, son abandon et un retour à INIT. Le pool peut ensuite la confier à un autre client. Un protocole qui définit explicitement la fin de l'usage autorisé ne crée pas un droit permanent.

Un bail infini ne devient pas un acte de propriété

La RFC 2132 réserve la valeur composée uniquement de bits à un pour un bail infini. Un tel choix change beaucoup l'exploitation : continuité accrue, moins de renouvellements et apparence de stabilité durable. Pendant un bail valide, l'autorité du serveur est également substantielle ; le DHCPACK n'est pas un simple avis consultatif.

« Infini » décrit pourtant une échéance, non un statut juridique ou une identité. La valeur n'authentifie pas la personne devant le terminal, ne produit aucun droit opposable à d'autres réseaux et n'empêche pas l'administrateur de transformer l'infrastructure. Confondre durée et propriété ajoute au protocole des affirmations absentes de ses champs.

La RFC 5227 conserve une autre limite : avant d'utiliser une adresse IPv4, l'hôte la sonde et doit réagir à un conflit. Cette détection ne remplace pas le serveur DHCP, mais rappelle que la base de baux n'est pas une vision infaillible du support. Autorisation du plan de contrôle et disponibilité observée sont deux éléments qui se complètent.

Le DHCPACK qui n'attribue rien

DHCPINFORM fournit le contre-exemple le plus net. Un client déjà configuré par un autre moyen peut demander des paramètres locaux supplémentaires. Le serveur répond alors par DHCPACK, mais la RFC 2131 lui interdit d'allouer une adresse dans cet échange, de rechercher une liaison, de remplir yiaddr ou d'ajouter une durée de bail.

Le même type de message accompagne donc deux actes différents. Dans la machine d'états d'attribution, il peut engager une liaison. Après DHCPINFORM, il livre seulement de la configuration. Un inventaire qui transforme chaque DHCPACK observé en preuve d'attribution produit de faux historiques avec une règle pourtant séduisante.

La RFC 6842 resserre de son côté l'association des messages en demandant, dans les cas prévus, le renvoi de l'identifiant client dans DHCPOFFER et DHCPACK. Cette correspondance est précieuse. Elle n'authentifie pas une personne et ne transforme pas l'identifiant technique en titre sur l'adresse.

L'autorité de la base de baux

La RFC 4388 rend la perspective du serveur visible grâce à Leasequery. Une adresse peut être déclarée ACTIVE, UNASSIGNED ou UNKNOWN ; pour un bail actif, la durée restante peut être fournie. La requête consulte un état sans modifier la liaison. La réponse fait autorité pour la base de ce serveur, pas pour la totalité des paquets et appareils réellement présents sur le segment.

Il faut donc séparer attribution d'adresse et attribution d'activité. Un journal de bail peut établir qu'un service a autorisé un identifiant client à utiliser une adresse pendant un intervalle. Seul, il ne démontre ni l'identité humaine de l'utilisateur, ni l'origine de tous les paquets, ni la validité de la même conclusion avant ou après cet intervalle.

Cette précision ne dévalorise pas DHCP comme source. Elle permet de combiner correctement historique des baux, identifiants, données de relais, observations de couche liaison, détections de conflit et horloges synchronisées. La faute serait de demander à l'acquittement une réponse que son périmètre ne contient pas.

Sources