Les messages DHCP

Dialogue avec le serveur

Les messages DHCP sont transmises via UDP. Bien que peu fiable, ce protocole suffit au transport des paquets simples sur réseau local, et surtout il est très léger, donc intéressant pour les petits systèmes (du genre le micro bout de programme qui fait la requête DHCP lorsque le PC se met en route). De facto, DHCP fonctionne aussi en mode non connecté.

Le client n'utilise que le port 68 pour envoyer et recevoir ses messages  de la méme façon, le serveur envoie et reçoit ses messages sur un seul port, le port 67.

Format de la trame BOOTP/DHCP

La trame DHCP est en fait la même que BOOTP, et a le format suivant (les chiffres entre paranthèses indique la taille du champ en octets) :

• op : vaut 1 pour BOOTREQUEST (requête client), 2 pour BOOTREPLY (réponse serveur)
• htype : type de l'adresse hardware (adresse MAC, par exemple. Voir RFC1340)
• hlen : longueur de l'adresse hardware (en octet). C'est 6 pour une adresse MAC
• hops : peut être utilisé par des relais DHCP
• xid : nombre aléatoire choisi par le client et qui est utilisé pour reconnaître le client
• secs : le temps écoulé (en secondes) depuis que le client a commencé sa requête
• flags : flags divers
• ciaddr : adresse IP du client, lorsqu'il en a déjà une
• yiaddr : la (future ?) adresse IP du client
• siaddr : adresse IP du (prochain) serveur à utiliser
• giaddr : adresse IP du relais (passerelle par exemple) lorsque la connexion directe client/serveur n'est pas possible
• chaddr : adresse hardware du client
• sname : champ optionnel. Nom du serveur
• file : nom du fichier à utiliser pour le boot
• options : Champs réservé pour les options (voir RFC2132). Dans une précédente RFC, la taille de ce champ était limitée (limité à 64 octets par exemple pour la première version de BOOTP) ; maintenant, il n'y a plus de limitation. Dans tous les cas, un client DHCP doit être prêt à recevoir au minimum 576 octets, mais la possibilité lui est offerte de demander au serveur de restreindre la taille de ses messages.

Passage d'options

Le passage de paramètres (nom de la machine...) se fait par l'intermédiaires d'options. Les options sont documentées dans la RFC2132. Elles portent toutes un numéro qui les identifie. Par exemple, l'option 15 est celle qui permet de donner au client le nom de domaine du réseau.

Il est bien entendu possible d'envoyer plusieurs options dans le même message DHCP ; dans tous les cas, que l'on ne transmette qu'une seule option utile ou plusieurs, on doit toujours finir la zone d'options par une option 255 (end).

Le format des options est le suivant :

Le numéro de l'option n'est codé que sur 1 octet, donc il ne peut y avoir que 256 options possibles. L'octet 2 code la longueur du champ de données qui suit ; il ne tient donc pas compte des 2 octets de code d'option et de longueur.

Certaines options ne comportent pas de données complémentaires, comme l'option 255. Dans ce cas, il n'y a ni champ de longueur ni champ de données.

Les messages DHCP vus dans le chapitre précédent (DHCPACK...) sont tout simplement une option ! Il s'agit de l'option 53 qui comporte un champ de données de longueur 1 contenant le numéro identifiant la requête (1 pour DHCPDISCOVER...).

Les 4 premiers octets du champ d'options doivent être initialisés respectivement avec les valeurs 99, 130, 83 et 99 (valeurs en décimal). Cette séquence est appelée le "magic cookie" (gateau magique en français).

Le client DHCP a la possibilité d'imposer au serveur DHCP une taille maxi pour le champ d'options (option 57). La conséquence d'une telle limitation est que le serveur peut manquer de place pour envoyer toutes les options souhaitées. Pour répondre à ce problème, le serveur est autorisé à utiliser les champs sname et file pour finir son envoi. Le client est averti de cet usage par un option 52 dans la zone d'options.

 format imprimable

 les requêtes