4. Spécification du protocole client-serveur DHCP (Specification of the DHCP Client-Server Protocol)
Dans cette section, nous supposons qu'un serveur DHCP dispose d'un bloc d'adresses réseau à partir duquel il peut satisfaire les demandes de nouvelles adresses. Chaque serveur maintient également une base de données des adresses allouées et des baux dans un stockage permanent local.
4.1 Construction et envoi de messages DHCP (Constructing and sending DHCP messages)
Les clients et serveurs DHCP construisent tous deux des messages DHCP en remplissant les champs de la section de format fixe du message et en ajoutant des éléments de données balisés dans la zone d'options de longueur variable. La zone d'options comprend d'abord un 'magic cookie' de quatre octets (décrit dans la section 3), suivi des options. La dernière option doit toujours être l'option 'end'.
DHCP utilise UDP comme protocole de transport. Les messages DHCP d'un client à un serveur sont envoyés au port 'serveur DHCP' (67), et les messages DHCP d'un serveur à un client sont envoyés au port 'client DHCP' (68). Un serveur avec plusieurs adresses réseau (par exemple, un hôte multiréseau) peut utiliser n'importe laquelle de ses adresses réseau dans les messages DHCP sortants.
Le champ 'identificateur de serveur' est utilisé à la fois pour identifier un serveur DHCP dans un message DHCP et comme adresse de destination des clients vers les serveurs. Un serveur avec plusieurs adresses réseau doit être prêt à accepter n'importe laquelle de ses adresses réseau comme identifiant ce serveur dans un message DHCP. Pour s'adapter à une connectivité réseau potentiellement incomplète, un serveur doit choisir une adresse comme 'identificateur de serveur' qui, au meilleur de la connaissance du serveur, est accessible depuis le client. Par exemple, si le serveur DHCP et le client DHCP sont connectés au même sous-réseau (c'est-à-dire que le champ 'giaddr' dans le message du client est zéro), le serveur devrait sélectionner l'adresse IP que le serveur utilise pour la communication sur ce sous-réseau comme 'identificateur de serveur'. Si le serveur utilise plusieurs adresses IP sur ce sous-réseau, n'importe laquelle de ces adresses peut être utilisée. Si le serveur a reçu un message via un agent relais DHCP, le serveur devrait choisir une adresse de l'interface sur laquelle le message a été reçu comme 'identificateur de serveur' (sauf si le serveur dispose d'autres informations meilleures sur lesquelles fonder son choix). Les clients DHCP doivent utiliser l'adresse IP fournie dans l'option 'identificateur de serveur' pour toute demande unicast au serveur DHCP.
Les messages DHCP diffusés par un client avant que ce client n'obtienne son adresse IP doivent avoir le champ d'adresse source dans l'en-tête IP défini à 0.
Si le champ 'giaddr' dans un message DHCP d'un client est non nul, le serveur envoie tous les messages de retour au port 'serveur DHCP' sur l'agent relais BOOTP dont l'adresse apparaît dans 'giaddr'. Si le champ 'giaddr' est zéro et le champ 'ciaddr' est non nul, alors le serveur envoie en unicast les messages DHCPOFFER et DHCPACK à l'adresse dans 'ciaddr'. Si 'giaddr' est zéro et 'ciaddr' est zéro, et que le bit de diffusion est défini, alors le serveur diffuse les messages DHCPOFFER et DHCPACK à 0xffffffff. Si le bit de diffusion n'est pas défini et 'giaddr' est zéro et 'ciaddr' est zéro, alors le serveur envoie en unicast les messages DHCPOFFER et DHCPACK à l'adresse matérielle du client et à l'adresse 'yiaddr'. Dans tous les cas, lorsque 'giaddr' est zéro, le serveur diffuse tous les messages DHCPNAK à 0xffffffff.
Si les options d'un message DHCP s'étendent dans les champs 'sname' et 'file', l'option 'option overload' DOIT apparaître dans le champ 'options', avec une valeur 1, 2 ou 3, comme spécifié dans la RFC 1533. Si l'option 'option overload' est présente dans le champ 'options', les options dans le champ 'options' DOIVENT être terminées par une option 'end', et PEUVENT contenir une ou plusieurs options 'pad' pour remplir le champ options. Les options dans les champs 'sname' et 'file' (si utilisées comme indiqué par l'option 'option overload') DOIVENT commencer par le premier octet du champ, DOIVENT être terminées par une option 'end', et DOIVENT être suivies d'options 'pad' pour remplir le reste du champ. Toute option individuelle dans les champs 'options', 'sname' et 'file' DOIT être entièrement contenue dans ce champ. Les options dans le champ 'options' DOIVENT être interprétées en premier, afin que toute option 'option overload' puisse être interprétée. Le champ 'file' DOIT être interprété ensuite (si l'option 'option overload' indique que le champ 'file' contient des options DHCP), suivi du champ 'sname'.
Les valeurs à passer dans une balise 'option' peuvent être trop longues pour tenir dans les 255 octets disponibles pour une seule option (par exemple, une liste de routeurs dans une option 'router' [21]). Les options ne peuvent apparaître qu'une seule fois, sauf indication contraire dans le document des options. Le client concatène les valeurs de plusieurs instances de la même option en une seule liste de paramètres pour la configuration.
Les clients DHCP sont responsables de toutes les retransmissions de messages. Le client DOIT adopter une stratégie de retransmission qui incorpore un algorithme de backoff exponentiel randomisé pour déterminer le délai entre les retransmissions. Le délai entre les retransmissions DEVRAIT être choisi pour permettre un temps suffisant pour que les réponses du serveur soient livrées en fonction des caractéristiques de l'internet entre le client et le serveur. Par exemple, dans un internet Ethernet 10Mb/sec, le délai avant la première retransmission DEVRAIT être de 4 secondes randomisé par la valeur d'un nombre aléatoire uniforme choisi dans la plage -1 à +1. Les clients avec des horloges qui fournissent une granularité de résolution inférieure à une seconde peuvent choisir une valeur de randomisation non entière. Le délai avant la prochaine retransmission DEVRAIT être de 8 secondes randomisé par la valeur d'un nombre uniforme choisi dans la plage -1 à +1. Le délai de retransmission DEVRAIT être doublé avec les retransmissions ultérieures jusqu'à un maximum de 64 secondes. Le client PEUT fournir une indication des tentatives de retransmission à l'utilisateur comme indication de la progression du processus de configuration.
Le champ 'xid' est utilisé par le client pour faire correspondre les messages DHCP entrants avec les demandes en attente. Un client DHCP DOIT choisir les 'xid' de manière à minimiser les chances d'utiliser un 'xid' identique à celui utilisé par un autre client. Par exemple, un client peut choisir un 'xid' initial aléatoire différent chaque fois que le client est redémarré, puis utiliser des 'xid' séquentiels jusqu'au prochain redémarrage. Le choix d'un nouveau 'xid' pour chaque retransmission est une décision d'implémentation. Un client peut choisir de réutiliser le même 'xid' ou de choisir un nouveau 'xid' pour chaque message retransmis.
Normalement, les serveurs DHCP et les agents relais BOOTP tentent de livrer les messages DHCPOFFER, DHCPACK et DHCPNAK directement au client en utilisant la livraison unicast. L'adresse de destination IP (dans l'en-tête IP) est définie sur l'adresse 'yiaddr' DHCP et l'adresse de destination de la couche liaison est définie sur l'adresse 'chaddr' DHCP. Malheureusement, certaines implémentations de client sont incapables de recevoir de tels datagrammes IP unicast jusqu'à ce que l'implémentation ait été configurée avec une adresse IP valide (conduisant à un blocage dans lequel l'adresse IP du client ne peut pas être livrée jusqu'à ce que le client ait été configuré avec une adresse IP).
Un client qui ne peut pas recevoir de datagrammes IP unicast jusqu'à ce que son logiciel de protocole ait été configuré avec une adresse IP DEVRAIT définir le bit BROADCAST dans le champ 'flags' à 1 dans tous les messages DHCPDISCOVER ou DHCPREQUEST que ce client envoie. Le bit BROADCAST fournira un indice aux serveurs DHCP et aux agents relais BOOTP pour diffuser tous les messages au client sur le sous-réseau du client. Un client qui peut recevoir des datagrammes IP unicast avant que son logiciel de protocole ait été configuré DEVRAIT effacer le bit BROADCAST à 0. Le document de clarifications BOOTP discute des ramifications de l'utilisation du bit BROADCAST [21].
Un serveur ou un agent relais envoyant ou relayant un message DHCP directement à un client DHCP (c'est-à-dire, pas à un agent relais spécifié dans le champ 'giaddr') DEVRAIT examiner le bit BROADCAST dans le champ 'flags'. Si ce bit est défini à 1, le message DHCP DEVRAIT être envoyé comme une diffusion IP en utilisant une adresse de diffusion IP (de préférence 0xffffffff) comme adresse de destination IP et l'adresse de diffusion de la couche liaison comme adresse de destination de la couche liaison. Si le bit BROADCAST est effacé à 0, le message DEVRAIT être envoyé comme un unicast IP à l'adresse IP spécifiée dans le champ 'yiaddr' et à l'adresse de la couche liaison spécifiée dans le champ 'chaddr'. Si l'unicast n'est pas possible, le message PEUT être envoyé comme une diffusion IP en utilisant une adresse de diffusion IP (de préférence 0xffffffff) comme adresse de destination IP et l'adresse de diffusion de la couche liaison comme adresse de destination de la couche liaison.
4.2 Contrôles administratifs du serveur DHCP (DHCP server administrative controls)
Les serveurs DHCP ne sont pas tenus de répondre à chaque message DHCPDISCOVER et DHCPREQUEST qu'ils reçoivent. Par exemple, un administrateur réseau, pour conserver un contrôle strict sur les clients attachés au réseau, peut choisir de configurer les serveurs DHCP pour répondre uniquement aux clients qui ont été préalablement enregistrés par un mécanisme externe. La spécification DHCP décrit uniquement les interactions entre les clients et les serveurs lorsque les clients et les serveurs choisissent d'interagir ; il est au-delà de la portée de la spécification DHCP de décrire tous les contrôles administratifs que les administrateurs système pourraient vouloir utiliser. Des implémentations spécifiques de serveur DHCP peuvent incorporer tous les contrôles ou politiques souhaités par un administrateur réseau.
Dans certains environnements, les serveurs DHCP devront considérer la valeur des options de classe de fournisseur incluses dans les messages DHCPDISCOVER ou DHCPREQUEST lors de la détermination des paramètres corrects pour un client particulier.
Un serveur DHCP doit utiliser un identifiant unique pour associer un client à son bail. Le client PEUT choisir de fournir explicitement l'identifiant via l'option 'identificateur de client'. Si le client fournit un 'identificateur de client', le client DOIT utiliser le même 'identificateur de client' dans tous les messages ultérieurs, et le serveur DOIT utiliser cet identifiant pour identifier le client. Si le client ne fournit pas d'option 'identificateur de client', le serveur DOIT utiliser le contenu du champ 'chaddr' pour identifier le client. Il est crucial pour le bon fonctionnement de DHCP que le client utilise un identifiant unique dans le sous-réseau auquel le client est attaché dans l'option 'identificateur de client'. L'utilisation de 'chaddr' comme identifiant unique du client peut entraîner des résultats inattendus, car cet identifiant peut être associé à une interface matérielle qui pourrait être déplacée vers un nouveau client. Certains sites peuvent choisir d'utiliser un numéro de série de fabricant comme 'identificateur de client', pour éviter des changements inattendus dans l'adresse réseau d'un client dus au transfert d'interfaces matérielles entre ordinateurs. Les sites peuvent également choisir d'utiliser un nom DNS comme 'identificateur de client', faisant en sorte que l'adresse réseau d'un client soit associée au nom DNS plutôt qu'à une boîte matérielle spécifique.
Les clients DHCP sont libres d'utiliser n'importe quelle stratégie pour sélectionner un serveur DHCP parmi ceux dont le client reçoit un message DHCPOFFER. L'implémentation client de DHCP DEVRAIT fournir un mécanisme permettant à l'utilisateur de sélectionner directement les valeurs 'identificateur de classe de fournisseur'.
4.3 Comportement du serveur DHCP (DHCP server behavior)
Un serveur DHCP traite les messages DHCP entrants d'un client en fonction de l'état actuel de la liaison pour ce client. Un serveur DHCP peut recevoir les messages suivants d'un client :
- DHCPDISCOVER
- DHCPREQUEST
- DHCPDECLINE
- DHCPRELEASE
- DHCPINFORM
Le tableau 3 donne l'utilisation des champs et des options dans un message DHCP par un serveur. Le reste de cette section décrit l'action du serveur DHCP pour chaque message entrant possible.
4.3.1 Message DHCPDISCOVER
Lorsqu'un serveur reçoit un message DHCPDISCOVER d'un client, le serveur choisit une adresse réseau pour le client demandeur. Si aucune adresse n'est disponible, le serveur peut choisir de signaler le problème à l'administrateur système. Si une adresse est disponible, la nouvelle adresse DEVRAIT être choisie comme suit :
- L'adresse actuelle du client telle qu'enregistrée dans la liaison actuelle du client, SINON
- L'adresse précédente du client telle qu'enregistrée dans la liaison (maintenant expirée ou libérée) du client, si cette adresse est dans le pool d'adresses disponibles du serveur et n'est pas déjà allouée, SINON
- L'adresse demandée dans l'option 'Adresse IP demandée', si cette adresse est valide et n'est pas déjà allouée, SINON
- Une nouvelle adresse allouée à partir du pool d'adresses disponibles du serveur ; l'adresse est sélectionnée en fonction du sous-réseau à partir duquel le message a été reçu (si 'giaddr' est 0) ou de l'adresse de l'agent relais qui a transmis le message ('giaddr' lorsqu'il n'est pas 0).
Comme décrit dans la section 4.2, un serveur PEUT, pour des raisons administratives, attribuer une adresse autre que celle demandée, ou peut refuser d'allouer une adresse à un client particulier même si des adresses libres sont disponibles.
Notez que, dans certaines architectures réseau (par exemple, des internets avec plus d'un sous-réseau IP attribué à un segment de réseau physique), il peut être le cas qu'un client DHCP devrait se voir attribuer une adresse d'un sous-réseau différent de l'adresse enregistrée dans 'giaddr'. Ainsi, DHCP n'exige pas que le client se voie attribuer une adresse du sous-réseau dans 'giaddr'. Un serveur est libre de choisir un autre sous-réseau, et il est au-delà de la portée de la spécification DHCP de décrire les moyens par lesquels l'adresse IP attribuée pourrait être choisie.
Bien que cela ne soit pas requis pour le bon fonctionnement de DHCP, le serveur NE DEVRAIT PAS réutiliser l'adresse réseau sélectionnée avant que le client ne réponde au message DHCPOFFER du serveur. Le serveur peut choisir d'enregistrer l'adresse comme étant offerte au client.
Le serveur doit également choisir un délai d'expiration pour le bail, comme suit :
- SI le client n'a pas demandé de bail spécifique dans le message DHCPDISCOVER et que le client a déjà une adresse réseau attribuée, le serveur renvoie le délai d'expiration du bail précédemment attribué à cette adresse (notez que le client doit explicitement demander un bail spécifique pour prolonger le délai d'expiration sur une adresse précédemment attribuée), SINON
- SI le client n'a pas demandé de bail spécifique dans le message DHCPDISCOVER et que le client n'a pas d'adresse réseau attribuée, le serveur attribue un délai de bail par défaut configuré localement, SINON
- SI le client a demandé un bail spécifique dans le message DHCPDISCOVER (indépendamment du fait que le client ait une adresse réseau attribuée), le serveur peut choisir de renvoyer le bail demandé (si le bail est acceptable pour la politique locale) ou de sélectionner un autre bail.
Tableau des champs et options utilisés par les serveurs DHCP
| Champ | DHCPOFFER | DHCPACK | DHCPNAK |
|---|---|---|---|
| op | BOOTREPLY | BOOTREPLY | BOOTREPLY |
| htype | (de la RFC "Assigned Numbers") | ||
| hlen | (longueur d'adresse matérielle en octets) | ||
| hops | 0 | 0 | 0 |
| xid | 'xid' du message DHCPDISCOVER du client | 'xid' du message DHCPREQUEST du client | 'xid' du message DHCPREQUEST du client |
| secs | 0 | 0 | 0 |
| ciaddr | 0 | 'ciaddr' de DHCPREQUEST ou 0 | 0 |
| yiaddr | Adresse IP offerte au client | Adresse IP attribuée au client | 0 |
| siaddr | Adresse IP du prochain serveur de bootstrap | Adresse IP du prochain serveur de bootstrap | 0 |
| flags | 'flags' du message DHCPDISCOVER du client | 'flags' du message DHCPREQUEST du client | 'flags' du message DHCPREQUEST du client |
| giaddr | 'giaddr' du message DHCPDISCOVER du client | 'giaddr' du message DHCPREQUEST du client | 'giaddr' du message DHCPREQUEST du client |
| chaddr | 'chaddr' du message DHCPDISCOVER du client | 'chaddr' du message DHCPREQUEST du client | 'chaddr' du message DHCPREQUEST du client |
| sname | Nom d'hôte du serveur ou options | Nom d'hôte du serveur ou options | (inutilisé) |
| file | Nom de fichier de démarrage client ou options | Nom de fichier de démarrage client ou options | (inutilisé) |
| options | options | options |
| Option | DHCPOFFER | DHCPACK | DHCPNAK |
|---|---|---|---|
| Adresse IP demandée | NE DOIT PAS | NE DOIT PAS | NE DOIT PAS |
| Durée de bail d'adresse IP | DOIT | DOIT (DHCPREQUEST) NE DOIT PAS (DHCPINFORM) | NE DOIT PAS |
| Utiliser les champs 'file'/'sname' | PEUT | PEUT | NE DOIT PAS |
| Type de message DHCP | DHCPOFFER | DHCPACK | DHCPNAK |
| Liste de demande de paramètres | NE DOIT PAS | NE DOIT PAS | NE DOIT PAS |
| Message | DEVRAIT | DEVRAIT | DEVRAIT |
| Identificateur de client | NE DOIT PAS | NE DOIT PAS | PEUT |
| Identificateur de classe de fournisseur | PEUT | PEUT | PEUT |
| Identificateur de serveur | DOIT | DOIT | DOIT |
| Taille maximale de message | NE DOIT PAS | NE DOIT PAS | NE DOIT PAS |
| Tous les autres | PEUT | PEUT | NE DOIT PAS |
Tableau 3 : Champs et options utilisés par les serveurs DHCP
Une fois l'adresse réseau et le bail déterminés, le serveur construit un message DHCPOFFER avec les paramètres de configuration offerts. Il est important que tous les serveurs DHCP renvoient les mêmes paramètres (à l'exception possible d'une adresse réseau nouvellement allouée) pour garantir un comportement client prévisible quel que soit le serveur sélectionné par le client. Les paramètres de configuration DOIVENT être sélectionnés en appliquant les règles suivantes dans l'ordre donné ci-dessous. L'administrateur réseau est responsable de la configuration de plusieurs serveurs DHCP pour assurer des réponses uniformes de ces serveurs. Le serveur DOIT retourner au client :
- L'adresse réseau du client, telle que déterminée par les règles données précédemment dans cette section,
- Le délai d'expiration pour le bail du client, tel que déterminé par les règles données précédemment dans cette section,
- Les paramètres demandés par le client, selon les règles suivantes :
- SI le serveur a été explicitement configuré avec une valeur par défaut pour le paramètre, le serveur DOIT inclure cette valeur dans une option appropriée dans le champ 'option', SINON
- SI le serveur reconnaît le paramètre comme un paramètre défini dans le document des exigences de l'hôte, le serveur DOIT inclure la valeur par défaut pour ce paramètre donnée dans le document des exigences de l'hôte dans une option appropriée dans le champ 'option', SINON
- Le serveur NE DOIT PAS retourner de valeur pour ce paramètre,
- Le serveur DOIT fournir autant de paramètres demandés que possible et DOIT omettre tous les paramètres qu'il ne peut pas fournir. Le serveur DOIT inclure chaque paramètre demandé une seule fois sauf si explicitement autorisé dans le document Options DHCP et Extensions de fournisseur BOOTP.
- Tous les paramètres de la liaison existante qui diffèrent des valeurs par défaut du document des exigences de l'hôte,
- Tous les paramètres spécifiques à ce client (tel qu'identifié par le contenu de 'chaddr' ou de 'identificateur de client' dans le message DHCPDISCOVER ou DHCPREQUEST), par exemple, tels que configurés par l'administrateur réseau,
- Tous les paramètres spécifiques à la classe de ce client (tel qu'identifié par le contenu de l'option 'Identificateur de classe de fournisseur' dans le message DHCPDISCOVER ou DHCPREQUEST), par exemple, tels que configurés par l'administrateur réseau ; les paramètres doivent être identifiés par une correspondance exacte entre les identificateurs de classe de fournisseur du client et la classe de client identifiée dans le serveur,
- Les paramètres avec des valeurs non par défaut sur le sous-réseau du client.
Le serveur PEUT choisir de retourner l''identificateur de classe de fournisseur' utilisé pour déterminer les paramètres dans le message DHCPOFFER pour aider le client à sélectionner quel DHCPOFFER accepter. Le serveur insère le champ 'xid' du message DHCPDISCOVER dans le champ 'xid' du message DHCPOFFER et envoie le message DHCPOFFER au client demandeur.
4.3.2 Message DHCPREQUEST
Un message DHCPREQUEST peut provenir d'un client répondant à un message DHCPOFFER d'un serveur, d'un client vérifiant une adresse IP précédemment allouée ou d'un client prolongeant le bail sur une adresse réseau. Si le message DHCPREQUEST contient une option 'identificateur de serveur', le message est en réponse à un message DHCPOFFER. Sinon, le message est une demande de vérification ou de prolongation d'un bail existant. Si le client utilise un 'identificateur de client' dans un message DHCPREQUEST, il DOIT utiliser ce même 'identificateur de client' dans tous les messages ultérieurs. Si le client a inclus une liste de paramètres demandés dans un message DHCPDISCOVER, il DOIT inclure cette liste dans tous les messages ultérieurs.
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 client DEVRAIT utiliser les paramètres du message DHCPACK pour la configuration.
Les clients envoient des messages DHCPREQUEST comme suit :
DHCPREQUEST généré pendant l'état SELECTING :
Le client insère l'adresse du serveur sélectionné dans 'identificateur de serveur', 'ciaddr' DOIT être zéro, 'adresse IP demandée' DOIT être remplie avec la valeur yiaddr du DHCPOFFER choisi.
Notez que le client peut choisir de collecter plusieurs messages DHCPOFFER et de sélectionner la "meilleure" offre. Le client indique sa sélection en identifiant le serveur offrant dans le message DHCPREQUEST. Si le client ne reçoit aucune offre acceptable, le client peut choisir d'essayer un autre message DHCPDISCOVER. Par conséquent, les serveurs peuvent ne pas recevoir de DHCPREQUEST spécifique à partir duquel ils peuvent décider si le client a accepté l'offre ou non. Étant donné que les serveurs n'ont engagé aucune attribution d'adresse réseau sur la base d'un DHCPOFFER, les serveurs sont libres de réutiliser les adresses réseau offertes en réponse aux demandes ultérieures. En tant que détail d'implémentation, les serveurs ne devraient pas réutiliser les adresses offertes et peuvent utiliser un mécanisme de temporisation spécifique à l'implémentation pour décider quand réutiliser une adresse offerte.
DHCPREQUEST généré pendant l'état INIT-REBOOT :
'identificateur de serveur' NE DOIT PAS être rempli, l'option 'adresse IP demandée' DOIT être remplie avec la notion du client de son adresse précédemment attribuée. 'ciaddr' DOIT être zéro. Le client cherche à vérifier une configuration précédemment allouée et mise en cache. Le serveur DEVRAIT envoyer un message DHCPNAK au client si l''adresse IP demandée' est incorrecte ou est sur le mauvais réseau.
La détermination de savoir si un client dans l'état INIT-REBOOT est sur le réseau correct se fait en examinant le contenu de 'giaddr', l'option 'adresse IP demandée', et une recherche dans la base de données. Si le serveur DHCP détecte que le client est sur le mauvais réseau (c'est-à-dire que le résultat de l'application du masque de sous-réseau local ou du masque de sous-réseau distant (si 'giaddr' n'est pas zéro) à la valeur de l'option 'adresse IP demandée' ne correspond pas à la réalité), alors le serveur DEVRAIT envoyer un message DHCPNAK au client.
Si le réseau est correct, alors le serveur DHCP devrait vérifier si la notion du client de son adresse IP est correcte. Si ce n'est pas le cas, alors le serveur DEVRAIT envoyer un message DHCPNAK au client. Si le serveur DHCP n'a aucun enregistrement de ce client, alors il DOIT rester silencieux, et PEUT émettre un avertissement à l'administrateur réseau. Ce comportement est nécessaire pour la coexistence pacifique de serveurs DHCP non communicants sur le même fil.
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 demandes ARP.
Si 'giaddr' est défini dans le message DHCPREQUEST, le client est sur un sous-réseau différent. Le serveur DOIT définir le bit de diffusion dans le DHCPNAK, de sorte que l'agent relais diffuse le DHCPNAK au client, car 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 demandes ARP.
DHCPREQUEST généré pendant l'état RENEWING :
'identificateur de serveur' NE DOIT PAS être rempli, l'option 'adresse IP demandée' NE DOIT PAS être remplie, 'ciaddr' DOIT être rempli avec l'adresse IP du client. Dans cette situation, le client est complètement configuré et tente de prolonger son bail. Ce message sera en unicast, donc aucun agent relais ne sera impliqué dans sa transmission. Étant donné que 'giaddr' n'est donc pas rempli, le serveur DHCP fera confiance à la valeur dans 'ciaddr' et l'utilisera lors de la réponse au client.
Un client PEUT choisir de renouveler ou de prolonger son bail avant T1. Le serveur peut choisir de ne pas prolonger le bail (en tant que décision politique par l'administrateur réseau), mais devrait retourner un message DHCPACK quoi qu'il arrive.
DHCPREQUEST généré pendant l'état REBINDING :
'identificateur de serveur' NE DOIT PAS être rempli, l'option 'adresse IP demandée' NE DOIT PAS être remplie, 'ciaddr' DOIT être rempli avec l'adresse IP du client. Dans cette situation, le client est complètement configuré et tente de prolonger son bail. Ce message DOIT être diffusé à l'adresse de diffusion IP 0xffffffff. Le serveur DHCP DEVRAIT vérifier 'ciaddr' pour l'exactitude avant de répondre au DHCPREQUEST.
Le DHCPREQUEST d'un client REBINDING est destiné à accommoder les sites qui ont plusieurs serveurs DHCP et un mécanisme pour maintenir la cohérence des liaisons entre les baux gérés par plusieurs serveurs. Un serveur DHCP PEUT prolonger le bail d'un client uniquement s'il a l'autorité administrative locale pour le faire.
4.3.3 Message DHCPDECLINE
Si le serveur reçoit un message DHCPDECLINE, le client a découvert par d'autres moyens que l'adresse réseau suggérée est déjà utilisée. Le serveur DOIT marquer l'adresse réseau comme non disponible et DEVRAIT notifier l'administrateur système local d'un problème de configuration possible.
4.3.4 Message DHCPRELEASE
Après réception d'un message DHCPRELEASE, le serveur marque l'adresse réseau comme non allouée. Le serveur DEVRAIT conserver un enregistrement des paramètres d'initialisation du client pour une réutilisation possible en réponse aux demandes ultérieures du client.
4.3.5 Message DHCPINFORM
Le serveur répond à un message DHCPINFORM en envoyant un message DHCPACK directement à l'adresse donnée dans le champ 'ciaddr' du message DHCPINFORM. Le serveur NE DOIT PAS envoyer un délai d'expiration du bail au client et NE DEVRAIT PAS remplir 'yiaddr'. Le serveur inclut d'autres paramètres dans le message DHCPACK comme défini dans la section 4.3.1.
4.3.6 Messages des clients
Le tableau 4 détaille les différences entre les messages des clients dans divers états.
| INIT-REBOOT | SELECTING | RENEWING | REBINDING | |
|---|---|---|---|---|
| Diffusion/unicast | Diffusion | Diffusion | Unicast | Diffusion |
| server-ip | NE DOIT PAS | DOIT | NE DOIT PAS | NE DOIT PAS |
| requested-ip | DOIT | DOIT | NE DOIT PAS | NE DOIT PAS |
| ciaddr | zéro | zéro | Adresse IP | Adresse IP |
Tableau 4 : Messages des clients de différents états
4.4 Comportement du client DHCP (DHCP client behavior)
La figure 5 donne le diagramme de transition d'état pour un client DHCP. Un client peut recevoir les messages suivants d'un serveur :
- DHCPOFFER
- DHCPACK
- DHCPNAK
Le message DHCPINFORM n'est pas montré dans la figure 5. Un client envoie simplement le DHCPINFORM et attend les messages DHCPACK. Une fois que le client a sélectionné ses paramètres, il a conclu le processus de configuration.
Le tableau 5 donne l'utilisation des champs et des options dans un message DHCP par un client. Le reste de cette section décrit l'action du client DHCP pour chaque message entrant possible. La description dans la section suivante correspond à la procédure de configuration complète précédemment décrite dans la section 3.1, et le texte de la section suivante correspond à la procédure de configuration abrégée décrite dans la section 3.2.
Diagramme de transition d'état pour les clients DHCP
-------- -------
| | +-------------------------->| |<-------------------+
| INIT- | | +-------------------->| INIT | |
| REBOOT |DHCPNAK/ +---------->| |<---+ |
| |Redémarrer | | ------- | |
-------- | DHCPNAK/ | | |
| Ignorer offre | -/Envoyer DHCPDISCOVER |
-/Envoyer DHCPREQUEST | | |
| | | DHCPACK v | |
----------- | (non accepter)/ ----------- | |
| | | Envoyer DHCPDECLINE | | |
| REBOOTING | | | | SELECTING |<----+ |
| | | / | | |DHCPOFFER/ |
----------- | / ----------- | |Collecter |
| | / | | | réponses |
DHCPACK/ | / +----------------+ +-------+ |
Enregistrer bail, définir| | v Sélectionner offre/ |
minuteries T1, T2 ------------ Envoyer DHCPREQUEST | |
| +----->| | DHCPNAK, Bail expiré/ |
| | | REQUESTING | Arrêter réseau |
DHCPOFFER/ | | | |
Ignorer ------------ | |
| | | | ----------- |
| +--------+ DHCPACK/ | | |
| Enregistrer bail, définir -----| REBINDING | |
| minuteries T1, T2 / | | |
| | DHCPACK/ ----------- |
| v Enregistrer bail, ^ |
+----------------> ------- /définir T1,T2 | |
+----->| |<---+ | |
| | BOUND |<---+ | |
DHCPOFFER, DHCPACK, | | | T2 expire/ DHCPNAK/
DHCPNAK/Ignorer ------- | Diffuser Arrêter réseau
| | | | DHCPREQUEST |
+-------+ | DHCPACK/ | |
T1 expire/ Enregistrer bail, définir | |
Envoyer DHCPREQUEST minuteries T1, T2 | |
au serveur de location | | |
| ---------- | |
| | |------------+ |
+->| RENEWING | |
| |----------------------------+
----------
Figure 5 : Diagramme de transition d'état pour le client DHCP
4.4.1 Initialisation et allocation d'adresse réseau
Le client commence dans l'état INIT et forme un message DHCPDISCOVER. Le client DEVRAIT attendre un temps aléatoire entre une et dix secondes pour désynchroniser l'utilisation de DHCP au démarrage. Le client définit 'ciaddr' à 0x00000000. Le client PEUT demander des paramètres spécifiques en incluant l'option 'liste de demande de paramètres'. Le client PEUT suggérer une adresse réseau et/ou un temps de bail en incluant les options 'adresse IP demandée' et 'temps de bail d'adresse IP'. Le client DOIT inclure son adresse matérielle dans le champ 'chaddr', si nécessaire pour la livraison des messages de réponse DHCP. Le client PEUT inclure un identifiant unique différent dans l'option 'identificateur de client', comme discuté dans la section 4.2. Si le client a inclus une liste de paramètres demandés dans un message DHCPDISCOVER, il DOIT inclure cette liste dans tous les messages ultérieurs.
Le client génère et enregistre un identificateur de transaction aléatoire et insère cet identificateur dans le champ 'xid'. Le client enregistre son propre temps local pour une utilisation ultérieure dans le calcul de l'expiration du bail. Le client diffuse ensuite le DHCPDISCOVER sur l'adresse de diffusion matérielle locale à l'adresse de diffusion IP 0xffffffff et au port UDP 'serveur DHCP'.
Si le 'xid' d'un message DHCPOFFER arrivant ne correspond pas au 'xid' du message DHCPDISCOVER le plus récent, le message DHCPOFFER doit être rejeté silencieusement. Tous les messages DHCPACK arrivants doivent être rejetés silencieusement.
Le client collecte des messages DHCPOFFER sur une période de temps, sélectionne un message DHCPOFFER parmi les (éventuellement nombreux) messages DHCPOFFER entrants (par exemple, le premier message DHCPOFFER ou le message DHCPOFFER d'un serveur précédemment utilisé) et extrait l'adresse du serveur de l'option 'identificateur de serveur' dans le message DHCPOFFER. Le temps pendant lequel le client collecte les messages et le mécanisme utilisé pour sélectionner un DHCPOFFER dépendent de l'implémentation.
Tableau des champs et options utilisés par les clients DHCP
| Champ | DHCPDISCOVER DHCPINFORM | DHCPREQUEST | DHCPDECLINE, DHCPRELEASE |
|---|---|---|---|
| op | BOOTREQUEST | BOOTREQUEST | BOOTREQUEST |
| htype | (de la RFC "Assigned Numbers") | ||
| hlen | (longueur d'adresse matérielle en octets) | ||
| hops | 0 | 0 | 0 |
| xid | sélectionné par le client | 'xid' du message DHCPOFFER du serveur | sélectionné par le client |
| secs | 0 ou secondes depuis le début du processus DHCP | 0 ou secondes depuis le début du processus DHCP | 0 |
| flags | Définir le drapeau 'BROADCAST' si le client nécessite une réponse en diffusion | Définir le drapeau 'BROADCAST' si le client nécessite une réponse en diffusion | 0 |
| ciaddr | 0 (DHCPDISCOVER) adresse réseau du client (DHCPINFORM) | 0 ou adresse réseau du client (BOUND/RENEW/REBIND) | 0 (DHCPDECLINE) adresse réseau du client (DHCPRELEASE) |
| yiaddr | 0 | 0 | 0 |
| siaddr | 0 | 0 | 0 |
| giaddr | 0 | 0 | 0 |
| chaddr | adresse matérielle du client | adresse matérielle du client | adresse matérielle du client |
| sname | options (si indiqué dans l'option 'sname/file'); sinon inutilisé | options (si indiqué dans l'option 'sname/file'); sinon inutilisé | (inutilisé) |
| file | options (si indiqué dans l'option 'sname/file'); sinon inutilisé | options (si indiqué dans l'option 'sname/file'); sinon inutilisé | (inutilisé) |
| options | options | options | (inutilisé) |
| Option | DHCPDISCOVER DHCPINFORM | DHCPREQUEST | DHCPDECLINE, DHCPRELEASE |
|---|---|---|---|
| Adresse IP demandée | PEUT (DISCOVER) NE DOIT PAS (INFORM) | DOIT (dans SELECTING ou INIT-REBOOT) NE DOIT PAS (dans BOUND ou RENEWING) | DOIT (DHCPDECLINE), NE DOIT PAS (DHCPRELEASE) |
| Temps de bail d'adresse IP | PEUT (DISCOVER) NE DOIT PAS (INFORM) | PEUT | NE DOIT PAS |
| Utiliser les champs 'file'/'sname' | PEUT | PEUT | PEUT |
| Type de message DHCP | DHCPDISCOVER/ DHCPINFORM | DHCPREQUEST | DHCPDECLINE/ DHCPRELEASE |
| Identificateur de client | PEUT | PEUT | PEUT |
| Identificateur de classe de fournisseur | PEUT | PEUT | NE DOIT PAS |
| Identificateur de serveur | NE DOIT PAS | DOIT (après SELECTING) NE DOIT PAS (après INIT-REBOOT, BOUND, RENEWING ou REBINDING) | DOIT |
| Liste de demande de paramètres | PEUT | PEUT | NE DOIT PAS |
| Taille maximale de message | PEUT | PEUT | NE DOIT PAS |
| Message | NE DEVRAIT PAS | NE DEVRAIT PAS | DEVRAIT |
| Spécifique au site | PEUT | PEUT | NE DOIT PAS |
| Tous les autres | PEUT | PEUT | NE DOIT PAS |
Tableau 5 : Champs et options utilisés par les clients DHCP
Si les paramètres sont acceptables, le client enregistre l'adresse du serveur qui a fourni les paramètres à partir du champ 'identificateur de serveur' et envoie cette adresse dans le champ 'identificateur de serveur' d'un message de diffusion DHCPREQUEST. Une fois que le message DHCPACK du serveur arrive, le client est initialisé et passe à l'état BOUND. Le message DHCPREQUEST contient le même 'xid' que le message DHCPOFFER. Le client enregistre le délai d'expiration du bail comme la somme du temps auquel la demande d'origine a été envoyée et la durée du bail du message DHCPACK. Le client DEVRAIT effectuer une vérification sur l'adresse suggérée pour s'assurer que l'adresse n'est pas déjà utilisée. Par exemple, si le client est sur un réseau qui prend en charge ARP, le client peut émettre une demande ARP pour la demande suggérée. Lors de la diffusion d'une demande ARP pour l'adresse suggérée, le client doit remplir sa propre adresse matérielle comme adresse matérielle de l'expéditeur, et remplir 0 comme adresse IP de l'expéditeur, pour éviter de confondre les caches ARP dans d'autres hôtes sur le même sous-réseau. Si l'adresse réseau semble être en cours d'utilisation, le client DOIT envoyer un message DHCPDECLINE au serveur. Le client DEVRAIT diffuser une réponse ARP pour annoncer la nouvelle adresse IP du client et effacer toutes entrées de cache ARP obsolètes dans les hôtes sur le sous-réseau du client.
4.4.2 Initialisation avec adresse réseau connue
Le client commence dans l'état INIT-REBOOT et envoie un message DHCPREQUEST. Le client DOIT insérer son adresse réseau connue comme option 'adresse IP demandée' dans le message DHCPREQUEST. Le client peut demander des paramètres de configuration spécifiques en incluant l'option 'liste de demande de paramètres'. Le client génère et enregistre un identificateur de transaction aléatoire et insère cet identificateur dans le champ 'xid'. Le client enregistre son propre temps local pour une utilisation ultérieure dans le calcul de l'expiration du bail. Le client NE DOIT PAS inclure un 'identificateur de serveur' dans le message DHCPREQUEST. Le client diffuse ensuite le DHCPREQUEST sur l'adresse de diffusion matérielle locale au port UDP 'serveur DHCP'.
Une fois qu'un message DHCPACK avec un champ 'xid' correspondant à celui du message DHCPREQUEST du client arrive de n'importe quel serveur, le client est initialisé et passe à l'état BOUND. Le client enregistre le délai d'expiration du bail comme la somme du temps auquel le message DHCPREQUEST a été envoyé et la durée du bail du message DHCPACK.
4.4.3 Initialisation avec une adresse réseau attribuée en externe
Le client envoie un message DHCPINFORM. Le client PEUT demander des paramètres de configuration spécifiques en incluant l'option 'liste de demande de paramètres'. Le client génère et enregistre un identificateur de transaction aléatoire et insère cet identificateur dans le champ 'xid'. Le client place sa propre adresse réseau dans le champ 'ciaddr'. Le client NE DEVRAIT PAS demander de paramètres de temps de bail.
Le client envoie ensuite en unicast le DHCPINFORM au serveur DHCP s'il connaît l'adresse du serveur, sinon il diffuse le message à l'adresse de diffusion limitée (tous 1s). Les messages DHCPINFORM DOIVENT être dirigés vers le port UDP 'serveur DHCP'.
Une fois qu'un message DHCPACK avec un champ 'xid' correspondant à celui du message DHCPINFORM du client arrive de n'importe quel serveur, le client est initialisé.
Si le client ne reçoit pas de DHCPACK dans un délai raisonnable (60 secondes ou 4 essais si l'on utilise le délai d'expiration suggéré dans la section 4.1), alors il DEVRAIT afficher un message informant l'utilisateur du problème, puis DEVRAIT commencer le traitement réseau en utilisant des valeurs par défaut appropriées comme indiqué dans l'Annexe A.
4.4.4 Utilisation de la diffusion et de l'unicast
Les clients DHCP diffusent les messages DHCPDISCOVER, DHCPREQUEST et DHCPINFORM, sauf si le client connaît l'adresse d'un serveur DHCP. Le client envoie en unicast les messages DHCPRELEASE au serveur. Étant donné que le client refuse l'utilisation de l'adresse IP fournie par le serveur, le client diffuse les messages DHCPDECLINE.
Lorsque le client DHCP connaît l'adresse d'un serveur DHCP, dans l'état INIT ou REBOOTING, le client peut utiliser cette adresse dans le DHCPDISCOVER ou DHCPREQUEST plutôt que l'adresse de diffusion IP. Le client peut également utiliser l'unicast pour envoyer des messages DHCPINFORM à un serveur DHCP connu. Si le client ne reçoit aucune réponse aux messages DHCP envoyés à l'adresse IP d'un serveur DHCP connu, le client DHCP revient à l'utilisation de l'adresse de diffusion IP.
4.4.5 Réacquisition et expiration
Le client maintient deux temps, T1 et T2, qui spécifient les moments auxquels le client tente de prolonger son bail sur son adresse réseau. T1 est le moment auquel le client entre dans l'état RENEWING et tente de contacter le serveur qui a initialement émis l'adresse réseau du client. T2 est le moment auquel le client entre dans l'état REBINDING et tente de contacter n'importe quel serveur. T1 DOIT être plus tôt que T2, qui, à son tour, DOIT être plus tôt que le moment auquel le bail du client expirera.
Pour éviter le besoin d'horloges synchronisées, T1 et T2 sont exprimés dans les options comme des temps relatifs [2].
Au temps T1, le client passe à l'état RENEWING et envoie (via unicast) un message DHCPREQUEST au serveur pour prolonger son bail. Le client définit le champ 'ciaddr' dans le DHCPREQUEST à son adresse réseau actuelle. Le client enregistre le temps local auquel le message DHCPREQUEST est envoyé pour le calcul du délai d'expiration du bail. Le client NE DOIT PAS inclure un 'identificateur de serveur' dans le message DHCPREQUEST.
Tous les messages DHCPACK qui arrivent avec un 'xid' qui ne correspond pas au 'xid' du message DHCPREQUEST du client sont rejetés silencieusement. Lorsque le client reçoit un DHCPACK du serveur, le client calcule le délai d'expiration du bail comme la somme du temps auquel le client a envoyé le message DHCPREQUEST et la durée du bail du message DHCPACK. Le client a réacquis avec succès son adresse réseau, retourne à l'état BOUND et peut continuer le traitement réseau.
Si aucun DHCPACK n'arrive avant le temps T2, le client passe à l'état REBINDING et envoie (via diffusion) un message DHCPREQUEST pour prolonger son bail. Le client définit le champ 'ciaddr' dans le DHCPREQUEST à son adresse réseau actuelle. Le client NE DOIT PAS inclure un 'identificateur de serveur' dans le message DHCPREQUEST.
Les temps T1 et T2 sont configurables par le serveur via les options. T1 par défaut est (0.5 * duration_of_lease). T2 par défaut est (0.875 * duration_of_lease). Les temps T1 et T2 DEVRAIENT être choisis avec un certain "flou" aléatoire autour d'une valeur fixe, pour éviter la synchronisation de la réacquisition par les clients.
Un client PEUT choisir de renouveler ou de prolonger son bail avant T1. Le serveur peut choisir de prolonger le bail du client selon la politique définie par l'administrateur réseau. Le serveur DEVRAIT retourner T1 et T2, et leurs valeurs DEVRAIENT être ajustées par rapport à leurs valeurs d'origine pour tenir compte du temps restant sur le bail.
Dans les états RENEWING et REBINDING, si le client ne reçoit aucune réponse à son message DHCPREQUEST, le client DEVRAIT attendre la moitié du temps restant jusqu'à T2 (dans l'état RENEWING) et la moitié du temps de bail restant (dans l'état REBINDING), jusqu'à un minimum de 60 secondes, avant de retransmettre le message DHCPREQUEST.
Si le bail expire avant que le client ne reçoive un DHCPACK, le client passe à l'état INIT, DOIT immédiatement arrêter tout autre traitement réseau et demande des paramètres d'initialisation réseau comme si le client n'était pas initialisé. Si le client reçoit ensuite un DHCPACK allouant à ce client son adresse réseau précédente, le client DEVRAIT continuer le traitement réseau. Si le client se voit attribuer une nouvelle adresse réseau, il NE DOIT PAS continuer à utiliser l'adresse réseau précédente et DEVRAIT notifier les utilisateurs locaux du problème.
4.4.6 DHCPRELEASE
Si le client n'a plus besoin d'utiliser son adresse réseau attribuée (par exemple, le client est arrêté normalement), le client envoie un message DHCPRELEASE au serveur. Notez que le bon fonctionnement de DHCP ne dépend pas de la transmission des messages DHCPRELEASE.