Protocole de configuration dynamique de l'hôte

Le protocole DHCP ( Dynamic Host Configuration Protocol ) est un protocole de gestion de réseau utilisé sur les réseaux IP ( Internet Protocol ) pour attribuer automatiquement des adresses IP et d'autres paramètres de communication aux périphériques connectés au réseau à l'aide d'une architecture client-serveur .

Cette technologie élimine la nécessité de configurer manuellement les périphériques réseau individuellement et se compose de deux composants réseau, un serveur DHCP réseau installé de manière centralisée et des instances clientes de la pile de protocoles sur chaque ordinateur ou périphérique. Lorsqu'il est connecté au réseau, et périodiquement par la suite, un client demande un ensemble de paramètres au serveur via DHCP.

Le protocole DHCP peut être mis en œuvre sur des réseaux de tailles diverses, allant des réseaux résidentiels aux grands réseaux de campus et aux réseaux régionaux de FAI. De nombreux routeurs et passerelles résidentielles disposent d'une fonction de serveur DHCP. La plupart des routeurs de réseau résidentiel reçoivent une adresse IP unique au sein du réseau du FAI. Au sein d'un réseau local, un serveur DHCP attribue une adresse IP locale à chaque périphérique.

Les services DHCP existent pour les réseaux exécutant le protocole Internet version 4 (IPv4), ainsi que la version 6 ( IPv6 ). La version IPv6 du protocole DHCP est communément appelée DHCPv6 .

Le protocole RARP (Reverse Address Resolution Protocol ) a été défini en 1984 pour la configuration de périphériques simples, tels que des stations de travail sans disque , avec une adresse IP appropriée. Agissant dans la couche de liaison de données , il a rendu la mise en œuvre difficile sur de nombreuses plates-formes de serveur. Il nécessitait qu'un serveur soit présent sur chaque liaison réseau individuelle. RARP a été remplacé par le protocole Bootstrap (BOOTP) défini en septembre 1985. Cela a introduit le concept d'agent relais, qui a permis la transmission de paquets BOOTP sur les réseaux, permettant à un serveur BOOTP central de servir des hôtes sur de nombreux sous-réseaux IP.

DHCP a été défini pour la première fois en octobre 1993. Il est basé sur BOOTP, mais peut allouer dynamiquement des adresses IP à partir d'un pool et les récupérer lorsqu'elles ne sont plus utilisées. Il peut également être utilisé pour fournir une large gamme de paramètres de configuration supplémentaires aux clients IP, y compris des paramètres spécifiques à la plate-forme.

Quatre ans plus tard, le type de message DHCPINFORM (utilisé pour WPAD ) et d'autres petits changements ont été ajoutés. Cette définition, datant de 1997, reste le cœur de la norme pour les réseaux IPv4.

DHCPv6 a été initialement défini en 2003. Après des mises à jour par de nombreuses RFC ultérieures, sa définition a été remplacée en 2018, où la délégation de préfixe et l'autoconfiguration d'adresse sans état ont désormais été fusionnées.

Le protocole Internet (IP) définit la manière dont les appareils communiquent au sein et entre les réseaux locaux sur Internet. Un serveur DHCP peut gérer les paramètres IP des appareils sur son réseau local, par exemple en attribuant des adresses IP à ces appareils de manière automatique et dynamique.

Le protocole DHCP fonctionne selon le modèle client-serveur . Lorsqu'un ordinateur ou un autre périphérique se connecte à un réseau, le logiciel client DHCP envoie une requête de diffusion DHCP demandant les informations nécessaires. N'importe quel serveur DHCP du réseau peut traiter la requête. Le serveur DHCP gère un pool d'adresses IP et des informations sur les paramètres de configuration du client, tels que la passerelle par défaut , le nom de domaine , les serveurs de noms et les serveurs de temps . À la réception d'une requête DHCP, le serveur DHCP peut répondre avec des informations spécifiques pour chaque client, telles que configurées précédemment par un administrateur, ou avec une adresse spécifique et toute autre information valide pour l'ensemble du réseau et pour la période de validité de l'allocation ( bail ). Un client DHCP interroge généralement ces informations immédiatement après le démarrage , puis périodiquement avant l'expiration des informations. Lorsqu'un client DHCP actualise une attribution, il demande initialement les mêmes valeurs de paramètres, mais le serveur DHCP peut attribuer une nouvelle adresse en fonction des stratégies d'attribution définies par les administrateurs.

