3. Le protocole client-serveur (The Client-Server Protocol)
DHCP utilise le format de message BOOTP défini dans la RFC 951, et donné dans le tableau 1 et la figure 1. Le champ 'op' de chaque message DHCP envoyé d'un client à un serveur contient BOOTREQUEST. BOOTREPLY est utilisé dans le champ 'op' de chaque message DHCP envoyé d'un serveur à un client.
Les quatre premiers octets du champ 'options' du message DHCP contiennent les valeurs (décimales) 99, 130, 83 et 99, respectivement (c'est le même magic cookie que celui défini dans la RFC 1497 [17]). Le reste du champ 'options' consiste en une liste de paramètres balisés appelés "options". Toutes les "extensions fournisseur" listées dans la RFC 1497 sont également des options DHCP. La RFC 1533 donne l'ensemble complet des options définies pour être utilisées avec DHCP.
Plusieurs options ont été définies jusqu'à présent. Une option particulière - l'option "type de message DHCP (DHCP Message Type)" - doit être incluse dans chaque message DHCP. Cette option définit le "type" du message DHCP. Des options supplémentaires peuvent être autorisées, requises ou non autorisées, selon le type de message DHCP.
Tout au long de ce document, les messages DHCP qui incluent une option 'type de message DHCP' seront désignés par le type du message ; par exemple, un message DHCP avec une option 'type de message DHCP' de type 1 sera appelé message "DHCPDISCOVER".
3.1 Interaction client-serveur - allocation d'une adresse réseau (Client-server interaction - allocating a network address)
Le résumé suivant de l'échange de protocole entre clients et serveurs fait référence aux messages DHCP décrits dans le tableau 2. Le diagramme de chronologie de la figure 3 montre les relations temporelles dans une interaction client-serveur typique. Si le client connaît déjà son adresse, certaines de ces étapes peuvent être omises ; cette interaction abrégée est décrite dans la section 3.2.
1. Le client diffuse un message DHCPDISCOVER sur son sous-réseau physique local. Le message DHCPDISCOVER PEUT inclure des options qui suggèrent des valeurs pour l'adresse réseau et la durée du bail. Les agents relais BOOTP peuvent transmettre le message aux serveurs DHCP qui ne sont pas sur le même sous-réseau physique.
2. Chaque serveur peut répondre avec un message DHCPOFFER qui inclut une adresse réseau disponible dans le champ 'yiaddr' (et d'autres paramètres de configuration dans les options DHCP). Les serveurs n'ont pas besoin de réserver l'adresse réseau offerte, bien que le protocole fonctionnera plus efficacement si le serveur évite d'allouer l'adresse réseau offerte à un autre client. Lors de l'allocation d'une nouvelle adresse, les serveurs DEVRAIENT vérifier que l'adresse réseau offerte n'est pas déjà utilisée ; par exemple, le serveur peut sonder l'adresse offerte avec une requête d'écho ICMP. Les serveurs DEVRAIENT être implémentés de sorte que les administrateurs réseau PUISSENT choisir de désactiver le sondage des adresses nouvellement allouées. Le serveur transmet le message DHCPOFFER au client, en utilisant l'agent relais BOOTP si nécessaire.
Messages DHCP (DHCP messages)
| Message | Utilisation |
|---|---|
| DHCPDISCOVER | Diffusion du client pour localiser les serveurs disponibles. |
| DHCPOFFER | Du serveur au client en réponse à DHCPDISCOVER avec offre de paramètres de configuration. |
| DHCPREQUEST | Message du client aux serveurs soit (a) demandant les paramètres offerts par un serveur et refusant implicitement les offres de tous les autres, (b) confirmant l'exactitude d'une adresse précédemment allouée après, par exemple, un redémarrage du système, ou (c) prolongeant le bail sur une adresse réseau particulière. |
| DHCPACK | Du serveur au client avec des paramètres de configuration, y compris l'adresse réseau engagée. |
| DHCPNAK | Du serveur au client indiquant que la notion d'adresse réseau du client est incorrecte (par exemple, le client s'est déplacé vers un nouveau sous-réseau) ou que le bail du client a expiré. |
| DHCPDECLINE | Du client au serveur indiquant que l'adresse réseau est déjà utilisée. |
| DHCPRELEASE | Du client au serveur abandonnant l'adresse réseau et annulant le bail restant. |
| DHCPINFORM | Du client au serveur, demandant uniquement les paramètres de configuration locaux ; le client a déjà une adresse réseau configurée en externe. |
Tableau 2 : Messages DHCP
Diagramme de chronologie (Timeline diagram)
Server Client Server
(not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/ |
| \________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\____________ |
|/ DHCPREQUEST | DHCPREQUEST\ |
| | |
| | Commits configuration
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\ ____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
Figure 3 : Diagramme de chronologie des messages échangés entre
le client et les serveurs DHCP lors de l'allocation
d'une nouvelle adresse réseau
3. Le client reçoit un ou plusieurs messages DHCPOFFER d'un ou plusieurs serveurs. Le client peut choisir d'attendre plusieurs réponses. Le client choisit un serveur auprès duquel demander des paramètres de configuration, en fonction des paramètres de configuration offerts dans les messages DHCPOFFER. Le client diffuse un message DHCPREQUEST qui DOIT inclure l'option 'identificateur de serveur' pour indiquer quel serveur il a sélectionné, et qui PEUT inclure d'autres options spécifiant les valeurs de configuration souhaitées. L'option 'adresse IP demandée' DOIT être définie sur la valeur de 'yiaddr' dans le message DHCPOFFER du serveur. Ce message DHCPREQUEST est diffusé et relayé via les agents relais DHCP/BOOTP. Pour aider à garantir que tout agent relais BOOTP transfère le message DHCPREQUEST au même ensemble de serveurs DHCP qui ont reçu le message DHCPDISCOVER d'origine, le message DHCPREQUEST DOIT utiliser la même valeur dans le champ 'secs' de l'en-tête du message DHCP et être envoyé à la même adresse de diffusion IP que le message DHCPDISCOVER d'origine. Le client expire et retransmet le message DHCPDISCOVER si le client ne reçoit aucun message DHCPOFFER.
4. Les serveurs reçoivent la diffusion DHCPREQUEST du client. Les serveurs non sélectionnés par le message DHCPREQUEST utilisent le message comme notification que le client a refusé l'offre de ce serveur. Le serveur sélectionné dans le message DHCPREQUEST engage la liaison du client dans un stockage persistant et répond avec un message DHCPACK contenant les paramètres de configuration pour le client demandeur. La combinaison de 'identificateur de client' ou 'chaddr' et de l'adresse réseau attribuée constitue un identifiant unique pour le bail du client et est utilisée à la fois par le client et le serveur pour identifier un bail référencé dans tout message DHCP. Tous les paramètres de configuration dans le message DHCPACK NE DEVRAIENT PAS entrer en conflit avec ceux du message DHCPOFFER antérieur auquel le client répond. Le serveur NE DEVRAIT PAS vérifier l'adresse réseau offerte à ce stade. Le champ 'yiaddr' dans les messages DHCPACK est rempli avec l'adresse réseau sélectionnée.
Si le serveur sélectionné est incapable de satisfaire le message DHCPREQUEST (par exemple, l'adresse réseau demandée a été allouée), le serveur DEVRAIT répondre avec un message DHCPNAK.
Un serveur PEUT choisir de marquer les adresses offertes aux clients dans les messages DHCPOFFER comme non disponibles. Le serveur DEVRAIT marquer une adresse offerte à un client dans un message DHCPOFFER comme disponible si le serveur ne reçoit aucun message DHCPREQUEST de ce client.
5. Le client reçoit le message DHCPACK avec les paramètres de configuration. Le client DEVRAIT effectuer une vérification finale des paramètres (par exemple, ARP pour l'adresse réseau allouée), et note la durée du bail spécifiée dans le message DHCPACK. À ce stade, le client est configuré. Si le client détecte que l'adresse est déjà utilisée (par exemple, par l'utilisation d'ARP), le client DOIT envoyer un message DHCPDECLINE au serveur et redémarre le processus de configuration. Le client DEVRAIT attendre un minimum de dix secondes avant de redémarrer le processus de configuration pour éviter un trafic réseau excessif en cas de boucle.
Si le client reçoit un message DHCPNAK, le client redémarre le processus de configuration.
Si le client ne reçoit ni un message DHCPACK ni un message DHCPNAK, le client expire et retransmet le message DHCPREQUEST, selon l'algorithme de retransmission de la section 4.1. Le client DEVRAIT choisir de retransmettre le DHCPREQUEST suffisamment de fois pour donner une probabilité adéquate de contacter le serveur sans faire attendre excessivement longtemps le client (et l'utilisateur de ce client) avant d'abandonner ; par exemple, un client retransmettant comme décrit dans la section 4.1 pourrait retransmettre le message DHCPREQUEST quatre fois, pour un délai total de 60 secondes, avant de redémarrer la procédure d'initialisation. Si le client ne reçoit ni un message DHCPACK ni un message DHCPNAK après avoir employé l'algorithme de retransmission, le client revient à l'état INIT et redémarre le processus d'initialisation. Le client DEVRAIT notifier l'utilisateur que le processus d'initialisation a échoué et redémarre.
6. Le client peut choisir d'abandonner son bail sur une adresse réseau en envoyant un message DHCPRELEASE au serveur. Le client identifie le bail à libérer avec son 'identificateur de client' ou 'chaddr' et l'adresse réseau dans le message DHCPRELEASE. Si le client a utilisé un 'identificateur de client' lorsqu'il a obtenu le bail, il DOIT utiliser le même 'identificateur de client' dans le message DHCPRELEASE.
3.2 Interaction client-serveur - réutilisation d'une adresse réseau précédemment allouée (Client-server interaction - reusing a previously allocated network address)
Si un client se souvient et souhaite réutiliser une adresse réseau précédemment allouée, un client peut choisir d'omettre certaines des étapes décrites dans la section précédente. Le diagramme de chronologie de la figure 4 montre les relations temporelles dans une interaction client-serveur typique pour un client réutilisant une adresse réseau précédemment allouée.
1. Le client diffuse un message DHCPREQUEST sur son sous-réseau local. Le message inclut l'adresse réseau du client dans l'option 'adresse IP demandée'. Comme le client n'a pas encore reçu son adresse réseau, il NE DOIT PAS remplir le champ 'ciaddr'. Les agents relais BOOTP transmettent le message aux serveurs DHCP qui ne sont pas sur le même sous-réseau. Si le client a utilisé un 'identificateur de client' pour obtenir son adresse, le client DOIT utiliser le même 'identificateur de client' dans le message DHCPREQUEST.
2. Les serveurs connaissant les paramètres de configuration du client répondent avec un message DHCPACK au client. Les serveurs NE DEVRAIENT PAS vérifier que l'adresse réseau du client est déjà utilisée ; le client peut répondre aux messages de requête d'écho ICMP à ce stade.
Server Client Server
v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| _________ __/ | \__________ |
| /DHCPREQUEST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \ _______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v v
Figure 4 : Diagramme de chronologie des messages échangés entre
le client et les serveurs DHCP lors de la réutilisation
d'une adresse réseau précédemment allouée
Si la requête du client est invalide (par exemple, le client s'est déplacé vers un nouveau sous-réseau), les serveurs DEVRAIENT répondre au client avec un message DHCPNAK. Les serveurs NE DEVRAIENT PAS répondre si leurs informations ne sont pas garanties comme étant exactes. Par exemple, un serveur qui identifie une requête pour une liaison expirée appartenant à un autre serveur NE DEVRAIT PAS répondre avec un DHCPNAK à moins que les serveurs n'utilisent un mécanisme explicite pour maintenir la cohérence entre les serveurs.
Si 'giaddr' est 0x0 dans le message DHCPREQUEST, le client est sur le même sous-réseau que le serveur. Le serveur DOIT diffuser le message DHCPNAK à l'adresse de diffusion 0xffffffff parce que le client peut ne pas avoir une adresse réseau ou un masque de sous-réseau correct, et le client peut ne pas répondre aux requêtes ARP. Sinon, le serveur DOIT envoyer le message DHCPNAK à l'adresse IP de l'agent relais BOOTP, telle qu'enregistrée dans 'giaddr'. L'agent relais transmettra, à son tour, le message directement à l'adresse matérielle du client, de sorte que le DHCPNAK puisse être livré même si le client s'est déplacé vers un nouveau réseau.
3. Le client reçoit le message DHCPACK avec les paramètres de configuration. Le client effectue une vérification finale des paramètres (comme dans la section 3.1), et note la durée du bail spécifiée dans le message DHCPACK. Le bail spécifique est implicitement identifié par l''identificateur de client' ou 'chaddr' et l'adresse réseau. À ce stade, le client est configuré.
Si le client détecte que l'adresse IP dans le message DHCPACK est déjà utilisée, le client DOIT envoyer un message DHCPDECLINE au serveur et redémarre le processus de configuration en demandant une nouvelle adresse réseau. Cette action correspond au déplacement du client vers l'état INIT dans le diagramme d'état DHCP, qui est décrit dans la section 4.4.
Si le client reçoit un message DHCPNAK, il ne peut pas réutiliser son adresse réseau mémorisée. Il doit plutôt demander une nouvelle adresse en redémarrant le processus de configuration, cette fois en utilisant la procédure (non abrégée) décrite dans la section 3.1. Cette action correspond également au déplacement du client vers l'état INIT dans le diagramme d'état DHCP.
Si le client ne reçoit ni un message DHCPACK ni un message DHCPNAK, le client expire et retransmet le message DHCPREQUEST, selon l'algorithme de retransmission de la section 4.1. Le client DEVRAIT choisir de retransmettre le DHCPREQUEST suffisamment de fois pour donner une probabilité adéquate de contacter le serveur sans faire attendre excessivement longtemps le client (et l'utilisateur de ce client) avant d'abandonner ; par exemple, un client retransmettant comme décrit dans la section 4.1 pourrait retransmettre le message DHCPREQUEST quatre fois, pour un délai total de 60 secondes, avant de redémarrer la procédure d'initialisation. Si le client ne reçoit ni un message DHCPACK ni un message DHCPNAK après avoir employé l'algorithme de retransmission, le client PEUT choisir d'utiliser l'adresse réseau précédemment allouée et les paramètres de configuration pour le reste du bail non expiré. Cela correspond au déplacement vers l'état BOUND dans le diagramme de transition d'état du client montré dans la figure 5.
4. Le client peut choisir d'abandonner son bail sur une adresse réseau en envoyant un message DHCPRELEASE au serveur. Le client identifie le bail à libérer avec son 'identificateur de client' ou 'chaddr' et l'adresse réseau dans le message DHCPRELEASE.
Notez que dans ce cas, où le client conserve son adresse réseau localement, le client n'abandonnera normalement pas son bail lors d'un arrêt gracieux. Ce n'est que dans le cas où le client a explicitement besoin d'abandonner son bail, par exemple, le client est sur le point d'être déplacé vers un sous-réseau différent, que le client enverra un message DHCPRELEASE.
3.3 Interprétation et représentation des valeurs de temps (Interpretation and representation of time values)
Un client acquiert un bail pour une adresse réseau pendant une période fixe (qui peut être infinie). Tout au long du protocole, les temps doivent être représentés en unités de secondes. La valeur de temps 0xffffffff est réservée pour représenter "l'infini".
Comme les clients et les serveurs peuvent ne pas avoir d'horloges synchronisées, les temps sont représentés dans les messages DHCP comme des temps relatifs, à interpréter par rapport à l'horloge locale du client. La représentation des temps relatifs en unités de secondes dans un mot non signé de 32 bits donne une plage de temps relatifs de 0 à environ 100 ans, ce qui est suffisant pour les temps relatifs à mesurer en utilisant DHCP.
L'algorithme d'interprétation de la durée du bail donné dans le paragraphe précédent suppose que les horloges du client et du serveur sont stables l'une par rapport à l'autre. S'il y a une dérive entre les deux horloges, le serveur peut considérer le bail comme expiré avant que le client ne le fasse. Pour compenser, le serveur peut retourner une durée de bail plus courte au client que celle que le serveur engage dans sa base de données locale d'informations client.
3.4 Obtention de paramètres avec une adresse réseau configurée en externe (Obtaining parameters with externally configured network address)
Si un client a obtenu une adresse réseau par un autre moyen (par exemple, configuration manuelle), il peut utiliser un message de requête DHCPINFORM pour obtenir d'autres paramètres de configuration locaux. Les serveurs recevant un message DHCPINFORM construisent un message DHCPACK avec tous les paramètres de configuration locaux appropriés pour le client sans : allouer une nouvelle adresse, vérifier une liaison existante, remplir 'yiaddr' ou inclure des paramètres de temps de bail. Les serveurs DEVRAIENT envoyer en unicast la réponse DHCPACK à l'adresse donnée dans le champ 'ciaddr' du message DHCPINFORM.
Le serveur DEVRAIT vérifier la cohérence de l'adresse réseau dans un message DHCPINFORM, mais NE DOIT PAS vérifier l'existence d'un bail existant. Le serveur forme un message DHCPACK contenant les paramètres de configuration pour le client demandeur et envoie le message DHCPACK directement au client.
3.5 Paramètres du client dans DHCP (Client parameters in DHCP)
Tous les clients ne nécessitent pas l'initialisation de tous les paramètres listés dans l'Annexe A. Deux techniques sont utilisées pour réduire le nombre de paramètres transmis du serveur au client. Premièrement, la plupart des paramètres ont des valeurs par défaut définies dans les RFC sur les exigences des hôtes ; si le client ne reçoit aucun paramètre du serveur qui remplace les valeurs par défaut, un client utilise ces valeurs par défaut. Deuxièmement, dans son message DHCPDISCOVER ou DHCPREQUEST initial, un client peut fournir au serveur une liste de paramètres spécifiques auxquels le client s'intéresse. Si le client inclut une liste de paramètres dans un message DHCPDISCOVER, il DOIT inclure cette liste dans tous les messages DHCPREQUEST suivants.
Le client DEVRAIT inclure l'option 'taille maximale de message DHCP' pour informer le serveur de la taille que le serveur peut donner à ses messages DHCP. Les paramètres renvoyés à un client peuvent encore dépasser l'espace alloué aux options dans un message DHCP. Dans ce cas, deux drapeaux d'option supplémentaires (qui doivent apparaître dans le champ 'options' du message) indiquent que les champs 'file' et 'sname' doivent être utilisés pour les options.
Le client peut informer le serveur des paramètres de configuration auxquels le client s'intéresse en incluant l'option 'liste de demande de paramètres (Parameter Request List)'. La partie données de cette option liste explicitement les options demandées par numéro de balise.
De plus, le client peut suggérer des valeurs pour l'adresse réseau et le temps de bail dans le message DHCPDISCOVER. Le client peut inclure l'option 'adresse IP demandée' pour suggérer qu'une adresse IP particulière soit attribuée, et peut inclure l'option 'temps de bail d'adresse IP' pour suggérer le temps de bail qu'il souhaite. D'autres options représentant des "indices" sur les paramètres de configuration sont autorisées dans un message DHCPDISCOVER ou DHCPREQUEST. Cependant, des options supplémentaires peuvent être ignorées par les serveurs, et plusieurs serveurs peuvent ne pas retourner les mêmes valeurs pour certaines options. L'option 'adresse IP demandée' ne doit être remplie que dans un message DHCPREQUEST lorsque le client vérifie des paramètres réseau précédemment alloués et mis en cache. Le client ne remplit le champ 'ciaddr' que lorsqu'il est correctement configuré avec une adresse IP dans l'état BOUND, RENEWING ou REBINDING.
Si un serveur reçoit un message DHCPREQUEST avec une 'adresse IP demandée' invalide, le serveur DEVRAIT répondre au client avec un message DHCPNAK et peut choisir de signaler le problème à l'administrateur système. Le serveur peut inclure un message d'erreur dans l'option 'message'.
3.6 Utilisation de DHCP dans les clients avec plusieurs interfaces (Use of DHCP in clients with multiple interfaces)
Un client avec plusieurs interfaces réseau doit utiliser DHCP via chaque interface indépendamment pour obtenir les paramètres d'informations de configuration pour ces interfaces séparées.
3.7 Quand les clients devraient utiliser DHCP (When clients should use DHCP)
Un client DEVRAIT utiliser DHCP pour réacquérir ou vérifier son adresse IP et ses paramètres réseau chaque fois que les paramètres réseau locaux peuvent avoir changé ; par exemple, au démarrage du système ou après une déconnexion du réseau local, car la configuration du réseau local peut changer sans que le client ou l'utilisateur le sache.
Si un client a connaissance d'une adresse réseau précédente et est incapable de contacter un serveur DHCP local, le client peut continuer à utiliser l'adresse réseau précédente jusqu'à ce que le bail pour cette adresse expire. Si le bail expire avant que le client ne puisse contacter un serveur DHCP, le client doit immédiatement cesser d'utiliser l'adresse réseau précédente et peut informer les utilisateurs locaux du problème.