On rappelle que pour pouvoir communiquer dans un réseau informatique, toute machine – poste de travail, imprimante réseau, smartphone, camera IP, serveur, etc. – doit y être raccordée par l'intermédiaire d'une interface réseau correctement configurée avec notamment (cf. chap. R1‑III ) :

une adresse IP et un masque de (sous‑)réseau associé ;
et, s'il s'agit d'un réseau local raccordé à l'Internet (cas le plus courant) :

l'adresse IP d'une passerelle par défaut pour y accéder ;
l'adresse IP d'un résolveur DNS pour les noms de domaines.

On parle de configuration statique lorsque ces informations sont saisies « à la main » par un personnel administrateur du réseau dans les paramètres du système d'exploitation de la machine ou même dans un script de commande qui s'exécute au démarrage, ou encore dans le programme utilisateur s'il s'agit d'une carte à microcontrôleur. Mais dans tous les cas :

si le réseau comporte un grand nombre de machines, le travail de configuration est fastidieux (et il peut devoir être recommencé lorsque le nombre de machine augmente au delà des prévisions initiales et nécessite une refonte du plan d'adressage) ;

si le réseau héberge beaucoup de machines nomades (hotspot Wi‑Fi W des lieux publics, etc.), cette stratégie n'est tout simplement pas envisageable (dans un tel cadre, il serait inimaginable de devoir confier son smartphone à un administrateur pour le configurer).

Le protocole DHCP W (dynamic host configuration protocol) est précisément conçu pour automatiser ce travail et on parle alors de configuration dynamique. Il s'agit d'un protocole applicatif de service.

Sans surprise, ce service est basé sur un modèle client‑serveur (cf. chap. R1‑I ) où :

le client DHCP est une machine raccordée au réseau et paramétrée pour émettre des requêtes en vue d'obtenir une configuration IP dans son réseau local ;
le serveur DHCP est une machine raccordée au réseau (avec une configuration IP statique) sur laquelle s'exécute un logiciel capable d'émettre des réponses aux clients, en disposant pour cela d'une plage d'adresses IP dynamiques pour le réseau.

Le rôle d'un serveur DHCP consiste donc à attribuer pour un certain temps – ou renouveler – des adresses IP. Comme pour ces dernières, il existe donc deux versions du protocole : DHCP v4 et DHCP v6 – sachant que lorsqu'on emploie le sigle DHCP seul, on fait usuellement référence à DHCP v4.

Il faut également préciser que le protocole DHCP v6 est plus réduit que dans sa version v4 car la norme IPv6 prévoit plusieurs mécanismes d'auto‑configuration des interfaces – le but étant précisément de diminuer le nombre de transactions DHCP, donc les congestions, dans les réseaux locaux.

Beaucoup moins complexe que le DNS, le protocole DHCP est une technologie logicielle incontournable pour tout technicien réseau, et plus généralement pour tout informaticien qui serait amené à programmer des systèmes hébergés dans des réseaux à pile de protocoles TCP/IP.

L'objectif de ce chapitre est donc d'apporter toutes les connaissances nécessaires pour pouvoir comprendre et utiliser ce protocole tant du côté client que serveur, en détaillant :

les principes généraux et le déroulement du protocole DHCP :

selon ses différentes transactions (initialisation, déconnexion, renouvellement) ;
et dans pour chaque type de transaction, les différents messages échangés ;

le paramétrage d'une interface réseau en client DHCP, avec différents cas de figure selon le système d'exploitation et la méthode (via des fenêtres de dialogue ou en ligne de commande) ;
les architectures matérielles et les paramétrages logiciels basiques :

pour configurer une interface en client DHCP ;
pour comprendre le rôle des relais DHCP dans le cas d'un réseau segmenté ;

sachant que pour approfondir certains aspects, on pourra consulter par exemple cette page web .

Principes et déroulement du protocole DHCP v4

Généralités

Le protocole DHCP est un protocole applicatif (niveau 7 dans le modèle OSI – cf. chap. R1‑IV ) qui est basé sur les mêmes principes que le protocole BOOTP, et dont il étend significativement les fonctionnalités.

Il peut être employé pour toute interface de machine raccordée à un réseau à pile de protocoles TCP/IP (ordinateur, carte à microcontrôleur, etc.).

Le protocole BOOTP W (bootstrap protocol) permet d'attribuer au démarrage d'une machine de type client léger une configuration IP. Il est principalement spécifié par la RFC 951 datant de 1985, et mise à jour par diverses autres RFC (1395, 1497, etc.).

Quant à lui, le protocole DHCP est principalement spécifié par les RFC 2131 et 2132 datant de 1997, également mises à jour par d'autres RFC (3396, 4361, etc.).

Comme BOOTP, le protocole DHCP utilise les ports nº 67 (côté serveur) et 68 (côté client).

Un client léger W (thin client) est une machine sans disque dur – donc sans même un système d'exploitation qui lui soit propre. Il fonctionne exclusivement par chargement dans sa mémoire vive de code exécutable de logiciels (système et applications) et de données (fichiers), toutes fournies par des serveurs. À chaque démarrage (boot), il doit donc d'abord exécuter le protocole BOOTP pour configurer son interface réseau. C'est seulement ensuite qu'il peut émettre une requête aux serveurs d'application et de données.

Ce type de machines était très courant dans les années 1980, quand les réseaux informatiques étaient constitués de gros ordinateurs centraux W (main frame) auxquels étaient raccordés une multitude de terminaux.

En déclin dans les années 1990 avec l’avènement des PC et autres stations de travail, les clients légers sont revenus en force dans les années 2010 avec l'essor de l'informatique dématérialisée W (cloud computing).

Principes généraux de fonctionnement

Basé sur un modèle client‑serveur, le protocole DHCP comporte principalement deux types de transactions :

l'initialisation, lorsqu'un client nouvellement raccordé au réseau ne dispose pas encore d'une configuration IP et en sollicite une ;
le renouvellement, lorsqu'un client dispose déjà d'une configuration et sollicite le prolongement de son bail (sa durée de validité).

De plus, les messages DHCP échangés lors d'une transaction entre un client et un serveur sont :

transmis par datagrammes, c'est‑à‑dire via le protocole de transport UDP ;
dans la transaction initiale, diffusés en broadcast.

En effet, tant que la configuration IP du client n'est pas finalisée, ce dernier ne peut pas émettre ni recevoir des messages en unicast via le protocole IP.

Le choix de transmettre en datagrammes (cf. chap. R1‑IV ) est pertinent puisque les données échangées sont peu volumineuses. Cela garantit une légèreté et une rapidité optimales des transmissions.

En revanche, la diffusion en broadcast (cf. chap. R1‑II ) peut occasionner une charge non négligeable sur le réseau si le serveur DHCP est mal paramétré, en particulier si les durées de bail (cf. infra ) ne sont pas judicieusement choisies.

Transaction d'initialisation

L'initialisation de la configuration IP d'une interface par le protocole DHCP est déclenchée par le système d'exploitation de la machine – ou le programme utilisateur de la carte à microcontrôleur – qui agit comme client DHCP.

Cette transaction débute juste après le raccordement physique de l'interface au réseau (branchement par câble Ethernet et l'activation de cette interface, ou l'activation de la fonction Wi‑Fi, etc.), ou encore le démarrage du système alors que l'interface est déjà physiquement raccordée et activée par défaut.

Elle procède par l'échange de 4 messages DHCP entre le client et le serveur.

Ces 4 messages DHCP d'initialisation sont respectivement dits :

de découverte – DHCP discover – c'est‑à‑dire de recherche par le client d'un serveur DHCP présent sur le réseau ;
d'offre – DHCP offer – de configuration, c'est‑à‑dire d'une proposition de configuration IP émise par tout serveur DHCP ayant en réserve au moins une adresse IP dynamique vacante sur le réseau ;
de demande – DHCP request – par le client d'une configuration offerte par un serveur DHCP (par défaut, la première reçue dans le cas où plusieurs serveurs auraient répondu) ;
de confirmation – DHCP acknowledgment, abrégé ack – par le serveur ayant fait l'offre, que la demande du client est acceptée.

Une confirmation vaut attribution de l'adresse IP dynamique. Sans plus attendre :

le client DHCP configure son interface avec les éléments transmis par le serveur (adresse IP, masque, passerelle et résolveurs DNS) ;
le serveur DHCP met à jour sa plage d'adresses IP dynamiques afin que celle qui vient d'être attribuée ne soit plus vacante.

Vérification opérée par le client

Lorsqu'un client DHCP reçoit un message offre d'une configuration de la part d'un serveur DHCP, avant d'envoyer un message de demande de cette configuration, il peut procéder à la vérification que l'adresse IP dynamique proposée est bien libre. Il lui suffit pour cela de générer une commande ping sur cette adresse (cf. chap. R1‑IV ), qui doit normalement rester sans réponse.

Dans le cas contraire (par exemple si l'adresse a été attribuée dans une configuration statique), le client envoie alors immédiatement au serveur un message de refus (DHCP decline), à la suite de quoi :

le serveur met à jour sa plage d'adresses dynamiques afin que cette adresse soit marquée comme non vacante ;

en principe, il doit aussi émettre un avertissement à l'administrateur réseau car une telle situation n'est pas normale (une adresse incluse dans une plage dynamique ne doit pas être attribuée par ailleurs) ;

de son côté, le client entame une nouvelle transaction d'initialisation.

Détails opérationnels du protocole DHCP

Afin de bien comprendre le fonctionnement opérationnel du protocole DHCP, il faut considérer successivement les « points de vue » du client et du serveur.

Pour un nouveau client DHCP sur le réseau, il faut avoir conscience de ce qu'implique l'absence initiale de configuration IP :

il n'a évidemment lui‑même pas d'adresse IP ;
et il ne connaît pas l'adresse d'un serveur DHCP (il ne connaît même pas l'adresse du réseau ni son masque).

Or le routage IP des messages DHCP requiert obligatoirement une adresse d'émetteur et une adresse de destinataire.

Pour l'adresse d'émetteur, le client DHCP adopte temporairement l'adresse IP spéciale 0.0.0.0 (cf. chap. R1‑III ) qui signifie justement qu'il n'a pas encore de configuration IP.

Comme plusieurs client DHCP peuvent être simultanément dans la même situation, divers dispositifs d'identification sont incorporés dans les messages DHCP (nombre aléatoire généré par le client, adresse physique MAC…) pour éviter toute confusion entre deux clients.

Pour l'adresse de destinataire, le client DHCP utilise l'adresse IP spéciale 255.255.255.255 dite de broadcast limité (car la diffusion est limitée au réseau local et n'est pas relayée par les interfaces des routeurs – cf. chap. R1‑III , sauf celles spécifiquement configurées comme relais DHCP – cf. infra ).

Cette adresse de broadcast limité est résolue par le protocole ARP (cf. chap. R1‑IV ) au niveau 2 du modèle OSI avec l'adresse physique de broadcast FF-FF-FF-FF-FF-FF.

Les datagrammes UDP encapsulant les messages d'un client DHCP sont repérés par les serveurs DHCP grâce aux numéros de ports d'émission – nº 68 – et de destination – nº 67 – inscrits dans leur entête. En effet, tout serveur DHCP a forcément son port nº 67 ouvert et analyse en détail tous les datagrammes qui y sont envoyés.

Quant au serveur DHCP, il ne peut pas émettre ses datagrammes encapsulant les messages d'offre ou de confirmation destinés au client en unicast vers l'adresse 0.0.0.0 car cette dernière n'est pas routable.

Il utilise donc aussi l'adresse de broadcast limité 255.255.255.255 et émet depuis son port nº 67 à destination du port nº 68, qui est ouvert seulement chez les machines configurées en clients DHCP.

Pour toute offre, le serveur DHCP choisit pour le client une adresse IP vacante parmi celles figurant dans une plage d'adresses dynamiques du réseau (en anglais, address pool W) qui lui a été confiée par l'administrateur système lors du paramétrage du serveur.

Bien évidemment, la mise à jour des plages d'adresses dynamiques au fur et à mesure des attributions et des restitutions fait partie des tâches que tout serveur DHCP sait mettre en œuvre de façon automatisée.

Cas d'un ancien hôte du réseau

Un client DHCP qui obtient une configuration dynamique dans un réseau, il garde en mémoire l'adresse IP qui lui a été attribuée après sa déconnexion.

Lorsqu'il se reconnecte au même réseau, la phase initiale se déroule sans recommencer les étapes de découverte et d'offre :

le client DHCP émet directement un message de demande – request – en y incorporant directement son ancienne adresse IP comme si elle émanait d'une offre, dans un champ optionnel du message ;
si elle fait partie de sa plage d'adresses dynamiques, le serveur DHCP accepte cette demande en émettant un message de confirmation – acknowledgement – même si l'adresse est étiquetée comme déjà attribuée.

En effet, la machine du client DHCP peut avoir simplement été redémarrée pour une mise à jour, ou déconnectée momentanément par invisibilité accidentelle du réseau (en technologie Wi‑Fi). Il est donc judicieux de lui attribuer la même adresse IP.

Néanmoins, le serveur DHCP peut quand même préalablement vérifier que cette ancienne adresse IP n'a pas été attribuée entre temps à une autre machine, de façon statique ou dynamique.

Cette vérification est opérée par le biais d'une commande ping (cf. chap. R1‑IV ).

Si cette adresse n'est pas déjà attribuée à une autre machine, la commande ping reste sans réponse.

En effet, même le client DHCP n'y répond pas (car ce n'est pas parce qu'il en fait la demande qu'il en dispose, et tant que la phase initiale n'est pas achevée, il garde l'adresse IP spéciale 0.0.0.0).

En revanche, si cette adresse est attribuée à une autre machine, alors les datagrammes ICMP de la commande ping reçoivent des accusés de réception de son interface.

Dans ce cas, le serveur DHCP envoie un message de non‑acquittement – negative acknowledgment, abrégé nack.
Quant au client DHCP, il doit reprendre à zéro une phase initiale complète de configuration, comme un tout nouveau client sur le réseau.

Transaction de déconnexion appropriée

Dans le cas d'une interface réseau configurée dynamiquement, lorsque sa déconnexion intervient par le biais d'une commande appropriée – mise en veille ou à l'arrêt du système, passage en mode « avion » d'un smartphone, etc. – le client DHCP doit envoyer en unicast au serveur DHCP qui a offert la configuration un message de libération (DHCP release).

Le serveur DHCP peut alors procéder à la mise à jour de sa plage d'adresses dynamique en étiquetant comme vacante celle qu'il avait offerte à l'interface.

En principe, il doit garder en mémoire les paramètres d'initialisation du client (adresse physique, et.) pour une éventuelle future demande de configuration – auquel cas il serait préférable de lui offrir la même adresse.

Notion de bail

La déconnexion d'une interface du réseau ne se déroule pas forcément par une commande appropriée.

Elle peut être la conséquence d'un débranchement de câble ou d'un arrêt inopiné du système (perte de la tension d'alimentation…) ;
Dans le cas d'un appareil nomade (smartphone, etc.), il peut s'agir d'une sortie de la zone de visibilité du réseau par effet de mobilité.

Se pose alors la question de la procédure de récupération de l'adresse IP qui lui a été attribuée – procédure sans laquelle le serveur est exposé au risque de pénurie d'adresses dynamiques. Mais comment savoir si l'hôte de l'interface est durablement sorti du réseau – donc que son adresse est disponible pour un prochain client DHCP – ou si sa déconnexion est juste momentanée ?

La solution adoptée par le protocole DHCP est d'instaurer une limite temporelle de validité des adresses IP dynamiques : c'est la notion de bail, qui est assortie de la possibilité de renouvellement.

Le bail W – en anglais, lease time – d'une configuration IP est la période de validité de cette configuration pour un client DHCP.

Sa durée est exprimée en secondes dans un champ d'option (nº 51) des messages d'offre et de confirmation émis par le serveur DHCP.

Une durée de bail est un entier non signé codé sur 32 bits (avec donc une valeur maximale théorique d'environ 136 ans). Une valeur typique est 86 400 s, soit un jour, mais on peut être amené à choisir une valeur :

bien plus longue – une semaine, voire plus – pour les postes de travail fixes fortement sollicités dans un réseau, quelle que soit la taille et le contexte de ce dernier (entreprise, université…) ;
ou bien plus courte – une heure, voire moins – pour les hôtes nomades d'un réseau à accès public (gare, aéroport, café, etc.).

Il est même possible d'attribuer un bail à validité permanente pour certains hôtes, en particulier les machines fonctionnant sans discontinuité (serveurs, etc.). On parle alors de configuration IP fixe – à ne pas confondre avec la notion de configuration IP statique.

Renouvellement d'une configuration

Après une initialisation réussie, la demande de renouvellement du bail d'une configuration IP procède automatiquement par une ou deux transactions déclenchées par le client DHCP :

la première – dite renewing – est opérée en unicast, au bout d'une durée T1 valant par défaut la moitié de celle du bail ;
en cas d'échec, la seconde – dite rebinding – est opérée en broadcast au bout d'une durée T2 valant par défaut les 7/8^e de celle du bail.

Ces deux transactions se déroulent chacune par échange de 2 messages DHCP :

Le client émet une demande – request – de renouvellement, où figure bien entendu l'adresse IP à renouveler.
Le plus souvent, le serveur répond par une confirmation – ack – que la configuration est renouvelée.

Mais éventuellement, le serveur peut émettre un non acquittement – nack – si l'adresse IP n'est pas disponible au renouvellement (entre‑temps, elle peut avoir été supprimée de la plage des adresses dynamiques).

À l'issue de la confirmation pour l'une ou l'autre de ces tentatives, la date de fin de bail du client est incrémentée de la durée de bail spécifiée dans le message de confirmation. Les dates correspondant aux fins de périodes T1 et T2 sont modifiées en conséquence.

En cas de non acquittement, le bail reste valable jusqu'à sa date d'expiration.

De son côté, le serveur DHCP peut aussi prendre l'initiative du renouvellement, en émettant un message de non acquittement à tout hôte du réseau dont la durée T1 a expiré et qui n'a pas encore émis de demande de renouvellement. Une telle situation se produit notamment lorsque l'hôte s'est déconnecté du réseau sans libérer son adresse IP de façon appropriée (cf. supra ).

Si l'hôte est encore présent sur le réseau, ce message déclenche alors normalement de sa part une transaction de type rebinding de la part du client.
Dans le cas contraire, le serveur DHCP peut alors mettre à jour sa plage d'adresses dynamiques en considérant que celle de l'hôte est désormais vacante.

Format et contenu des messages DHCP

Rappelons que tout message DHCP est encapsulé :

dans un datagramme UDP, dont l'en‑tête comporte notamment les numéros de port d'émission et de réception (67 ou 68) ;
lui‑même encapsulé dans un datagramme IP, dont l'en‑tête comporte notamment les adresses IP d'émission et de réception ;

Dans un message DHCP, quel que soit sont type, on distingue deux parties :

en premier, un partie formée de divers champs codés dans un format invariable sur 236 octets ;
en deuxième, une partie réservée aux options, formée d'un champ unique de taille variable.

La première partie d'un message DHCP comporte dans l'ordre :

7 champs techniques (sur 12 octets) d'identification (code d'opération, etc.) ;
4 champs d'adresse IPv4 (32 bits chacun) qui contiennent les informations essentielles du message :

c-i-addr est l'adresse du client DHCP au moment de l'émission du message – toujours renseignée par le client lui‑même conformément à sa configuration courante (et non pas sa future configuration) ;
y-i-addr est l'adresse offerte par le serveur DHCP ;
s-i-addr est l'adresse du serveur DHCP ;
g-i-addr est l'adresse de la passerelle qui joue éventuellement le rôle de relais DHCP (cf. infra ) ;

sachant que dans un message de découverte, faute de connaissance, le client DHCP renseigne systématiquement l'adresse IP spéciale 0.0.0.0 pour tous ces champs ;

un champ de 16 octets (128 bits) c-haddr pour l'adresse physique de l'interface réseau du client DHCP.

Lorsqu'il s'agit d'une adresse MAC codée sur 6 octets (cf. chap. R1‑III ), les 10 derniers octets du champ sont mis à zéro.
La longueur de cette adresse est justement codée dans l'octet technique h‑len.
Cette adresse est requise dans le message dans l'éventualité où le serveur DHCP mettrait en œuvre un filtrage des hôtes via leur adresse physique.

Quant aux autres champs de cette première partie – le nom d'hôte du serveur (64 octets) et le nom du fichier de démarrage (128 octets) – ce sont des héritages du protocole BOOTP (cf. supra ). Dans le cadre du protocole DHCP, ces 192 octets sont tous mis à zéro.

La deuxième partie d'un message DHCP commence toujours le magic cookie W 0x 63 82 53 63. C'est un nombre sans signification particulière qui permet seulement de repérer sans équivoque le début de cette partie du message (c'est un héritage du protocole BOOTP).

Ensuite, il faut savoir que les paramètres du protocole DHCP renseignées dans les divers champs d'option ne sont pas facultatives pour le déroulement du protocole – contrairement à ce que pourrait laisser penser le mot « option ». Ce sont des informations essentielles qui viennent compléter celles de la première partie. Elles sont numérotées. À titre d'exemple, on a :

l'option nº 51 qui précise la durée du bail de la configuration offerte par le serveur DHCP ;
l'option nº 53 qui précise le type de message DHCP (découverte, offre, etc.).

Champs techniques d'identification d'un message DHCP

Les champs techniques codés au début d'un message DHCP regroupent des paramètres techniques pour mettre en œuvre la transaction (les échanges de messages) entre le client et le serveur.

Pour certains de ces champs, les valeurs initialement définies dans la RFC 1700 , maintenant obsolète, sont publiées dans une base de données de l'IANA .

op (operation code) ne peut ici prendre que deux valeurs parmi les mêmes que celles définies pour le protocole ARP :

1 (REQUEST), c'est‑à‑dire si le message est émis par le client (discover, request…) ;
2 (REPLY) si le message est émis par le serveur (offer, ack, nack…) ;

Cette valeur permet ensuite de déterminer les numéros de port d'émission et de réception dans l'en‑tête du datagramme UDP qui encapsule le message DHCP.

Par ailleurs, cette valeur est complétée par celle du champ d'option nº 53 qui code exactement le type de message envoyé (discover, offer, etc.)

h-type (hardware address type) code la technologie de l'interface réseau pour laquelle le client DHCP demande une configuration. Les valeurs sont là encore basées sur celles définies pour le protocole ARP mais, par défaut, pour presque toutes les technologies récentes (Ethernet, Wi‑Fi) on a la valeur :

1 (historiquement pour la technologie Ethernet 10 Mb/s).

h-len (hardware address length) code le nombre d'octets de l'adresse physique de l'interface réseau du client DHCP. En particulier, il prend la valeur 6 s'il s'agit d'une adresse MAC au format EUI‑48 (48 bits, donc 6 octets, cf. chap. R1‑III ).

Cette valeur permet ensuite de récupérer sans difficulté l'adresse elle‑même, codée dans le champ c-h-addr du message DHCP (cf. supra ).

hops (hardware address length) code le nombre de routeurs traversés par le message (on parle de « sauts »). Initialisé à 0 par l'émetteur du message, il est incrémenté par toute interface de routeur jouant le rôle de relais DHCP – cf. infra .
x-id (transaction identifier), codé sur 32 bits, est un nombre aléatoire entier positif généré par le client DHCP pour identifier toute nouvelle transaction (discover, renew, rebind).

En effet, comme les messages sont diffusés en broadcast, cela permet aux clients comme aux serveurs de ne pas confondre les différentes transactions simultanément en cours.

secs (seconds elapsed), codé sur 16 bits, est initialisé à 0 par le client au début de toute nouvelle transaction (discover, renew, rebind).

Dans les messages suivants de la transaction (request), le client incrémente cette valeur de l'écoulement des secondes mesuré avec son horloge.

flags (mot binaire constitué de drapeaux ayant chacun une signification particulière), codé sur 16 bits, est pour le moment très peu exploité. Il doit être mis à zéro, sauf le bit le plus à gauche, dit bit de broadcast. Le client met sa valeur à :

1 (donc la valeur 0x8000 pour le champ tout entier) pour indiquer au serveur qu'il attend un réponse en broadcast ;
0 (donc la valeur 0x0000 pour le champ tout entier) pour indiquer au serveur qu'il peut recevoir une réponse en unicast

Options du protocole DHCP

Le champ d'options d'un message DHCP reprend le même format que celui du protocole BOOTP, appelé vendor extensions.

Ce format se compose d'un nombre variables de mots binaires qui adoptent le format générique détaillé en figure ci‑contre, où :

code (1 octet) indique le numéro d'option, compris entre 0 et 255, sachant que ces deux valeurs extrêmes sont spéciales

l'option nº 0 sert à intercaler des octets nuls (padding) pour faire respecter des contraintes d'alignement aux options significatives ;
l'option nº 255 (0xFF) marque la fin des options (end mark) ;

length (1 octet) indique le nombre n d'octets de la partie variable à suivre dans le mot binaire ;
les n octets suivants – variable part – codent les informations spécifiques de l'option.

Toutes les options sont détaillées dans la RFC 2132 . Celles spécifiques au protocole DHCP portent des numéros compris entre 50 à 67. En particulier, on a :

l'option nº 50, de longueur 4, qui code l'adresse IP demandée par le client DHCP s'il en possédait déjà une auparavant dans le réseau ;
l'option nº 51, de longueur 4, qui code la durée de bail de la configuration offerte par le serveur DHCP ;
L'option nº 53, de longueur 1, qui code le type de message DHCP (discover 1, offer 2, request 3, decline 4, ack 5 etc.).
Les options nº 58 et 59, chacune de longueur 4 (32 bits), qui codent respectivement sous la forme d'entiers non signés les durées T1 et T2 au delà desquelles le client doit enclencher les transactions de renouvellement (renewing et rebinding – cf. supra ).

D'autres options communes avec le protocole BOOTP (dites vendor extensions) sont également exploitées par le protocole DHCP, notamment :

l'option nº 1, de longueur 4, qui code le masque de (sous)‑réseau (cf. chap. R‑III ) qu'offre le serveur DHCP pour la configuration de l'interface réseau du client DHCP ;
l'option nº 6, de longueur variable (multiple de 4), qui code les adresses IP des résolveurs DNS dans l'ordre de priorité d'utilisation (serveur primaire puis secondaire – cf. chap. R2‑I ) pour la configuration de l'interface réseau du client DHCP.

Pour un panorama général des options, on pourra consulter cette page web W.

Le protocole d'auto‑configuration en liaison locale

En cas de non‑réponse aux messages DHCP émis par une interface (par exemple, parce que le serveur ou l'un de ses relais est inaccessible, défaillant…), le système d'exploitation de la machine (ou le programme utilisateur de la carte à microcontrôleur) peut l'auto‑configurer en lui attribuant une adresse IP privée spéciale dite de liaison locale W (local‑link address) dans un bloc d'adresses réservé spécialement par l'IANA.

Ce protocole d'auto‑configuration qui est défini par la RFC 3297 de 2005. Il est également désigné :

automatic private IP addressing (APIPA) dans les systèmes d'exploitation Windows ;
stateless address autoconfiguration en IPv6…

Les adresses réservées sont dite de liaison locale parce qu'elles ne sont pas routables, ni sur l'Internet, ni même dans un réseau local. Elles permettent aux interfaces de communiquer seulement dans leur segment immédiat (déployé par des switchs) – ce qui est déjà mieux que rien.

En IPv4, il s'agit du bloc 169.254.0.0/16.
En IPv6, il s'agit du bloc fe80::/10.

La non‑routabilité des adresses de liaison locale s'explique par le fait qu'il faut garantir l'absence de conflit sur les adresses attribuées par ce protocole. Or en cas de défaillance du service DHCP, il y a toutes les chances que plusieurs machines du réseau local se retrouvent simultanément dans la même situation d'échec et de procéder à leur auto‑configuration, d'où un risque de conflit.

Lorsqu'une machine auto‑configure une de ses interfaces, elle doit donc vérifier en broadcast que l'adresse qu'elle choisie n'est pas déjà utilisée. Pour ne pas surcharger la bande passante du réseau, il est raisonnable de limiter la diffusion au segment du réseau dans lequel elle est hébergée, donc sans recourir à des relais.

Paramétrage d'une interface réseau en client DHCP

Généralités

Rappelons (cf. chap. R1‑III ) que le paramétrage d'une interface réseau s'effectue au niveau de son système d'exploitation ou de son programme utilisateur si la machine hôte est une carte à microcontrôleur.

En règle générale, toutes les machines informatiques destinées au grand public (ordinateurs fixes ou portables, smartphones, imprimantes, routeur Wi‑Fi, etc.) sont paramétrées par défaut en client DHCP, et ce pour des raisons évidentes de simplicité de mise en service et d'utilisation basique.

Avec un système neuf ou « fraîchement » installé, il n'y a donc en général aucun paramétrage à effectuer pour activer le client DHCP.

Néanmoins, tout technicien réseau doit savoir effectuer un tel paramétrage dans tous les cas de figure. Avec un ordinateur, on peut procéder au choix :

très intuitivement, via des fenêtres de dialogue ;
de façon plus experte, mais plus efficacement, par des commandes en ligne dans un terminal ;
et, pour les systèmes Linux, dans un fichier de script.

Cas d'un PC Windows

Via l'interface graphique du système (GUI)

Dans le cas d'un PC sous Windows 10, il existe plusieurs manières d'accéder à la fenêtre de dialogue de paramétrage des interfaces réseau :

soit via le panneau de configuration, en cliquant sur l'icône Réseau et Internet ;
soit via la zone de notification (à droite dans la barre de tâche), en cliquant sur l'icône du réseau puis sur Paramètres réseau & Internet.

Dans cette fenêtre de dialogue, pour avoir accès à toutes les interfaces réseau, il faut choisir dans les Paramètres réseau avancés l'option :
Modifier les options d'adaptateur

S'ouvre alors une fenêtre où chaque interface apparaît comme une icône. En faisant un clic‑droit sur l'icône d'une carte réseau, et en sélectionnant Propriétés dans le menu contextuel, on ouvre une fenêtre avec un onglet Gestion de réseau.

On doit alors sélectionner l'élément :
☑ ⫠ Protocole Internet version 4 (TCP/IPv4)
et cliquer sur le bouton Propriétés pour ouvrir la fenêtre de paramétrage de l'interface en IPv4.

Dans cette fenêtre, il suffit alors de cocher l'option :
⦿ Obtenir une adresse IP automatiquement
pour paramétrer l'interface en client DHCP.

Via un terminal de commandes en ligne

On peut effectuer exactement la même action que ci‑dessus dans un terminal de commandes en ligne exécuté en qualité d'administrateur, avec la commande netsh W (network shell). Il suffit de saisir :

netsh interface ipv4 set address name="Ethernet" dhcp

Cas d'un système Linux

Dans le cas d'un PC à système Linux, on dispose de méthodes similaires de paramétrage qu'avec Windows. Seule la présentation change, selon la distribution (Debian, Ubuntu, Mint, Fedora, etc.) et le bureau adopté (Gnome, Cinnamon, Xfce, etc. ).

Ainsi, avec Linux Mint et l'environnement de bureau Cinnamon, en accédant aux paramètres d'une connexion réseau via le gestionnaire de réseaux (accès rapide à droite dans la barre de tâches), après avoir sélectionné la rubrique IPv4, on peut imposer une configuration dynamique simplement par un choix dans un menu déroulant (cf. la capture d'écran ci‑contre pour une connexion filaire Ethernet).

Cas d'une carte Raspberry Pi

Pour mémoire, dans le cas d'une carte Raspberry Pi avec un système basé sur une distribution Debian 11 ou antérieure, la configuration de l'interface Ethernet eth0 est effectuée au démarrage en fonction du paramétrage codé dans le fichier /etc/dhcpcd.conf (cf. chap. R1‑III ).

Pour paramétrer cette interface en client DHCP, il suffit de laisser ou mettre en commentaires (par ajout du symbole # en tête de ligne) toutes les lignes de configuration statique, comme sur la capture d'écran ci‑contre (lignes n° 44 à 48), sachant que c'est le choix par défaut du constructeur, donc en principe, il n'y a rien à faire.

Dans le fichier /etc/dhcpcd.conf, on peut même prévoir une configuration statique de secours – en anglais fallback – en cas d'échec de la transaction de configuration DHCP (typiquement parce que le serveur DHCP est inaccessible, la configuration mal définie, ou autre cause…).

Pour cela, il faut dé‑commenter et renseigner les lignes prévues à cet effet en codant les différents éléments de la configuration statique souhaitée (adresse de l'interface et masque du réseau, adresse de la passerelle par défaut, des DNS primaire et secondaire – cf. la capture d'écran ci‑contre, lignes n° 51 à 55 et n° 58 & 59).

Cas d'une carte à microcontrôleur

Dans le cas d'une carte à microcontrôleur, on rappelle qu'il est vivement recommandé de faire appel à une bibliothèque de fonctions spécialisées pour mettre en œuvre les communications réseau (cf. chap. R1‑III ).

Sur une telle carte, il n'est pas aussi simple que pour une carte Raspberry Pi de configurer une interface réseau en client DHCP, puisqu'il faut explicitement coder des instructions appropriées dans le programme utilisateur. Néanmoins, on trouve des exemples basiques dans les documentations disponibles sur l'Internet.

Rappelons que dans un programme pour carte Arduino équipée d'un shield Ethernet jouant le rôle d'interface réseau, on appelle les fichiers d'en‑tête SPI.h et Ethernet.h (cf. chap. R1‑III ).

Pour configurer cette interface en client DHCP, il suffit d'appeler la méthode Ethernet.begin A avec un seul argument : l'adresse MAC inscrite sur l'étiquette en dessous du shield. C'est cet appel qui paramètre implicitement l'interface en client DHCP.

De plus, lorsqu'elle est appelée avec pour seul argument l'adresse MAC, la méthode Ethernet.begin retourne la valeur :

1 si la transaction d'initialisation déclenchée par son appel s'achève sur un succès (c'est‑à‑dire avec la réception d'un message ack du serveur) ;
0 sinon.

C'est pourquoi il est aussi possible de coder le programme de connexion au réseau local comme ci‑dessous :

#include <SPI.h>
#include <Ethernet.h>

const int SPI_SS_ETHERNET_PIN = 10; // choice may depends of the Arduino board  
byte mac[] = {0x90, 0xA2, 0xDA, 0x0D, 0x15, 0x43};

void setup()
{
  Ethernet.init(SPI_SS_ETHERNET_PIN);
  delay(1000);
  if (Ethernet.linkStatus() != LinkON) {
    Serial.println("Ethernet link off! Check connectivity and reboot program...");
    while (1);
  }

  Serial.begin(115200);
  Serial.println();
  Serial.print("Network connection");
  Serial.flush();

  if (!Ethernet.begin(mac)) {
    Serial.print(" .");
    delay(1000);
    if (millis() > 10000) {
      Serial.println("DHCP protocol failed! Try static configuration...");
      while (1);
    }
  }

  Serial.println(" successful :)");
  Serial.print("IPv4    = "); Serial.println(Ethernet.localIP());
  Serial.print("Gateway = "); Serial.println(Ethernet.gatewayIP());
  Serial.print("DNS     = "); Serial.println(Ethernet.dnsServerIP());
  Serial.println(); 
  Serial.flush();
}

void loop()
{
  //...
  switch(Ethernet.maintain()) {
    case 1: case 3: 
      Serial.println("DHCP has ended without renewing or rebinding :(");
      break;
    case 2: case 4: 
      Serial.println("DHCP was renewed or rebound successfully :)");
      break;
  }
}

Remarques. Pour garantir la persistance de la connexion, il est nécessaire de coder dans la fonction loop l'instruction Ethernet.maintain(); A. Elle commande au client DHCP de déclencher aux moments opportuns – c'est‑à‑dire conformément à la norme – des transactions de renouvellement (cf. supra ).

Un appel de la méthode Ethernet.maintain retourne respectivement la valeur :

0 si rien ne s'est passé, c'est‑à‑dire qu'aucune transaction n'a été déclenchée car ce n'était pas le moment ;
1 si une transaction de renewing vient de s'achever sur un échec ;
2 si une transaction de renewing vient de s'achever sur un succès ;
3 si une transaction de rebinding vient de s'achever sur un échec ;
4 si une transaction rebinding vient de s'achever sur un succès.

Architecture matérielle et logicielle d'un serveur DHCP

Cas d'un PAN ou d'un petit LAN

Dans un PAN (personnal area network – cf. chap. R1‑II ) ou d'un LAN de petite taille (typiquement, un réseau domestique), même si le nombre de machines est faible, le service DHCP est particulièrement utile. Il permet de faire communiquer sur le réseau – et sur l'Internet via la passerelle d'accès – toute machine paramétrée en client DHCP, et ce dès son raccordement par câble ou liaison sans‑fil. Dans le cadre d'un usage basique, cela évite de recourir systématiquement aux compétences d'un administrateur réseau.

En général, toute box d'abonné à l'Internet intègre un serveur DHCP. De plus, son service est activé par défaut avec, typiquement :

pour son interface interne, une adresse IPv4 statique comme 192.168.0.1 ou 192.168.0.254 – ce sont respectivement la première et la dernière adresse du segment 192.168.0.0/24 ;

(cette interface joue le rôle de passerelle par défaut dans le réseau local) ;

une plage de quelques dizaines d'adresses dynamiques consécutives dans le segment.

La prise en charge des hôtes nomades du réseau (smartphones, tablettes, imprimante réseau sans‑fil, etc.) nécessite en plus :

l'activation de la fonction routeur Wi‑Fi intégrée à la box ;
et, si une fonction d'authentification est activée, la communication à l'utilisateur de l'hôte nomade de la clef de sécurité (mot de passe pour la connexion Wi‑Fi).

En général, c'est le paramétrage par défaut adopté par les FAI, toujours dans une perspective de facilité d'usage pour le grand public, tout en procurant une sécurité suffisante.

Paramétrage du serveur DHCP intégré à une box FAI

En général, une box d'abonné à l'Internet peut être contrôlée via une page web dynamique à accès distant par mot de passe (communiqué seulement à l'abonné). Bien que souvent rudimentaire, cette solution donne accès aux réglages de base et propose quelques fonctions avancées.

Parmi les réglages de base, on a notamment:

l'activation-désactivation du point d'accès Wi‑Fi ;
le choix de la clef d'authentification ;
le choix de l'adresse IP statique privée de la box dans un segment prédéfini (typiquement 192.168.0.0/24) ;
la délimitation d'une plage d'adresses dynamiques consécutives dans le segment prédéfini (cf. la capture d'écran ci‑contre).

Parmi les fonctions avancées, on peut également attribuer à une interface une adresse IP assortie d'un bail permanent (adresse IP dite fixe – cf. supra ). L'attribution se fait par l'association d'une adresse IP et d'une adresse MAC (celle de l'interface).

Par rapport à une adresse IP statique, une adresse IP fixe présente l'avantage de pouvoir être configurée de façon centralisée sur le serveur DHCP et non pas localement sur la machine hébergeant l'interface à laquelle l'adresse IP est attribuée.

Néanmoins, il faut avoir conscience que plus on recourt à cette possibilité, plus on mobilise d'adresses IP définitivement. Sur un réseau personnel, cela ne pose en principe aucun problème, mais ce n'est pas forcément le cas sur un LAN comportant un grand nombre de machines (grande entreprise, université, etc.)

Le contrôle de la box par une page web à accès distant par mot de passe présente plusieurs avantages par rapport aux anciennes solutions implémentée par une page web locale embarquée dans la box (accessible via son adresse IP statique privée) et une authentification par bouton‑poussoir.

D'une part, le contrôle de la box est opérable depuis n'importe quel lieu géographique, et non pas seulement à domicile ;
D'autre part, l'accès par mot de passe, dès lors que ce dernier n'est pas divulgué, prévient le contrôle par tout tiers (intrus, personne non autorisée).

Cas d'un LAN segmenté

Dans le cas d'un LAN, pas forcément très grand, mais structuré en plusieurs segments ou VLAN communiquant via des routeurs, plusieurs solutions matérielles sont envisageables.

On peut notamment décentraliser le service DHCP en mettant en place un serveur DHCP dans chaque segment – et typiquement, en activant ce service dans les routeur‑passerelle respectifs des segments.

Économique, cette solution est en revanche moins commode à administrer puisqu'il faut se connecter à chaque routeur pour définir ou modifier les plages d'adresses dynamiques.

Au contraire, on peut aussi centraliser le service DHCP sur un seul serveur – voire, pour les architectures les plus sollicitées, un cluster de serveurs en redondances et avec un système de basculement (failover).

De plus, elle nécessite la mise en place d'agents relais DHCP pour permettre aux messages DHCP de traverser les routeurs du réseaux (cf. infra ).

Sans surprise, cette solution a des avantages et inconvénients diamétralement opposés à ceux de la précédente.

Notion d'agent relais DHCP

Rappelons que pour prévenir toute saturation de la bande passante sur les réseaux, l'adresse IP 255.255.255.255 de broadcast limité (cf. chap. R1‑III ) employée dans les transactions d'initialisation et de rebinding n'est pas diffusée par les routeurs .

Donc a priori, dans une architecture segmentée à service DHCP centralisé, les messages discover d'un client DHCP ne parviendront jamais à atteindre le serveur DHCP : ils ne passeront pas la barrière du routeur‑passerelle du sous‑réseau matériel dans lequel la machine est physiquement raccordée.

Une solution usuellement retenue consiste, pour chaque segment du réseau n'hébergeant pas de serveur DHCP à paramétrer l'interface de sa passerelle par défaut en agent relais DHCP W.

Ce paramétrage de l'interface du routeur en agent relais DHCP est opéré en le plus souvent en ligne de commande avec une commande spéciale qui doit désigne l'adresse IP du serveur DHCP.

Par exemple, dans le cas d'un routeur Cisco, la commande est de la forme :
ip helper-address adresse IP serveur DHCP

Comme un serveur DHCP, un agent relais a son port nº 67 actif. Lorsqu'un message DHCP diffusé en broadcast lui parvient, il le relaie vers le serveur DHCP en unicast, en opérant une substitution d'adresses dans l'en‑tête du datagramme IP encapsulant le message :

à la place de l'adresse d'émission spéciale 0.0.0.0, il inscrit son adresse ;
à la place de l'adresse de diffusion restreinte 255.255.255.255, il inscrit l'adresse du serveur DHCP ;

De plus, l'agent relais indique son adresse dans le champ g-i-addr du message DHCP (cf. supra ).

En retour, le serveur DHCP répond toujours en unicast à l'agent relais DHCP, ce qui évite de saturer la bande passante du segment où il est hébergé. La diffusion large ne reprend que lorsque l'agent relais reçoit la réponse du serveur et doit la procéder en broadcast pour atteindre le client DHCP.

Notion de cluster DHCP

Dans un LAN structuré en multiples segments avec un service DHCP centralisé, il serait risqué de n'équiper le réseau que d'un seul serveur DHCP. En effet, toute panne de ce dernier causerait peu à peu, avec l'expiration des baux en cours, le blocage complet du réseau.

Le service DHCP est donc souvent mis en œuvre sur un cluster DHCP, c'est‑à‑dire un ensemble de serveur fonctionnant en redondance pour garantir la continuité de service.

Sans entrer dans les détails, on interpose dans ou entre la passerelle d'accès au cluster et les serveurs eux‑même un dispositif de gestion de la redondance avec :

un système de miroirs des bases de données d'adresse entre un serveur maître et un ou plusieurs serveurs esclaves ;
un système de basculement (DHCP failover) pour passer à un serveur secondaire en cas de panne du serveur principal.

Pour plus de précisions, on pourra consulter cette référence .

Logiciels serveurs DHCP

On peut implémenter un serveur DHCP de deux façons :

soit comme un composant logiciel intégré à un système d'exploitation de machine de type serveur, mais aussi un routeur, ;
soit comme un logiciel applicatif s'exécutant sur un système d'exploitation ; le plus souvent, ce dernier est couplé à un résolveur DNS (cf. chap. R2‑I ).

Les systèmes d'exploitation les plus courants disposent tous d'un composant DHCP.

Microsoft Windows Server intègre une implémentation DHCP propriétaire ;
En principe sur toute distribution de Linux, on peut installer des paquets libres de droits et open‑source pour doter la machine de la fonctionnalité de serveur DHCP, notamment ceux développés par l'ISC (cf. chap. R1‑I ) . Par exemple, on a isc-dhcp-server pour Ubuntu ).

Parmi les logiciels applicatifs serveurs DHCP, on peut citer :

Cisco network registrar développé par l'entreprise Cisco ;
VitalQIP développé par l'entreprise Nokia.