Aller au contenu principal

1. Introduction

Le protocole de configuration dynamique d'hôte (Dynamic Host Configuration Protocol, DHCP) fournit des paramètres de configuration aux hôtes Internet. DHCP se compose de deux composants : un protocole pour délivrer des paramètres de configuration spécifiques à l'hôte depuis un serveur DHCP vers un hôte et un mécanisme pour l'allocation d'adresses réseau aux hôtes.

DHCP est construit sur un modèle client-serveur, où des hôtes serveurs DHCP désignés allouent des adresses réseau et délivrent des paramètres de configuration aux hôtes configurés dynamiquement. Dans le reste de ce document, le terme « serveur » fait référence à un hôte fournissant des paramètres d'initialisation via DHCP, et le terme « client » fait référence à un hôte demandant des paramètres d'initialisation à un serveur DHCP.

Un hôte ne doit pas agir en tant que serveur DHCP à moins d'être explicitement configuré pour le faire par un administrateur système. La diversité des implémentations matérielles et protocolaires sur Internet empêcherait un fonctionnement fiable si des hôtes aléatoires étaient autorisés à répondre aux requêtes DHCP. Par exemple, IP nécessite le réglage de nombreux paramètres dans le logiciel d'implémentation du protocole. Comme IP peut être utilisé sur de nombreux types différents de matériel réseau, les valeurs de ces paramètres ne peuvent être devinées ou supposées avoir des valeurs par défaut correctes. De plus, les schémas d'allocation d'adresses distribuées dépendent d'un mécanisme de sondage/défense pour la découverte d'adresses déjà utilisées. Les hôtes IP peuvent ne pas toujours être capables de défendre leurs adresses réseau, de sorte qu'un tel schéma d'allocation d'adresses distribuées ne peut garantir d'éviter l'allocation d'adresses réseau en double.

DHCP supporte trois mécanismes d'allocation d'adresses IP. Dans « l'allocation automatique », DHCP attribue une adresse IP permanente à un client. Dans « l'allocation dynamique », DHCP attribue une adresse IP à un client pour une période limitée (ou jusqu'à ce que le client renonce explicitement à l'adresse). Dans « l'allocation manuelle », l'adresse IP d'un client est attribuée par l'administrateur réseau, et DHCP est simplement utilisé pour transmettre l'adresse attribuée au client. Un réseau particulier utilisera un ou plusieurs de ces mécanismes, selon les politiques de l'administrateur réseau.

L'allocation dynamique est le seul de ces mécanismes qui permet la réutilisation automatique d'une adresse qui n'est plus nécessaire au client auquel elle a été attribuée. Ainsi, l'allocation dynamique est particulièrement utile pour attribuer une adresse à un client qui sera connecté au réseau seulement temporairement ou pour partager un pool limité d'adresses IP entre un groupe de clients qui n'ont pas besoin d'adresses IP permanentes. L'allocation dynamique peut également être un bon choix pour attribuer une adresse IP à un nouveau client connecté en permanence à un réseau où les adresses IP sont suffisamment rares pour qu'il soit important de les récupérer lorsque les anciens clients sont retirés. L'allocation manuelle permet d'utiliser DHCP pour éliminer le processus sujet aux erreurs de configuration manuelle des hôtes avec des adresses IP dans les environnements où (pour quelque raison que ce soit) il est souhaitable de gérer l'attribution des adresses IP en dehors des mécanismes DHCP.

Le format des messages DHCP est basé sur le format des messages BOOTP, pour capturer le comportement de l'agent relais BOOTP décrit dans la spécification BOOTP [7, 21], et pour permettre l'interopérabilité des clients BOOTP existants avec les serveurs DHCP. L'utilisation d'agents relais BOOTP élimine la nécessité d'avoir un serveur DHCP sur chaque segment réseau physique.

1.1 Modifications apportées à la RFC 1541​

Ce document met à jour la spécification du protocole DHCP qui apparaît dans la RFC 1541. Un nouveau type de message DHCP, DHCPINFORM, a été ajouté ; voir les sections 3.4, 4.3 et 4.4 pour les détails. Le mécanisme de classification pour identifier les clients DHCP aux serveurs DHCP a été étendu pour inclure les classes de « fournisseur » telles que définies dans les sections 4.2 et 4.3. La restriction de durée minimale de bail a été supprimée. Enfin, de nombreuses modifications éditoriales ont été apportées pour clarifier le texte suite à l'expérience acquise lors des tests d'interopérabilité DHCP.

