2. Résumé du protocole (Protocol Summary)
Du point de vue d'un client, DHCP est une extension du mécanisme BOOTP. Ce comportement permet aux clients BOOTP existants d'interopérer avec les serveurs DHCP sans nécessiter aucune modification du logiciel d'initialisation des clients. La RFC 1542 [2] détaille les interactions entre les clients et serveurs BOOTP et DHCP [9]. Il existe de nouvelles transactions optionnelles qui optimisent l'interaction entre les clients et serveurs DHCP, décrites dans les sections 3 et 4.
La figure 1 présente le format d'un message DHCP et le tableau 1 décrit chacun des champs d'un message DHCP. Les nombres entre parenthèses indiquent la taille de chaque champ en octets. Les noms des champs donnés dans la figure seront utilisés tout au long de ce document pour faire référence aux champs dans les messages DHCP.
Il existe deux différences principales entre DHCP et BOOTP. Premièrement, DHCP définit des mécanismes par lesquels les clients peuvent se voir attribuer une adresse réseau pour un bail fini, permettant la réaffectation en série d'adresses réseau à différents clients. Deuxièmement, DHCP fournit le mécanisme permettant à un client d'acquérir tous les paramètres de configuration IP dont il a besoin pour fonctionner.
DHCP introduit un petit changement terminologique destiné à clarifier la signification de l'un des champs. Ce qui était le champ « extensions fournisseur (Vendor Extensions) » dans BOOTP a été renommé champ « options » dans DHCP. De même, les éléments de données balisés qui étaient utilisés dans le champ « extensions fournisseur » de BOOTP, anciennement appelés « extensions fournisseur », sont maintenant simplement appelés « options ».
Format d'un message DHCP (Format of a DHCP message)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1) | hlen (1) | hops (1) |
+---------------+---------------+---------------+---------------+
| xid (4) |
+-------------------------------+-------------------------------+
| secs (2) | flags (2) |
+-------------------------------+-------------------------------+
| ciaddr (4) |
+---------------------------------------------------------------+
| yiaddr (4) |
+---------------------------------------------------------------+
| siaddr (4) |
+---------------------------------------------------------------+
| giaddr (4) |
+---------------------------------------------------------------+
| |
| chaddr (16) |
| |
| |
+---------------------------------------------------------------+
| |
| sname (64) |
+---------------------------------------------------------------+
| |
| file (128) |
+---------------------------------------------------------------+
| |
| options (variable) |
+---------------------------------------------------------------+
Figure 1 : Format d'un message DHCP
DHCP définit une nouvelle option « identificateur de client (Client Identifier) » qui est utilisée pour transmettre un identificateur de client explicite à un serveur DHCP. Ce changement élimine la surcharge du champ « chaddr » dans les messages BOOTP, où « chaddr » était utilisé à la fois comme adresse matérielle pour la transmission des messages de réponse BOOTP et comme identificateur de client. L'« identificateur de client » est une clé opaque, qui ne doit pas être interprétée par le serveur ; par exemple, l'« identificateur de client » peut contenir une adresse matérielle, identique au contenu du champ « chaddr », ou il peut contenir un autre type d'identificateur, tel qu'un nom DNS. L'« identificateur de client » choisi par un client DHCP DOIT être unique pour ce client dans le sous-réseau auquel le client est rattaché. Si le client utilise un « identificateur de client » dans un message, il DOIT utiliser ce même identificateur dans tous les messages suivants, pour s'assurer que tous les serveurs identifient correctement le client.
DHCP clarifie l'interprétation du champ « siaddr » comme étant l'adresse du serveur à utiliser lors de la prochaine étape du processus d'amorçage du client. Un serveur DHCP peut retourner sa propre adresse dans le champ « siaddr », si le serveur est prêt à fournir le prochain service d'amorçage (par exemple, la livraison d'une image exécutable du système d'exploitation). Un serveur DHCP retourne toujours sa propre adresse dans l'option « identificateur de serveur (Server Identifier) ».
Description des champs dans un message DHCP (Description of fields in a DHCP message)
| Champ | Octets | Description |
|---|---|---|
| op | 1 | Code d'opération du message / type de message. 1 = BOOTREQUEST, 2 = BOOTREPLY |
| htype | 1 | Type d'adresse matérielle, voir la section ARP dans la RFC « Assigned Numbers » ; par exemple, '1' = 10mb ethernet. |
| hlen | 1 | Longueur de l'adresse matérielle (par exemple, '6' pour 10mb ethernet). |
| hops | 1 | Défini à zéro par le client, utilisé optionnellement par les agents relais lors de l'amorçage via un agent relais. |
| xid | 4 | ID de transaction, un nombre aléatoire choisi par le client, utilisé par le client et le serveur pour associer les messages et les réponses entre un client et un serveur. |
| secs | 2 | Rempli par le client, secondes écoulées depuis que le client a commencé le processus d'acquisition ou de renouvellement d'adresse. |
| flags | 2 | Drapeaux (voir figure 2). |
| ciaddr | 4 | Adresse IP du client ; rempli uniquement si le client est dans l'état BOUND, RENEW ou REBINDING et peut répondre aux requêtes ARP. |
| yiaddr | 4 | Adresse IP « votre » (client). |
| siaddr | 4 | Adresse IP du prochain serveur à utiliser lors de l'amorçage ; retourné dans DHCPOFFER, DHCPACK par le serveur. |
| giaddr | 4 | Adresse IP de l'agent relais, utilisé lors de l'amorçage via un agent relais. |
| chaddr | 16 | Adresse matérielle du client. |
| sname | 64 | Nom d'hôte du serveur optionnel, chaîne terminée par null. |
| file | 128 | Nom de fichier d'amorçage, chaîne terminée par null ; nom « générique » ou null dans DHCPDISCOVER, nom de chemin de répertoire entièrement qualifié dans DHCPOFFER. |
| options | var | Champ de paramètres optionnels. Voir les documents d'options pour une liste des options définies. |
Tableau 1 : Description des champs dans un message DHCP
Le champ « options » est désormais de longueur variable. Un client DHCP doit être prêt à recevoir des messages DHCP avec un champ « options » d'une longueur d'au moins 312 octets. Cette exigence implique qu'un client DHCP doit être prêt à recevoir un message allant jusqu'à 576 octets, la taille minimale de datagramme IP qu'un hôte IP doit être prêt à accepter [3]. Les clients DHCP peuvent négocier l'utilisation de messages DHCP plus volumineux via l'option « taille maximale de message DHCP (Maximum DHCP Message Size) ». Le champ options peut être étendu davantage dans les champs « file » et « sname ».
Dans le cas d'un client utilisant DHCP pour la configuration initiale (avant que le logiciel TCP/IP du client ne soit complètement configuré), DHCP nécessite une utilisation créative du logiciel TCP/IP du client et une interprétation libérale de la RFC 1122. Le logiciel TCP/IP DEVRAIT accepter et transférer à la couche IP tous les paquets IP livrés à l'adresse matérielle du client avant que l'adresse IP ne soit configurée ; les serveurs DHCP et les agents relais BOOTP peuvent ne pas être en mesure de livrer des messages DHCP aux clients qui ne peuvent pas accepter de datagrammes unicast matériels avant que le logiciel TCP/IP ne soit configuré.
Pour contourner certains clients qui ne peuvent pas accepter de datagrammes unicast IP avant que le logiciel TCP/IP ne soit configuré comme discuté dans le paragraphe précédent, DHCP utilise le champ « flags » [21]. Le bit le plus à gauche est défini comme le drapeau BROADCAST (B). La sémantique de ce drapeau est discutée dans la section 4.1 de ce document. Les bits restants du champ flags sont réservés pour une utilisation future. Ils DOIVENT être définis à zéro par les clients et ignorés par les serveurs et les agents relais. La figure 2 donne le format du champ « flags ».
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B : Drapeau BROADCAST
MBZ : DOIT ÊTRE ZÉRO (MUST BE ZERO) (réservé pour une utilisation future)
Figure 2 : Format du champ 'flags'
2.1 Dépôt de paramètres de configuration (Configuration parameters repository)
Le premier service fourni par DHCP consiste à fournir un stockage persistant des paramètres réseau pour les clients réseau. Le modèle de stockage persistant de DHCP est que le service DHCP stocke une entrée clé-valeur pour chaque client, où la clé est un identifiant unique (par exemple, un numéro de sous-réseau IP et un identifiant unique dans le sous-réseau) et la valeur contient les paramètres de configuration pour le client.
Par exemple, la clé peut être la paire (IP-subnet-number, hardware-address), permettant la réutilisation en série ou simultanée d'une adresse matérielle sur différents sous-réseaux, et pour les adresses matérielles qui peuvent ne pas être globalement uniques. Alternativement, la clé peut être la paire (IP-subnet-number, hostname), permettant au serveur d'attribuer intelligemment des paramètres à un client DHCP qui a été déplacé vers un sous-réseau différent ou a changé son adresse matérielle (peut-être en raison d'une défaillance de l'interface réseau et d'un remplacement du matériel). Le protocole définit que la clé sera (IP-subnet-number, hardware-address) à moins que le client ne fournisse explicitement un identifiant en utilisant l'option « identificateur de client ». Un client peut interroger le service DHCP pour récupérer ses paramètres de configuration. L'interface client vers le dépôt de paramètres de configuration consiste en des messages de protocole pour demander des paramètres de configuration et des réponses du serveur transportant les paramètres de configuration.
2.2 Allocation dynamique d'adresses réseau (Dynamic allocation of network addresses)
Le deuxième service fourni par DHCP est l'allocation d'adresses réseau (IP) temporaires ou permanentes aux clients. Le mécanisme de base pour l'allocation dynamique d'adresses réseau est simple : un client demande l'utilisation d'une adresse pendant une certaine période. Le mécanisme d'allocation (un ensemble de serveurs DHCP) garantit de ne pas réallouer cette adresse dans le temps demandé et tente de retourner la même adresse réseau chaque fois que le client demande une adresse. Dans ce document, la période pendant laquelle une adresse réseau est allouée à un client est appelée « bail (Lease) » [11]. Le client peut prolonger son bail avec des demandes ultérieures. Le client peut émettre un message pour libérer l'adresse vers le serveur lorsque le client n'a plus besoin de l'adresse. Le client peut demander une affectation permanente en demandant un bail infini. Même lors de l'attribution d'adresses « permanentes », un serveur peut choisir de donner des baux longs mais non infinis pour permettre la détection du fait qu'un client a été mis hors service.
Dans certains environnements, il sera nécessaire de réaffecter des adresses réseau en raison de l'épuisement des adresses disponibles. Dans de tels environnements, le mécanisme d'allocation réutilisera les adresses dont le bail a expiré. Le serveur devrait utiliser toute information disponible dans le dépôt d'informations de configuration pour choisir une adresse à réutiliser. Par exemple, le serveur peut choisir l'adresse la moins récemment attribuée. En tant que vérification de cohérence, le serveur d'allocation DEVRAIT sonder l'adresse réutilisée avant d'allouer l'adresse, par exemple, avec une requête d'écho ICMP, et le client DEVRAIT sonder l'adresse nouvellement reçue, par exemple, avec ARP.