Vous êtes ici : Accueil Fondamentaux Le Dynamic Host Configuration Protocol (DHCP) - RFC 2131

Le Dynamic Host Configuration Protocol (DHCP) - RFC 2131

L'implémentation d'un service RARP (Reverse ARP), utilisant des messages ARP (couche 3) dans un contexte client/serveur afin qu'un serveur attribue à un client qui en fait la demande une adresse IPv4 prédéfinie est devenu obsolète. Le successeur de BOOTP (couche7), DHCP est le protocole incontournable pour la bonne compréhension des mécanismes d'attribution statique, automatique ou dynamique d'une multitude de paramètres réseaux aux clients, dont l'adresse IP, le masque, la passerelle ...

Le Dynamic Host Configuration Protocol (DHCP) est utilisé pour activer des hôtes (Clients DHCP) sur un réseau IP pour obtenir leur configuration d'un serveur (Serveur DHCP), notamment en leur attribuant dynamiquement leur adresse IP. Cette solution est évidemment intéressante pour réduire le poids administratif de la gestion d'un tel réseau [1].

Le protocole DHCP est décrit dans la RFC 2131.

DHCP, protocole applicatif, utilise UDP au niveau de la couche transport. Le client envoie des messages au serveur sur le port (67) et le serveur renvoie des messages au client sur le port (68).

DHCP est une extension du protocole BOOTP [2]. Les deux principales différences entre ces deux protocoles sont les suivantes :

1. DHCP définit un mécanisme d'assignation d'adresse IP à  un client pour une période déterminée (bail), cette adresse pouvant être redonnée à  un autre client plus tard.

2. DHCP fournit le mécanisme qui donne beaucoup plus de paramètres de configuration pour qu'un client puisse opérer dans un réseau TCP/IP.

Il y a trois mécanisme d'assignation d'adresses IP :

1. Allocation automatique - DHCP assigne une adresse IP permanente à  un client.

2. Allocation manuelle - L'adresse IP du client est assignée par un administrateur, DHCP donne l'adresse au client.

3. Allocation dynamique - DHCP assigne une adresse IP au client pour une période limitée (bail - lease)

Nous nous concentrerons sur le mécanisme des allocations dynamiques. D'autres paramètres de configurations sont disponibles dans la RFC 1533, dont :

  • Le masque de sous-réseau
  • Le routeur
  • Le domaine
  • Le serveur DNS ou d'autres paramètres optionnels

Fonctionnement basique :

Ce schéma résume de façon simplifiée le fonctionnement de DHCP :

doc-25
Résumé de DHCP

Fonctionnement détaillé :

Dans un session typique, le client diffuse (broadcast) un message DHCPDISCOVER sur son segment local. Le client peut suggérer son adresse IP et la durée du bail (lease). Si le serveur est sur le même segment, il peut répondre avec un message DHCPOFFER qui inclut une adresse IP valide et d'autres paramètres comme le masque de sous-réseau [3]. Une fois que le client reçoit ce message, il répond avec un DHCPREQUEST qui inclut une valeur identifiant le serveur (pour le cas o๠il y en aurait plusieurs). Cette valeur l'identifie de manière certaine et décline implicitement les offres des autres serveurs. Une fois le DHCPREQUEST reçu, le serveur répond avec les paramètres définitifs de configuration par un message DHCPACK (si le serveur a déjà  assigné l'adresse IP, il envoie un DHCPNACK).

Si le client détecte que l'adresse IP est déjà  utilisée sur le segment, il envoie un DHCPDECLINE au serveur et le processus recommence [4].

Si le client reçoit un message DHCPNACK du serveur après un DHCPREQUEST, le processus recommence également.

Si le client plus besoin d'une adresse IP, il envoie un DHCPRELEASE au serveur. Avec Windows, on exécutera la commande ipconfig /release_all [5].

Si le client veut étendre la durée du bail qui lui est allouée, il envoie un DHCPREQUEST au serveur dans lequel le champ 'ciaddr' correspondra à  son adresse IP actuelle. Le serveur répondra avec un DHCPACK comprenant la nouvelle durée du bail.

On trouvera donc 4 états DHCP pour le client :

1. Initialisation

2. Sélection

3. Requête

4. Liaison

Voici le schéma proposé par la RFC 2131 :

 

doc-28

 

Message Utilisation
DHCPDISCOVER Diffusion (broadcast) du client pour localiser les serveurs disponibles
DHCPOFFER Du serveur au client pour répondre au DHCPDISCOVER avec les paramètres de configuration.
DHCPREQUEST Message client aux serveurs soit (a) qui demande les paramètres à  un serveur et décline implicitement les offres de tous les autres, (b) qui confirme la validité des adresses précédemment allouées, par ex : un redémarrage système, ou (c) qui étend le bail sur une adresse réseau en particulier.
DHCPACK Du serveur au client avec les paramètres de configuration et qui inclut l'adresse réseau déjà  attribuée.
DHCPNAK Du serveur au client indiquant que la notion d'un client pour les adresses réseau est incorrecte. (par ex : si un client est déplacé sur un nouveau sous réseau) ou que le bail du client a expiré.
DHCPDECLINE Client vers serveur indiquant que l'adresse réseau est déjà  utilisée.
DHCPRELEASE Client vers serveur libérant l'adresse réseau et annulant le bail.
DHCPINFORM Client vers serveur, demandant seulement les paramètres de configuration locaux ; le client possède déjà  une adresse réseau attribuée de manière externe.

Captures

On peut analyser la capture de http://packetlife.net/captures/protocol/bootp/ sur http://www.cloudshark.org/captures/58332e558b92 qui montre un échange DHCP entre deux routeurs Cisco avec un bail de 1 minute.


 

[1] DHCP fait partie de la pile des protocoles TCP/IP

[2] Pour de plus amples informations voir la RFC 1542

[3] Si le serveur est sur un autre segment, un relai BOOTP sur le routeur peut être utilisé pour transmettre les requêtes : commande "ip helper-address"

[4] Voici ce que nous en dit la RFC2131 : "Le client DEVRAIT faire une vérification sur l'adresse suggérée pour s'assurer que l'adresse n'est pas déjà  prise. Par exemple, si le client est sur un réseau supportant l'ARP, le client émet une requête ARP pour la valeur suggérée. Quand on diffuse une requête ARP pour l'adresse suggérée, le client doit mettre sa propre adresse matérielle comme adresse matérielle de l'envoyeur, et 0 pour l'adresse IP de l'envoyeur, pour éviter la confusion entre les différents cache ARP sur d'autres machines d'un même sous réseau. Si l'adresse réseau semble être utilisée, le client DOIT envoyer un DHCPDECLINE au serveur. Le client DEVRAIT diffuser une réponse ARP pour annoncer la nouvelle adresse IP du client et vider toutes les entrées du cache ARP périmées sur les machines de son réseau."

[5] La commande ipconfig /release_all relancera le processus de requête


Mots-clés associés : , , , , , , ,
akrout a écrit :
04/12/2013 20:36
je veux bien que vous nous mètre un tp pratique pour les commande et tous