Le Protocole DHCP. Définition. Références. Fonctionnement. Les baux

Transcription

1 Définition Le Protocole DHCP DHCP signifie Dynamic Host Configuration Protocol. Il s'agit d'un protocole qui permet à un ordinateur qui se connecte sur un réseau local d'obtenir dynamiquement et automatiquement sa configuration IP. Le but principal étant la simplification de l'administration d'un réseau. On voit généralement le protocole DHCP comment distribant des adresses IP, mais il a été conçu au départ comme complément au protocole BOOTP (Bootstrap Protocol) qui est utilisé par exemple lorsque l'on installe une machine à travers un réseau (on peut effectivement installer complètement un ordinateur, et c'est beaucoup plus rapide que de le faire en à la main). Cette dernière possibilité est très intéressante pour la maintenance de gros parcs-machines. Les versions actuelles des serveurs DHCP fonctionne pour IPv4 (adresses IP sur 4 octets). Une spécification pour IPv6 (adresses IP sur 16 octets) est en cours de développement par l'ietf. Références Les incontournables RFCs : RFC951 : BOOTP RFC1497 : options vendor extensions RFC1541 : Définition du protocole DHCP RFC1542 : interaction entre BOOTP et DHCP RFC2131 : complément à la RFC1541 RFC2132 : complément aux options vendor extensions Fonctionnement DHCP fonctionne sur le modèle client-serveur : un serveur, qui détient la politique d'attribution des configurations IP, envoie une configuration donnée pour une durée donnée à un client donné (typiquement, une machine qui vient de démarrer). Le serveur va servir de base pour toutes les requêtes DHCP (il les reçoit et y répond), aussi doit-il avoir une configuration IP fixe. Dans un réseau, on peut donc n'avoir qu'une seule machine avec adresse IP fixe : le serveur DHCP. Le protocole DHCP s'appuie entièrement sur BOOTP : il en reprend le mécanisme de base (ordre des requêtes, mais aussi le format des messages). DHCP est une extension de BOOTP. Quand une machine vient de démarrer, elle n'a pas de configuration réseau (meme pas de configuration par defaut), et pourtant, elle doit arriver à émettre un message sur le réseau pour qu'on lui donne une vraie configuration. La technique utilisée est le broadcast : pour trouver et dialoguer avec un serveur DHCP, la machine va simplement émettre un paquet spécial, dit de broadcast, sur l'adresse IP et sur le réseau local. Ce paquet particulier va être reçu par toutes les machines connectées au réseau (particularité du broadcast). Lorsque le serveur DHCP reçoit ce paquet, il répond par un autre paquet de broadcast contenant toutes les informations requises pour la configuration. Si le client accepte la configuration, il renvoit un paquet pour informer le serveur qu'il garde les paramètres, sinon, il fait une nouvelle demande. Les choses se passent de la même façon si le client a déjà une adresse IP (négociation et validation de la configuration), sauf que le dialogue ne s'établit plus avec du broadcast. Les baux Pour des raisons d'optimisation des ressources réseau, les adresses IP sont délivrées pour une durée limitée. C'est ce qu'on appelle un bail (lease en anglais). Un client qui voit son bail arriver à terme peut demander au serveur un renouvellement du bail. De même, lorsque le serveur verra un bail arrivé à terme, il émettra un paquet pour demander au client s'il veut prolonger son bail. Si le serveur ne reçoit pas de réponse valide, il rend disponible l'adresse IP. C'est toute la subtilité du DHCP : on peut optimiser l'attribution des adresses IP en jouant sur la durée des baux. Le problème est là : si toutes les adresses sont allouées et si aucune n'est libérée au bout d'un certain temps, plus aucune requête ne pourra être satisfaite. Sur un réseau où beaucoup d'ordinateurs se connectent et se déconnectent souvent (réseau d'école ou de locaux commerciaux par exemple), il est intéressant de proposer des baux de courte durée. A l'inverse, sur un réseau constitué en majoritéde machines fixes, très peu souvent rebootées, des baux de longues durées suffisent. N'oubliez pas que le DHCP marche principalement par broadcast, et que cela peut bloquer de la bande passante sur des petits réseaux fortement sollicités. Le protocole DHCP Page 1/5

2 Dynamique ou pas? Un serveur DHCP est censé fournir des adresses dynamiques (un même ordinateur peut recevoir successivement 2 adresses différentes), mais il peut fournir une adresse IP fixe à un client bien particulier. Ceci ne doit être utilisé que de manière modérée, sinon, le serveur DHCP ne sert à peu près plus à rien, mais cela peut se révéler utile pour fournir l'adresse IP au serveur TFTP qui va servir pour le boot à distance des machines. Les requêtes et les messages DHCP On pourrait croire qu'un seul aller-retour peut suffir à la bonne marche du protocole. En fait, il existe plusieurs messages DHCP qui permettent de compléter une configuration, la renouveler... Ces messages sont susceptibles d'être émis soit par le client pour le ou les serveurs, soit par le serveur vers un client : nom DHCPDISCOVER (1) DHCPOFFER (2) DHCPREQUEST (3) DHCPDECLINE (4) DHCPACK (5) DHCPNAK (6) DHCPRELEASE (7) DHCPINFORM (8) description pour localiser les serveurs DHCP disponibles et demander une première configuration réponse du serveur à un message DHCPDISCOVER, qui contient les premiers paramètres requête diverse du client pour par exemple prolonger son bail le client annonce au serveur que l'adresse est déjà utilisée réponse du serveur qui contient des paramètres et l'adresse IP du client réponse du serveur pour signaler au le client que son bail est échu ou si le client annonce une mauvaise configuration réseau le client libère son adresse IP le client demande des paramètres locaux, il a déjà son adresse IP La valeur entre parenthèses est utilisées pour identifier ces requêtes dans les messages DHCP. La premère requête émise par le client est un message DHCPDISCOVER. Le serveur répond par un DHCPOFFER, en particulier pour soumettre une adresse IP au client. Le client établit sa configuration, demande éventuellement d'autres paramètres, puis fait un DHCPREQUEST pour valider son adresse IP. Le serveur répond simplement par un DHCPACK avec l'adresse IP pour confirmation de l'attribution. Normalement, c'est suffisant pour qu'un client obtienne une configuration réseau efficace, mais cela peut être plus ou moins long selon que le client accepte ou non l'adresse IP ou demande des infos complémentaires... Pour demander une nouvelle adresse, le chronogramme-type est le suivant : Le protocole DHCP Page 2/5

3 Pour renouveler une adresse, le fonctionnement est le suivant (les 2 serveurs connaissent le client) : Le protocole DHCP Page 3/5

4 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) : octet 1 octet 2 octet 3 octet 4 op (1) htype (1) hlen (1) hops (1) xid (4) secs (2) flags (2) ciaddr (4) yiaddr (4) siaddr (4) giaddr (4) chaddr (16) sname (64) file (128) options (variable) 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 Le protocole DHCP Page 4/5

5 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 : octet 1 octet 2 données... Code de l'option longeur champ de données... 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. Le protocole DHCP Page 5/5