Sur les réseaux de grande taille constitués de plusieurs liaisons, un seul serveur DHCP peut desservir l'ensemble du réseau lorsqu'il est assisté par des agents relais DHCP situés sur les routeurs interconnectés. Ces agents relaient les messages entre les clients DHCP et les serveurs DHCP situés sur différents sous-réseaux.

Selon l'implémentation, le serveur DHCP peut disposer de trois méthodes d'allocation d'adresses IP :

Allocation dynamique

Un administrateur réseau réserve une plage d'adresses IP pour DHCP et chaque client DHCP sur le réseau local est configuré pour demander une adresse IP au serveur DHCP lors de l'initialisation du réseau. Le processus de demande et d'octroi utilise un concept de bail avec une période de temps contrôlable, permettant au serveur DHCP de récupérer puis de réattribuer les adresses IP qui ne sont pas renouvelées.

Attribution automatique

Le serveur DHCP attribue de manière permanente une adresse IP à un client demandeur à partir d'une plage définie par un administrateur. Cela s'apparente à une allocation dynamique, mais le serveur DHCP conserve une table des attributions d'adresses IP passées, de sorte qu'il peut attribuer de préférence à un client la même adresse IP que celle qu'il avait précédemment.

Affectation manuelle

Cette méthode est également appelée allocation DHCP statique , allocation d'adresse fixe , réservation et liaison d'adresse MAC/IP . Un administrateur mappe un identifiant unique (un identifiant client ou une adresse MAC ) pour chaque client à une adresse IP, qui est proposée au client demandeur. Les serveurs DHCP peuvent être configurés pour recourir à d'autres méthodes en cas d'échec.

Les services DHCP sont utilisés pour le protocole Internet version 4 (IPv4) et IPv6 . Les détails du protocole pour IPv4 et IPv6 diffèrent suffisamment pour qu'ils puissent être considérés comme des protocoles distincts. Pour le fonctionnement IPv6, les périphériques peuvent également utiliser l'autoconfiguration d'adresse sans état . Les hôtes IPv6 peuvent également utiliser l'adressage local de liaison pour réaliser des opérations limitées à la liaison réseau locale.

Le DHCP utilise un modèle de service sans connexion , utilisant le protocole UDP ( User Datagram Protocol ). Il est implémenté avec deux numéros de port UDP pour ses opérations qui sont les mêmes que pour le protocole bootstrap ( BOOTP ). Le serveur écoute sur le port UDP numéro 67 et le client écoute sur le port UDP numéro 68.

Les opérations DHCP se divisent en quatre phases : découverte du serveur, offre de location IP, demande de location IP et accusé de réception de location IP. Ces étapes sont souvent abrégées en DORA (découverte, offre, demande et accusé de réception).

