Résumé

  • T1 ouvre l’état RENEWING auprès du serveur qui a accordé le bail ; T2 ouvre REBINDING par diffusion afin qu’un autre serveur administrativement compétent puisse répondre ; l’échéance interdit toute continuation sans DHCPACK.
  • La réassociation protège la disponibilité sans transformer la simple réception d’une diffusion en autorité. Le bail reste une décision locale, limitée dans le temps, et non un titre permanent sur l’adresse.

Un silence n’était ni une révocation ni une prolongation

Un poste portable conserve son adresse, ses routes et plusieurs sessions ouvertes. Le serveur DHCP qui avait répondu le matin ne répond plus. Du point de vue des applications, rien n’a encore changé.

Le client, lui, ne voit pas un seul compte à rebours mais trois seuils. À T1, il se tourne vers le serveur bailleur. À T2, il diffuse sa demande pour atteindre une autorité de secours. À l’expiration, il doit cesser d’utiliser l’adresse si aucun DHCPACK n’a renouvelé le bail.

Cette progression donne au silence un sens précis. Avant l’échéance, il autorise des tentatives de continuité. Il ne vaut jamais consentement tacite à une utilisation indéfinie.

La réutilisation exigeait un droit révocable

RFC 1541, publié en octobre 1993, ajoutait à l’héritage de BOOTP une allocation dynamique. Une adresse pouvait être attribuée pour une durée limitée, puis revenir au parc afin de servir un autre client.

Le RFC nomme binding l’ensemble de paramètres, comprenant au moins l’adresse IP, associé à un client et géré par les serveurs DHCP. La formulation est importante : le client ne reçoit pas l’adresse comme une propriété. Il reçoit une configuration dont la validité dépend d’un service et d’une politique administrative.

RFC 2131 a conservé en 1997 trois modèles. L’allocation automatique peut être permanente ; l’allocation manuelle transporte un choix de l’administrateur ; l’allocation dynamique, objet de cet article, vit par son bail et ses transitions de réacquisition.

Durée, renouvellement et réassociation ne formaient pas la même horloge

RFC 2132 réserve l’option 51 à la durée du bail, l’option 58 à T1 et l’option 59 à T2. Ces valeurs expriment des intervalles en secondes depuis l’attribution, pas des dates civiles.

Si le serveur ne transmet pas de valeurs valides, RFC 2131 place par défaut T1 à la moitié du bail et T2 aux sept huitièmes. Une légère variation aléatoire évite qu’une population entière ne renouvelle en cadence. Ces fractions sont des replis ; elles ne décrivent ni un réglage universel ni une pratique présente chez un fournisseur.

L’ordre réserve du temps à trois stratégies. D’abord préserver la relation avec le serveur qui connaît le bail. Ensuite chercher une continuité plus large. Enfin retirer l’adresse lorsque toute autorité temporelle a disparu.

T1 respectait le détenteur de l’état initial

À T1, le client BOUND passe en RENEWING. Il adresse DHCPREQUEST au serveur qui lui a accordé le bail, si son adresse est connue. Il renseigne ciaddr avec l’adresse actuelle et ne recommence pas une sélection d’offres.

Cette préférence n’est pas décorative. Le serveur bailleur connaît le lien qu’il a établi, la politique qui l’a permis et les paramètres qui peuvent changer avec une prolongation. Il peut étendre le bail, renvoyer une configuration modifiée ou choisir de ne pas prolonger selon la politique locale.

L’absence de réponse n’annule pas aussitôt le bail existant. Le client peut retransmettre pendant le temps restant. Le protocole sépare ainsi une panne de contrôle d’une révocation : les données ne s’arrêtent pas à la première perte, mais la panne ne crée pas non plus un droit nouveau.

T2 élargissait l’audience, pas le pouvoir

Sans DHCPACK à T2, le client entre en REBINDING. Il diffuse DHCPREQUEST, conserve son adresse dans ciaddr et omet l’identifiant du serveur. Un autre serveur peut alors entendre ce que le serveur initial n’entend plus.