1.2 Travaux connexes​

Il existe plusieurs protocoles Internet et mécanismes connexes qui traitent certaines parties du problème global de configuration des hôtes. Le protocole de résolution d'adresse inverse (Reverse Address Resolution Protocol, RARP) [10] (via les extensions définies dans le RARP dynamique (DRARP) [5]) traite explicitement le problème de la découverte d'adresses réseau et inclut un mécanisme d'attribution automatique d'adresses IP. Le protocole de transfert de fichiers trivial (Trivial File Transfer Protocol, TFTP) [20] assure le transport d'une image de démarrage depuis un serveur de démarrage. Le protocole de messages de contrôle Internet (Internet Control Message Protocol, ICMP) [16] permet d'informer les hôtes de routeurs supplémentaires via les messages « ICMP redirect ». ICMP peut également fournir des informations sur le masque de sous-réseau via le message « ICMP mask request » et d'autres informations via le message (obsolète) « ICMP information request ». Les hôtes peuvent localiser les routeurs via le mécanisme de découverte de routeur ICMP [8].

BOOTP est un mécanisme de transport pour une collection d'informations de configuration. BOOTP est également extensible, et des extensions officielles [17] ont été définies pour plusieurs paramètres de configuration. Morgan a proposé des extensions à BOOTP pour l'attribution dynamique d'adresses IP [15]. Le protocole d'information réseau (Network Information Protocol, NIP), utilisé par le projet Athena au MIT, est un mécanisme distribué pour l'attribution dynamique d'adresses IP [19]. Le protocole de localisation de ressources RLP [1] permet la localisation de services de niveau supérieur. Les stations de travail sans disque Sun Microsystems utilisent une procédure de démarrage qui emploie RARP, TFTP et un mécanisme RPC appelé « bootparams » pour délivrer des informations de configuration et du code de système d'exploitation aux hôtes sans disque. (Sun Microsystems, Sun Workstation et SunOS sont des marques commerciales de Sun Microsystems, Inc.) Certains réseaux Sun utilisent également DRARP et un mécanisme d'auto-installation pour automatiser la configuration de nouveaux hôtes dans un réseau existant.

Dans d'autres travaux connexes, l'algorithme de découverte de l'unité de transmission maximale (MTU) du chemin peut déterminer le MTU d'un chemin Internet arbitraire [14]. Le protocole de résolution d'adresse (Address Resolution Protocol, ARP) a été proposé comme protocole de transport pour la localisation et la sélection de ressources [6]. Enfin, les RFC sur les exigences des hôtes [3, 4] mentionnent des exigences spécifiques pour la reconfiguration des hôtes et suggèrent un scénario pour la configuration initiale des hôtes sans disque.

1.3 Définition du problème et questions​

DHCP est conçu pour fournir aux clients DHCP les paramètres de configuration définis dans les RFC sur les exigences des hôtes. Après avoir obtenu des paramètres via DHCP, un client DHCP devrait pouvoir échanger des paquets avec tout autre hôte sur Internet. Les paramètres de pile TCP/IP fournis par DHCP sont listés dans l'annexe A.

Tous ces paramètres ne sont pas requis pour un client nouvellement initialisé. Un client et un serveur peuvent négocier pour la transmission uniquement des paramètres requis par le client ou spécifiques à un sous-réseau particulier.

DHCP permet mais n'exige pas la configuration de paramètres client non directement liés au protocole IP. DHCP ne traite pas non plus l'enregistrement des clients nouvellement configurés dans le système de noms de domaine (Domain Name System, DNS) [12, 13].

DHCP n'est pas destiné à être utilisé pour la configuration des routeurs.

1.4 Exigences​

Tout au long de ce document, les mots utilisés pour définir l'importance de certaines exigences sont en majuscules. Ces mots sont :

"MUST" (doit)​

Ce mot ou l'adjectif « REQUIRED » signifie que l'élément est une exigence absolue de cette spécification.

"MUST NOT" (ne doit pas)​

Cette phrase signifie que l'élément est une interdiction absolue de cette spécification.

"SHOULD" (devrait)​