L'opération DHCP commence par la diffusion d'une demande par les clients. Si le client et le serveur se trouvent dans des domaines de diffusion différents , un assistant DHCP ou un agent relais DHCP peut être utilisé. Les clients demandant le renouvellement d'un bail existant peuvent communiquer directement via UDP unicast , car le client dispose déjà d'une adresse IP établie à ce stade. De plus, il existe un indicateur BROADCAST (1 bit dans un champ d'indicateurs de 2 octets, où tous les autres bits sont réservés et donc définis sur 0) que le client peut utiliser pour indiquer de quelle manière (diffusion ou monodiffusion) il peut recevoir le DHCPOFFER : 0x8000 pour la diffusion, 0x0000 pour la monodiffusion. En général, le DHCPOFFER est envoyé via monodiffusion. Pour les hôtes qui ne peuvent pas accepter les paquets monodiffusion avant que les adresses IP ne soient configurées, cet indicateur peut être utilisé pour contourner ce problème.

Le client DHCP diffuse un message DHCPDISCOVER sur le sous-réseau du réseau en utilisant l'adresse de destination 255.255.255.255 (diffusion limitée) ou l'adresse de diffusion spécifique du sous-réseau (diffusion dirigée). Un client DHCP peut également demander une adresse IP dans le DHCPDISCOVER, que le serveur peut prendre en compte lors de la sélection d'une adresse à proposer.

Par exemple, si HTYPE est défini sur 1, pour spécifier que le support utilisé est Ethernet , HLEN est défini sur 6 car une adresse Ethernet (adresse MAC) a une longueur de 6 octets. CHADDR est défini sur l'adresse MAC utilisée par le client. Certaines options sont également définies.

Lorsqu'un serveur DHCP reçoit un message DHCPDISCOVER d'un client, qui est une demande de location d'adresse IP, le serveur DHCP réserve une adresse IP pour le client et fait une offre de location en envoyant un message DHCPOFFER au client. Ce message peut contenir l' ID client du client (option 61, contenant une valeur unique, traditionnellement une adresse MAC), l'adresse IP que le serveur propose, le masque de sous-réseau, la durée du bail et l'adresse IP du serveur DHCP qui fait l'offre. Le serveur DHCP peut également prendre en compte l'adresse MAC au niveau matériel (comme spécifié dans le champ CHADDR). Ce champ doit être utilisé pour identifier le client, si aucun ID client n'est fourni dans le paquet DHCP.

Le serveur DHCP détermine la configuration en fonction de l'adresse matérielle du client telle que spécifiée dans le champ CHADDR (adresse matérielle du client). Dans l'exemple suivant, le serveur ( 192.168.1.1 ) spécifie l'adresse IP du client dans le champ YIADDR (votre adresse IP).

En réponse à l'offre DHCP, le client répond par un message DHCPREQUEST, diffusé au serveur, demandant l'adresse proposée. Un client peut recevoir des offres DHCP de plusieurs serveurs, mais il n'acceptera qu'une seule offre DHCP.

Le client doit envoyer l' option d'identification du serveur dans le message DHCPREQUEST, indiquant le serveur dont le client a sélectionné l'offre. Lorsque d'autres serveurs DHCP reçoivent ce message, ils retirent toutes les offres qu'ils ont faites au client et renvoient l'adresse IP qu'ils ont proposée au pool d'adresses disponibles.

Lorsque le serveur DHCP reçoit le message DHCPREQUEST du client, le processus de configuration entre dans sa phase finale. La phase d'accusé de réception implique l'envoi d'un paquet DHCPACK au client. Ce paquet inclut la durée du bail et toute autre information de configuration que le client aurait pu demander. À ce stade, le processus de configuration IP est terminé.

Le protocole attend du client DHCP qu'il configure son interface réseau avec les paramètres négociés.

Lorsque le serveur réutilise une adresse IP de son pool, il peut d'abord vérifier (en utilisant ping ) si elle n'est pas déjà prise. Cela peut se produire si un hôte est configuré manuellement avec une adresse IP qui se trouve dans la portée DHCP.

Avant de réclamer une adresse IP, le client doit sonder l'adresse nouvellement reçue (par exemple avec ARP ), afin de trouver s'il existe un autre hôte présent sur le réseau avec l'adresse IP proposée. S'il n'y a pas de réponse, cette adresse n'est pas en conflit avec celle d'un autre hôte, elle est donc libre d'être utilisée. Si cette sonde trouve un autre ordinateur utilisant cette adresse, le client doit diffuser un DHCPDECLINE au(x) serveur(s) DHCP.

Un client DHCP peut demander plus d'informations que celles envoyées par le serveur avec le DHCPOFFER d'origine. Le client peut également demander des données répétées pour une application particulière. Par exemple, les navigateurs utilisent DHCP Inform pour obtenir les paramètres de proxy Web via WPAD .

Le client envoie une requête au serveur DHCP pour libérer les informations DHCP et le client désactive son adresse IP. Comme les périphériques clients ne savent généralement pas quand les utilisateurs peuvent les débrancher du réseau, le protocole n'impose pas l'envoi de DHCP Release .

Un serveur DHCP peut fournir des paramètres de configuration facultatifs au client. La RFC 2132 décrit les options DHCP disponibles définies par l'IANA ( Internet Assigned Numbers Authority ) - PARAMÈTRES DHCP et BOOTP.

Un client DHCP peut sélectionner, manipuler et écraser les paramètres fournis par un serveur DHCP. Dans les systèmes de type Unix, ce raffinement au niveau du client s'effectue généralement en fonction des valeurs du fichier de configuration /etc/dhclient.conf .

Les options sont des chaînes d'octets de longueur variable. C'est ce qu'on appelle le codage type-longueur-valeur . Le premier octet est le code de l'option, le deuxième octet est le nombre d'octets suivants et les octets restants dépendent du code. Par exemple, l'option de type de message DHCP pour une offre apparaîtrait sous la forme 0x35, 0x01, 0x02, où 0x35 est le code 53 pour « type de message DHCP », 0x01 signifie qu'un octet suit et 0x02 est la valeur de « offre ».

Les tableaux suivants répertorient les options DHCP disponibles.

Ce tableau répertorie les types de messages DHCP, documentés dans les RFC 2132, RFC 3203, RFC 4388, RFC 6926 et RFC 7724. Ces codes correspondent à la valeur de l'extension DHCP 53, indiquée dans le tableau ci-dessus.

Il existe une option permettant d'identifier le fournisseur et les fonctionnalités d'un client DHCP. Les informations sont une chaîne de caractères ou d'octets de longueur variable dont la signification est spécifiée par le fournisseur du client DHCP. Une méthode par laquelle un client DHCP peut communiquer au serveur qu'il utilise un certain type de matériel ou de micrologiciel consiste à définir une valeur dans ses requêtes DHCP appelée identifiant de classe de fournisseur (VCI) (option 60).

La valeur sur laquelle cette option est définie donne au serveur DHCP une indication sur les informations supplémentaires requises dont ce client a besoin dans une réponse DHCP. Certains types de décodeurs configurent le VCI pour informer le serveur DHCP du type de matériel et des fonctionnalités du périphérique. Un point d'accès sans fil de campus Aruba , par exemple, fournit la valeur « ArubaAP » comme option 60 dans son message DHCPDISCOVER. Le serveur DHCP peut ensuite augmenter son DHCPOFFER avec une adresse IP d'un contrôleur sans fil Aruba dans l'option 43, afin que le point d'accès sache où s'enregistrer.

La définition d'un VCI par le client permet à un serveur DHCP de différencier les machines clientes et de traiter les demandes de leur part de manière appropriée.

L'option d'informations de l'agent de relais (option 82) spécifie le conteneur permettant de joindre des sous-options aux requêtes DHCP transmises entre un relais DHCP et un serveur DHCP.

Dans les petits réseaux, où un seul sous-réseau IP est géré, les clients DHCP communiquent directement avec les serveurs DHCP. Toutefois, les serveurs DHCP peuvent également fournir des adresses IP pour plusieurs sous-réseaux. Dans ce cas, un client DHCP qui n'a pas encore acquis d'adresse IP ne peut pas communiquer directement avec un serveur DHCP qui n'est pas sur le même sous-réseau, car la diffusion du client ne peut être reçue que sur son propre sous-réseau.

Afin de permettre aux clients DHCP sur des sous-réseaux non directement desservis par des serveurs DHCP de communiquer avec ces derniers, des agents relais DHCP peuvent être installés sur ces sous-réseaux. Un agent relais DHCP s'exécute sur un périphérique réseau, capable d'effectuer un routage entre le sous-réseau du client et le sous-réseau du serveur DHCP. Le client DHCP diffuse sur la liaison locale ; l'agent relais reçoit la diffusion et la transmet à un ou plusieurs serveurs DHCP à l'aide de la monodiffusion . Les adresses IP des serveurs DHCP sont configurées manuellement dans l'agent relais. L'agent relais stocke sa propre adresse IP, à partir de l'interface sur laquelle il a reçu la diffusion du client, dans le champ GIADDR du paquet DHCP. Le serveur DHCP utilise la valeur GIADDR pour déterminer le sous-réseau, puis le pool d'adresses correspondant, à partir duquel attribuer une adresse IP. Lorsque le serveur DHCP répond au client, il envoie la réponse à l'adresse GIADDR, à nouveau à l'aide de la monodiffusion. L'agent relais retransmet ensuite la réponse sur le réseau local, en utilisant la diffusion unique (dans la plupart des cas) vers la nouvelle adresse IP réservée, dans une trame Ethernet dirigée vers l'adresse MAC du client. Le client doit accepter le paquet comme le sien, même si cette adresse IP n'est pas encore définie sur l'interface. Directement après le traitement du paquet, le client définit l'adresse IP sur son interface et est prêt pour une communication IP régulière, immédiatement après.

Si l'implémentation de la pile IP du client n'accepte pas les paquets monodiffusion alors qu'il n'a pas encore d'adresse IP, le client peut définir le bit de diffusion dans le champ FLAGS lors de l'envoi d'un paquet DHCPDISCOVER. L'agent relais utilisera l' adresse IP de diffusion 255.255.255.255 (et l'adresse MAC du client) pour informer le client du DHCPOFFER du serveur.

