Avec un titre pareil, on se demande si on est sur un court de tennis ou un cours de réseau. C’est pourtant bien pour pouvoir communiquer que DHCP est indispensable dans la vie quotidienne. Si vous n’avez pas paramétré votre adresse IP pour lire ce chapitre, c’est très certainement grâce à lui !
Ce protocole sert à distribuer automatiquement des configurations IP dès que vous connectez votre appareil à un réseau. Nous allons d’abord voir comment il fonctionne globalement, puis nous nous intéresserons aux possibilités de configuration offertes par les routeurs et les serveurs.
Côté client
DHCP est un protocole de niveau 7 qui permet d’obtenir une adresse IP automatiquement, sans avoir à configurer sa carte réseau. C’est bien pratique quand on ne connait pas le réseau, et surtout, on ne risque pas de s’attribuer par erreur une adresse déjà utilisée.
C’est bien pratique aussi pour l’administrateur réseau qui n’a pas envie de configurer les 500 machines de son entreprise. En plus, en cas de changement de plan d’adressage, il aura encore moins envie de devoir refaire tout le travail.
Vous l’avez sûrement remarqué, sous la plupart des systèmes d’exploitation (Windows, Android, …), la configuration réseau se fait automatiquement. Elle est généralement fournie par DHCP. Voyons justement comment cela fonctionne pour nous, clients. Que se passe-t-il quand on branche un câble dans la prise, ou quand on se connecte sur un réseau Wi-Fi ?
Nous avons dit que DHCP est de niveau 7. Il fonctionne au dessus d’UDP et IP.
…
Il n’y a pas quelque chose qui vous choque ?
DHCP sert à obtenir une adresse IP, donc on l’utilise quand on n’en a pas, donc… comment ça peut fonctionner sur IP !?
Hé hé hé… Il y a deux cas différents, selon qu’on utilise IPv4 ou IPv6.
En IPv4
En réalité, c’est tout bête : quand une machine demande une adresse IP en DHCP, elle prend l’adresse 0.0.0.0.
L’obtention d’une adresse IP se fait en plusieurs phases :
- Le client envoie en broadcast une recherche de serveur DHCP (DHCP discover, découverte). Niveau transport, le port source est toujours 68 et le port destination 67. Cela implique nécessairement que la machine qui répond soit sur le même réseau physique : les broadcasts ne sont pas propagés par les routeurs.
- Tous les serveurs DHCP ayant reçu la requête et ayant une offre à proposer y répondent en envoyant leur adresse IP ainsi que la configuration (adresse, masque) qu’ils proposent au client (DHCP offer, offre). Pour cela, ils utilisent l’identifiant de niveau 2 de l’émetteur, comme l’adresse MAC sur un réseau Ethernet, afin que la réponse arrive au bon demandeur.
- Le client ne retient que la première réponse qui lui parvient, s’approprie la configuration retenue et envoie en broadcast l’adresse du serveur choisi pour qu’il réserve l’adresse et pour que les autres sachent que leur proposition a été rejetée (DHCP request, requête).
- Le serveur confirme et informe le client de la durée de validité de cette adresse (le bail). En complément, il peut aussi lui indiquer une passerelle par défaut, des serveurs DNS, … Cette dernière phase est appelée acknowledgment (acceptation).
Discover. Offer. Request. Acknowledgment. Découverte. Offre. Requête. Acceptation. Si on garde les initiales de chaque mot, ça fait DORA. Voilà un bon moyen mnémotechnique pour se souvenir des 4 phases !
Ces détails peuvent être visualisés à l’aide d'un analyseur de trames.
On peut se pencher en détail sur les différentes couches pour chacune de ces phases.
On visualise ici l’utilisation de l’adresse 0.0.0.0, l’envoi en broadcast niveau IP et Ethernet, ainsi que les ports UDP utilisés.
Notons que lors de la 2ème phase, la réponse est adressée en unicast au demandeur au niveau 2, mais au niveau 3, c’est l’adresse de broadcast qui est utilisée.
Là encore, cette trame est émise en broadcast.
Et voilà, l’attribution de l’adresse est confirmée !
En IPv6
Avec IPv6, toute carte réseau dispose de base d’une adresse de lien local, générée par le système d’exploitation. DHCP peut tout de même servir à obtenir une adresse globale. Le principe est sensiblement le même qu’avec IPv4 :
- Le client sollicite un serveur DHCP (solicit). Niveau réseau, l’adresse IP source est celle de lien local. L’adresse de destination est FF02::1:2. Les broadcasts n’existant pas en IPv6, c’est cette adresse de multicast qui regroupe tous les serveurs DHCP. Niveau transport, le port source est 546, le port destination est 547.
- Tous les serveurs atteints répondent par une annonce, s’ils ont une offre à proposer (advertise).
- Le client confirme la demande qui lui convient (la première reçue, généralement) au moyen d’un paquet émis sur le même multicast qu’à l’étape 1 (request).
- Le serveur confirme l’attribution et fournit éventuellement des informations complémentaires (reply).
Lorsqu’on parle de DHCP sur IPv6, on le précise souvent en parlant de DHCPv6. Ce n’est pas le seul à fournir des adresses : le protocole NDP propose aussi ce service.
Ça, c’est ce que voit un client. Mais de l’autre côté du réseau, les choses peuvent être plus complexes que cela.
Côté serveur
Dans les cas les plus simples, c’est un routeur qui fait office de serveur DHCP. Il n’en a toutefois pas l’obligation, il peut même ne pas proposer ce service du tout. Le rôle d’un routeur, ce n’est pas de fournir des adresses : quand on doit assurer le routage de données de nombreux flux, on a parfois autre chose à faire que de distribuer des IP.
Fonctionnement des serveurs
Cette tâche peut être dévolue à des serveurs, dont c’est déjà davantage le rôle. Un serveur DHCP est configuré avec une liste d’adresses qu’il peut attribuer et leur masque associé. On appelle cela un pool. On le paramètre aussi pour renvoyer d’autres informations au client, comme une adresse de passerelle par défaut ou des serveurs DNS.
Quand un serveur DHCP reçoit une requête, il pioche une adresse dans ce pool (généralement, la première disponible dans l’ordre numérique) pour la fournir au client. Il est possible de configurer le serveur pour renvoyer une adresse IP spécifique en fonction de l’adresse physique (MAC) du demandeur. L’adresse IP fournie est enregistrée comme étant prise par le serveur et ne peut plus être distribuée. Cette attribution est limitée dans le temps par un bail qui peut être défini comme on le souhaite : 2 heures, 1 jour, une semaine… Pour pouvoir continuer à utiliser l’adresse fournie, le client doit formuler une demande de renouvellement de bail à la moitié du temps de validité. Ainsi, si le bail est de 2 heures, le client doit formuler une demande au bout d’une heure pour le prolonger. Sans renouvellement, le serveur demande au client à la fin du bail s’il souhaite conserver son adresse. En l’absence de réponse, elle est libérée et peut de nouveau être attribuée.
Si toutes les adresses sont attribuées et que le pool est vide, le serveur ne répond plus aux nouvelles demandes.
Comme DHCP fonctionne grâce à des broadcasts, du moins avec IPv4, cela implique qu’il faut un serveur par réseau de niveau 2 (physique ou VLAN). Dans les entreprises, il peut y en avoir beaucoup, et mettre en place autant de serveurs DHCP, c’est contraignant ! On passe alors par des agents relais.
Agent à votre service
Pour centraliser la gestion des adresses IP, on peut tout configurer sur un seul serveur. Ensuite, des serveurs ou des routeurs peuvent être paramétrés sur chaque LAN pour servir de relai. On les appelle des agents relais, ou simplement des relais.
Comme leur nom l’indique, ils relaient les flux DHCP jusqu’au serveur défini. C’est transparent pour le client : il ne voit que les échanges avec le relai comme si c’était le serveur final.
La gestion d’un grand nombre d’adresses peut même être compliquée pour un simple serveur DHCP sous Linux, par exemple. Il existe des solutions comme Efficient IP qui permettent de centraliser la gestion de quantités d’adresses et de simplifier le paramétrage dans des réseaux d’envergure.
Dans la famille des services réseaux indispensables, DHCP mérite largement sa place sur le podium. Dans le prochain chapitre, nous nous pencherons sur un autre service fondamental dans les réseaux actuels.