Table des matières
3.1. Le service DHCP
Référence : RFC2131
Rôle du service
Le premier service que nous allons examiner est le DHCP. En effet, lors de la mise en place d’un réseau d’entreprise, l’adressage IP est une des premières problématiques à traiter. Une fois le plan d’adressage conçu, il faut configurer les adresses IP pour chaque machine.
Dans le cas des serveurs, la configuration en IP statique est préférée, pour des raisons de stabilité : puisqu’ils sont constamment en service, l’adresse qui leur est attribuée ne changera pas, et il ne faut pas qu’ils dépendent d’un autre service pour leur connectivité.
Par contre, pour les utilisateurs, devoir configurer l’adresse IP pour chaque nouvelle machine entrant dans le réseau est contraignant. On préférera donc l’adressage dynamique : au lieu de nécessiter une intervention manuelle pour la configuration, la machine utilisateur demandera l’adresse IP à un serveur dédié, qui se charge de distribuer les adresses selon les guidelines données par l’administrateur.
Le protocole utilisé principalement pour cette attribution dynamique d’adresse IP est le protocole DHCP (Dynamic Host Configuration Protocol). Ce protocole est le sucesseur de BOOTP, dont il a hérité des numéros de ports (UDP 67 et 68).
En plus de l’attribution de l’adresse IP, le DHCP peut également transmettre différents paramètres pour la configuration du poste utilisateur : l’adresse du subnet, l’adresse IP de la passerelle pour sortir du subnet, l’adresse du résolveur DNS, etc.
Paramètres pour la couche transport
Ce protocole applicatif utilise le protocole transport UDP, pour plusieurs raisons :
- il doit faire des envois en broadcast, ce qui n’est pas possible avec TCP
- il nécessite des échanges rapides de messages courts, et l’établissement de connection TCP prend du temps.
- il intervient au niveau d’un réseau privé qui ne devrait normalement pas subir beaucoup de pertes.
Il utilise les numéros de ports UDP 67 et 68. Etant donné que ce protocole ne respecte pas un modèle client-serveur pour lequel le client peut choisir un port quelconque, mais utilise des transmissions IP broadcast, il importe que le client soit joignable sur un port bien connu. Le port 67 est donc réservé au serveur DHCP, et le 68 au client.
Format des messages DHCP
Pour la petite histoire, le protocole DHCP utilise le format de message du protocole BOOTP, dont il est le successeur. Ainsi, on retrouvera le type de message DHCP (Discover, Offer, etc.) dans un champ d’options, intitulé “DHCP Message Type”.
Les informations que nous invitons à observer dans les messages BOOTP/DHCP sont :
- dans les flags Bootp, le flag “Broadcast”, qui servira à indiquer si le client sait recevoir des messages unicast avant d’avoir formellement reçu son adresse IP ou non,
- le champ “Your IP Address” qui sert au serveur pour indiquer au client l’adresse IP proposée,
- l’option “53” : “DHCP Message Type”, qui indiquera le type de message (Discover, Offer, …),
- les options contenant les informations concernant la durée du prêt de l’adresse : IP Address Lease Time notamment,
- l’option “55” “Parameter Request List” permettant au client d’indiquer les informations qu’il souhaiterait obtenir du serveur en plus de l’IP
- les autres options contenant diverses informations comme le masque de sous-réseau, l’IP du résolveur DNS, etc.
La capture d’écran ci-dessous vous montre le contenu d’un message DHCP extrait d’une capture Wireshark. Il s’agit d’un message DHCPREQUEST comme indiqué dans l’option “53”, avec le flag “broadcast” à zéro et diverses options liées au type de message.
Etapes d’un échange DHCP
Les échanges DHCP consistent essentiellement en un échange de quatre messages entre un poste nouvellement arrivé sur le réseau et un ou plusieurs serveur(s) DHCP. Lorsqu’un poste arrive sur un subnet, il ne connait rien de l’adressage IP de ce subnet, ni même de la localisation du serveur DHCP. Afin de pouvoir joindre ce dernier et tant qu’il ne dispose pas lui-même d’une adresse IP, il doit donc passer par le broadcast. L’échange va se passer comme suit :
- Le client envoie un message DHCPDISCOVER pour contacter un ou plusieurs serveurs DHCP. Il utilise l’adresse IP source 0.0.0.0 puisqu’il n’en possède pas, et 255.255.255.255 (broadcast) comme adresse destination, puisqu’il ne sait pas comment joindre le(s) serveur(s) DHCP. Il indique éventuellement en option de son message la liste des paramètres qu’il souhaite obtenir (masque, gateway, DNS,…)
- Un ou plusieurs serveurs DHCP ayant reçu la requête du client répondent à ce dernier par un message DHCPOFFER proposant une adresse IP.
- Le client choisit une adresse IP parmi celles reçues. Il envoie un message DHCPREQUEST contenant cette adresse à tous les serveurs DHCP, donc en broadcast. De la sorte, le serveur l’ayant proposée peut confirmer la réservation, et les autres serveurs savent que le client a décliné leurs offres.
- Le serveur confirme pour de bon l’allocation de l’adresse dans un message DHCPACK. A la réception de ce message, le client peut utiliser l’adresse IP allouée.
L’utilisation du broadcast est importante dans les échanges DHCP, d’une part pour pouvoir communiquer avec tous les serveurs DHCP, et d’autre part, pour que les serveurs puissent communiquer avec le client avant que ce dernier n’ait reçu son adresse.
Normalement, le client ne peut pas recevoir de message unicast sur l’adresse IP allouée avant la fin du processus de réservation. Comme le montre le tableau ci-dessus, tous les messages de la couche 3 seront des messages de broadcast. Au niveau de la couche 2, le broadcast est utilisé par le client dans les mssages DHCPDISCOVER et DHCPREQUEST, pour être sûr de joindre tous les serveurs DHCP.
| Type de message | Emetteur | MAC source | IP source | MAC destination | IP destination |
|---|---|---|---|---|---|
| DHCP Discover | Poste client | MAC client | 0.0.0.0 | Broadcast | 255.255.255.255 |
| DHCP offer | Serveur DHCP | MAC serveur | IP serveur | MAC client | 255.255.255.255 |
| DHCP Request | Poste client | MAC client | 0.0.0.0 | Broadcast | 255.255.255.255 |
| DHCP Ack | Serveur DHCP | MAC serveur | IP serveur | MAC client | 255.255.255.255 |
Cependant, certaines implémentations TCP/IP supportent la réception de messages IP unicast avant la finalisation de l’échange DHCP. Cela permet notamment de limiter les broadcasts DHCP dans les réseaux. Pour signaler cette possibilité, le client met le flag bootp/dhcp “broadcast” à zéro. On voit alors dans le tableau ci-dessous qu’au niveau de la couche réseau, les serveurs ne doivent plus utiliser de broadcast dans le DHCPOffer et le DHCPACK.
| Type de message | Emetteur | MAC source | IP source | MAC destination | IP destination |
|---|---|---|---|---|---|
| DHCP Discover | Poste client | MAC client | 0.0.0.0 | Broadcast | 255.255.255.255 |
| DHCP offer | Serveur DHCP | MAC serveur | IP serveur | MAC client | IP client |
| DHCP Request | Poste client | MAC client | 0.0.0.0 | Broadcast | 255.255.255.255 |
| DHCP Ack | Serveur DHCP | MAC serveur | IP serveur | MAC client | IP client |
La trace ci-dessous montre un échange DHCP complet lorsque le client supporte la réception unicast (flag broadcast à 0).
Architecture DHCP
L’architecture de base pour le service DHCP consiste en des échanges client-serveur sur un même réseau IP. Pour les réseaux d’entreprise de petite taille, un unique serveur DHCP peut être mis à la disposition des postes utilisateurs. Ce cas de figure est illustré dans le schéma ci-dessous, au point A.
Dans les réseaux plus complexes composé de plusieurs segments/subnets, un serveur DHCP devra gérer l’attribution des IPs pour plusieurs sous-réseaux. Puisqu’il n’est en général pas envisageable de le mettre directement dans chacun de ces sous-réseaux, il est alors possible d’utiliser un ou des relais DHCP, généralement les routeurs, qui identifieront les requêtes DHCP DISCOVER envoyées en broadcast et les relayeront, ainsi que les messages subséquents, en unicast au serveur DHCP. Ce cas de figure est illustré par le schéma B.
Enfin, pour ajouter de la redondance ou équilibrer la charge du DHCP, il est également possible d’utiliser plusieurs serveurs DHCP. Le protocole est d’ailleurs prévu pour que le client puisse recevoir plusieurs propositions d’IP (DHCP OFFER), en sélectionne une et décline les autres via l’envoi du DHCP REQUEST en broadcast. Ce cas de figure est illustré par le schéma C.