La communication entre l'agent relais et le serveur DHCP utilise généralement un port UDP source et de destination de 67.

Un client DHCP peut recevoir ces messages d'un serveur :

• OFFRE DHCP
• DHCPACK
• DHCPNAK

Le client se déplace dans les états DHCP en fonction de la manière dont le serveur répond aux messages que le client envoie.

Le DHCP assure la fiabilité de plusieurs façons : renouvellement périodique, réattribution, et basculement. Les clients DHCP se voient attribuer des baux d'une durée déterminée. Les clients commencent à essayer de renouveler leurs baux une fois que la moitié de l'intervalle de bail a expiré. Ils le font en envoyant un message DHCPREQUEST en monodiffusion au serveur DHCP qui a accordé le bail d'origine. Si ce serveur est en panne ou inaccessible, il ne répondra pas au DHCPREQUEST . Cependant, dans ce cas, le client répète le DHCPREQUEST de temps en temps, donc si le serveur DHCP revient ou devient à nouveau accessible, le client DHCP réussira à le contacter et à renouveler le bail.

Si le serveur DHCP est inaccessible pendant une période prolongée, le client DHCP tentera de se lier à nouveau, en diffusant son DHCPREQUEST plutôt qu'en le diffusant en monodiffusion. Comme il est diffusé , le message DHCPREQUEST atteindra tous les serveurs DHCP disponibles. Si un autre serveur DHCP est en mesure de renouveler le bail, il le fera à ce moment-là.