RFC 2131 ajoute une limite décisive : ce serveur ne peut prolonger le bail que s’il possède l’autorité administrative locale nécessaire. La réassociation suppose des serveurs multiples capables de maintenir une vision cohérente des baux.

La diffusion résout un problème de découverte. Elle ne délègue rien. Un processus qui reçoit le paquet mais ignore l’état partagé, le parc d’adresses ou la politique du site n’acquiert aucun droit de répondre par sa seule présence sur le réseau.

T2 rend donc visible une dépendance opérationnelle. La haute disponibilité ne tient pas seulement au nombre de serveurs ; elle tient à leur accord sur ce qui a déjà été promis.

ACK, NAK et absence de réponse avaient trois effets distincts

Un DHCPACK reçu pendant RENEWING ou REBINDING renouvelle la configuration. Le client enregistre la nouvelle durée et redémarre T1 et T2. Le message peut aussi modifier d’autres paramètres : un renouvellement n’est pas uniquement une rallonge de temps.

DHCPNAK retire la base de la configuration courante. Le client doit cesser de l’utiliser et retourner vers l’initialisation. Continuer après un NAK reviendrait à opposer une mémoire locale à l’autorité du réseau.

Le silence conserve le bail tant que son temps n’est pas écoulé. Il déclenche des retransmissions espacées selon le temps restant. Mais si l’expiration arrive avant ACK, RFC 2131 ordonne le retour à INIT et l’arrêt immédiat des autres traitements réseau.

Une passerelle peut encore acheminer un paquet, un voisin peut répondre à l’ARP et un commutateur peut garder son port. Ce sont des observations de fonctionnement, pas une prorogation.

Une adresse mémorisée devait être confirmée

Après un redémarrage, le client peut se souvenir de son ancienne adresse. L’état INIT-REBOOT lui permet de demander sa confirmation. La demande est diffusée parce que le client ne sait pas encore si le même réseau ou le même serveur demeure compétent.

DHCPACK confirme ; DHCPNAK refuse. Si aucun serveur n’est joignable, l’ancienne configuration ne peut être utilisée que jusqu’à la fin du bail encore valable. La mémoire accélère la reprise, mais elle ne produit pas sa propre autorité.

Le serveur pouvait avancer l’examen, sous contrôle

RFC 3203 a ensuite défini FORCERENEW. Un serveur peut envoyer ce message en unicast afin que le client rejoigne RENEW avant T1 et effectue une demande DHCP ordinaire.

FORCERENEW ne réécrit pas directement l’adresse. Si le serveur veut la retirer, il répond au DHCPREQUEST par DHCPNAK, puis le client repart en découverte. Le chemin conserve les conséquences explicites du state machine.

Un faux FORCERENEW permettrait de provoquer des interruptions répétées. Le RFC exige donc l’authentification décrite par RFC 3118 et avertit qu’une reconfiguration peut couper des sessions actives. Le pouvoir d’avancer le renouvellement est lui aussi borné.

Le bail ne prouvait pas que l’adresse était libre sur le lien

Une allocation correcte dans le service DHCP peut rencontrer une réalité locale contradictoire. RFC 5227 impose de sonder une adresse IPv4 avant de commencer à l’utiliser. Si le client découvre un conflit après une offre DHCP, il envoie DHCPDECLINE.

Les deux preuves ne répondent pas à la même question. Le bail dit quelle configuration le service géré autorise pendant une période. La sonde ARP demande si un autre hôte revendique déjà cette adresse sur le lien. Un DHCPACK ne prouve donc ni l’identité de l’utilisateur, ni une propriété juridique, ni l’absence de collision, ni la disponibilité d’un service de bout en bout.

Sources et limites de preuve

Les faits historiques et techniques sont bornés par les documents officiels suivants :

Ils définissent DHCPv4 et quelques extensions. Ils ne prouvent aucun taux de déploiement actuel, aucun comportement de produit nommé et aucune architecture particulière de réplication ou de secours. DHCPv6 relève d’un autre protocole.