Ce mot ou l'adjectif « RECOMMENDED » signifie qu'il peut exister des raisons valables dans des circonstances particulières pour ignorer cet élément, mais les implications complètes doivent être comprises et le cas soigneusement pesé avant de choisir une approche différente.

"SHOULD NOT" (ne devrait pas)​

Cette phrase signifie qu'il peut exister des raisons valables dans des circonstances particulières où le comportement listé est acceptable ou même utile, mais les implications complètes doivent être comprises et le cas soigneusement pesé avant d'implémenter tout comportement décrit avec cette étiquette.

"MAY" (peut)​

Ce mot ou l'adjectif « OPTIONAL » signifie que cet élément est vraiment optionnel. Un fournisseur peut choisir d'inclure l'élément parce qu'un marché particulier l'exige ou parce qu'il améliore le produit, par exemple ; un autre fournisseur peut omettre le même élément.

1.5 Terminologie​

Ce document utilise les termes suivants :

"DHCP client" (client DHCP)​

Un client DHCP est un hôte Internet utilisant DHCP pour obtenir des paramètres de configuration tels qu'une adresse réseau.

"DHCP server" (serveur DHCP)​

Un serveur DHCP est un hôte Internet qui renvoie des paramètres de configuration aux clients DHCP.

"BOOTP relay agent" (agent relais BOOTP)​

Un agent relais BOOTP ou agent relais est un hôte Internet ou un routeur qui transmet des messages DHCP entre les clients DHCP et les serveurs DHCP. DHCP est conçu pour utiliser le même comportement d'agent relais que celui documenté dans la spécification du protocole BOOTP.

"binding" (liaison)​

Une liaison est une collection de paramètres de configuration, incluant au moins une adresse IP, associée ou « liée » à un client DHCP. Les liaisons sont gérées par les serveurs DHCP.

1.6 Objectifs de conception​

La liste suivante donne les objectifs généraux de conception pour DHCP.

  • DHCP devrait être un mécanisme plutôt qu'une politique. DHCP doit permettre aux administrateurs système locaux de contrôler les paramètres de configuration si désiré ; par exemple, les administrateurs système locaux devraient pouvoir appliquer des politiques locales concernant l'allocation et l'accès aux ressources locales si désiré.

  • Les clients ne devraient pas nécessiter de configuration manuelle. Chaque client devrait pouvoir découvrir les paramètres de configuration locaux appropriés sans intervention de l'utilisateur et incorporer ces paramètres dans sa propre configuration.

  • Les réseaux ne devraient pas nécessiter de configuration manuelle pour les clients individuels. Dans des circonstances normales, le gestionnaire de réseau ne devrait pas avoir à entrer de paramètres de configuration par client.

  • DHCP ne devrait pas nécessiter un serveur sur chaque sous-réseau. Pour permettre l'échelle et l'économie, DHCP doit fonctionner à travers les routeurs ou par l'intervention d'agents relais DHCP.

  • Un client DHCP doit être prêt à recevoir plusieurs réponses à une demande de paramètres de configuration. Certaines installations peuvent inclure plusieurs serveurs DHCP se chevauchant pour améliorer la fiabilité et augmenter les performances.

  • DHCP doit coexister avec des hôtes configurés statiquement et non participants et avec des implémentations de protocole réseau existantes.

  • DHCP doit interopérer avec le comportement de l'agent relais BOOTP tel que décrit par la RFC 951 et par la RFC 1542 [21].

  • DHCP doit fournir un service aux clients BOOTP existants.

La liste suivante donne les objectifs de conception spécifiques à la transmission des paramètres de couche réseau. DHCP doit :

  • Garantir qu'une adresse réseau spécifique ne sera pas utilisée par plus d'un client DHCP à la fois,

  • Conserver la configuration du client DHCP lors des redémarrages du client DHCP. Un client DHCP devrait, autant que possible, se voir attribuer les mêmes paramètres de configuration (par exemple, adresse réseau) en réponse à chaque demande,

  • Conserver la configuration du client DHCP lors des redémarrages du serveur, et, autant que possible, un client DHCP devrait se voir attribuer les mêmes paramètres de configuration malgré les redémarrages du mécanisme DHCP,

  • Permettre l'attribution automatique de paramètres de configuration aux nouveaux clients pour éviter la configuration manuelle des nouveaux clients,

  • Supporter l'allocation fixe ou permanente de paramètres de configuration à des clients spécifiques.

Dernière mise à jour le