Pour que la liaison fonctionne, lorsque le client contacte avec succès un serveur DHCP de secours, ce serveur doit disposer d'informations précises sur la liaison du client. Maintenir des informations de liaison précises entre deux serveurs est un problème complexe ; si les deux serveurs sont capables de mettre à jour la même base de données de bail, il doit exister un mécanisme pour éviter les conflits entre les mises à jour sur les serveurs indépendants. Une proposition de mise en œuvre de serveurs DHCP tolérants aux pannes a été soumise à l'Internet Engineering Task Force, mais n'a jamais été formalisée.

Si la réattribution échoue, le bail expirera éventuellement. Lorsque le bail expire, le client doit cesser d'utiliser l'adresse IP qui lui a été attribuée dans son bail. À ce moment-là, il redémarrera le processus DHCP depuis le début en diffusant un DHCPDISCOVERmessage. Puisque son bail a expiré, il acceptera toute adresse IP qui lui sera proposée. Une fois qu'il aura une nouvelle adresse IP (probablement d'un autre serveur DHCP), il pourra à nouveau utiliser le réseau. Cependant, comme son adresse IP a changé, toutes les connexions en cours seront interrompues.

La méthodologie de base du protocole DHCP a été développée pour les réseaux basés sur le protocole Internet version 4 (IPv4). Depuis le développement et le déploiement des réseaux IPv6 , le protocole DHCP a également été utilisé pour l'attribution de paramètres dans ces réseaux, malgré les fonctionnalités inhérentes au protocole IPv6 pour la configuration automatique des adresses sans état . La version IPv6 du protocole est désignée par DHCPv6 .

Le DHCP de base n'inclut aucun mécanisme d'authentification. De ce fait, il est vulnérable à diverses attaques. Ces attaques se répartissent en trois catégories principales :

• Serveurs DHCP non autorisés fournissant de fausses informations aux clients.
• Clients non autorisés accédant aux ressources.
• Attaques d'épuisement des ressources provenant de clients DHCP malveillants.

Comme le client n'a aucun moyen de valider l'identité d'un serveur DHCP, des serveurs DHCP non autorisés (communément appelés « DHCP malveillants ») peuvent être exploités sur les réseaux, fournissant des informations incorrectes aux clients DHCP. Cela peut servir soit à une attaque par déni de service, empêchant le client d'accéder à la connectivité réseau, soit à une attaque de l'homme du milieu . Comme le serveur DHCP fournit au client DHCP des adresses IP de serveur, telles que l'adresse IP d'un ou plusieurs serveurs DNS, un attaquant peut convaincre un client DHCP d'effectuer ses recherches DNS via son propre serveur DNS, et peut donc fournir ses propres réponses aux requêtes DNS du client. Cela permet à son tour à l'attaquant de rediriger le trafic réseau à travers lui-même, lui permettant d'écouter les connexions entre le client et les serveurs réseau qu'il contacte, ou de simplement remplacer ces serveurs réseau par les siens.

Étant donné que le serveur DHCP ne dispose d'aucun mécanisme sécurisé pour authentifier le client, les clients peuvent obtenir un accès non autorisé aux adresses IP en présentant des informations d'identification, telles que des identifiants client, qui appartiennent à d'autres clients DHCP. Cela permet également aux clients DHCP d'épuiser la réserve d'adresses IP du serveur DHCP : en présentant de nouvelles informations d'identification à chaque fois qu'il demande une adresse, le client peut consommer toutes les adresses IP disponibles sur une liaison réseau particulière, empêchant ainsi les autres clients DHCP d'obtenir le service.

DHCP fournit certains mécanismes pour atténuer ces problèmes. L'extension de protocole Relay Agent Information Option (généralement désignée dans l'industrie par son numéro réel, Option 82 ) permet aux opérateurs réseau d'attacher des balises aux messages DHCP lorsque ces messages arrivent sur le réseau de confiance de l'opérateur réseau. Cette balise est ensuite utilisée comme jeton d'autorisation pour contrôler l'accès du client aux ressources réseau. Étant donné que le client n'a pas accès au réseau en amont de l'agent relais, l'absence d'authentification n'empêche pas l'opérateur du serveur DHCP de s'appuyer sur le jeton d'autorisation.

Une autre extension, Authentication for DHCP Messages (RFC 3118), fournit un mécanisme d'authentification des messages DHCP. En 2002, cette extension n'avait pas été largement adoptée en raison des problèmes de gestion des clés pour un grand nombre de clients DHCP. Un livre de 2007 sur les technologies DSL a fait remarquer que :

[D]e nombreuses vulnérabilités de sécurité ont été identifiées par rapport aux mesures de sécurité proposées par la RFC 3118. Ce fait, combiné à l'introduction de la norme 802.1X , a ralenti le déploiement et le taux d'adoption du DHCP authentifié, et il n'a jamais été largement déployé.

Un livre de 2010 note que :

[I]l existe très peu d'implémentations de l'authentification DHCP. Les défis liés à la gestion des clés et aux délais de traitement dus au calcul du hachage ont été jugés comme un prix trop lourd à payer pour les avantages perçus.

Les propositions architecturales de 2008 impliquent l'authentification des requêtes DHCP à l'aide de 802.1X ou PANA (les deux transportant EAP ). Une proposition de l'IETF a été faite pour inclure EAP dans DHCP lui-même, le soi-disant EAPoDHCP ; cela ne semble pas avoir progressé au-delà du niveau de projet de l'IETF, dont le dernier date de 2010.

• RFC 2131, Protocole de configuration dynamique de l'hôte
• RFC 2132, options DHCP et extensions du fournisseur BOOTP
• RFC 3046, option d'informations sur l'agent relais DHCP
• RFC 3397, option de recherche de domaine du protocole DHCP (Dynamic Host Configuration Protocol)
• RFC 3942, Reclassification des options du protocole DHCPv4 (Dynamic Host Configuration Protocol Version Four)
• RFC 4242, Option de temps de rafraîchissement des informations pour le protocole de configuration d'hôte dynamique pour IPv6
• RFC 4361, Identifiants de client spécifiques au nœud pour le protocole de configuration d'hôte dynamique version quatre (DHCPv4)
• RFC 4436, Détection de connexion réseau dans IPv4 (DNAv4)
• RFC 3442, option de routage statique sans classe pour le protocole DHCP (Dynamic Host Configuration Protocol) version 4
• RFC 3203, extension de reconfiguration DHCP
• RFC 4388, requête de bail du protocole DHCP (Dynamic Host Configuration Protocol)
• RFC 6926, requête de location en masse DHCPv4
• RFC 7724, Requête de bail DHCPv4 active