Statut de ce document

Ce document spécifie un protocole standard d'Internet, pour la communauté Internet, et ne sera éprouvé qu'après plusieurs discussions et suggestions. Merci de vous référer à l'édition courante du "Internet Official Protocol Standards " (STD1) pour l'état de standardisation et le statut de ce protocole. La distribution de ce document est illimitée.

Résumé

Le DHCP fournit une trame de travail pour transférer des informations de configuration à des machines sur un réseau TCP/IP. DHCP est basé sur le protocole d'amorçage BOOTP (bootstrap protocol) [7], en y ajoutant la possibilité d'allocation automatique d'adresses réseaux réutilisables, ainsi que de nouvelles options de configuration [19]. DHCP capture le comportement d'agents de relais BOOTP [7, 21] et les participants DHCP peuvent interagir avec des participants BOOTP [9].

SOMMAIRE

1. Introduction
  1.1 Changement fait au RFC1541
  1.2 Travail lié 
  1.3 Définition des problèmes et solutions 
  1.4 Exigences 
  1.5 Terminologie 
  1.6 But du projet 
2. Résumé du protocole 
  2.1 Dépôt des paramètres de configuration 
  2.2 Allocations dynamique des adresses réseau
3. Le protocole Client-Serveur 
  3.1 Interaction client-serveur - Allocation d'une adresse réseau 
  3.2 Interaction client-serveur - Réutilisation d'une adresse réseau 
  3.3 Interprétation et représentation des données temporelles 
  3.4 Obtenir des paramètres avec une adresse réseau configurée en externe 
  3.5 Paramétrage d'un client avec DHCP 
  3.6 Utilisation de DHCP sur des clients possédant de multiples interfaces 
  3.7 Quand les clients devraient utiliser DHCP 
4. Spécification du protocole DHCP 
  4.1 Construction et envoi de messages DHCP 
  4.2 Contrôle d'administration d'un serveur DHCP 
  4.3 Comportement du serveur DHCP 
  4.4 Comportement du client DHCP 
5. Remerciements 
6. Références 
7. Considérations concernant la sécurité
8. Adresse de l'auteur 
A. Paramètres de configuration de machine
1. Introduction

Le DHCP fournit des paramètres de configuration pour des machines Internet. DHCP est constitué de 2 parties : un protocole pour la livraison de paramètres de configuration de machines spécifiques à partir d'un serveur DHCP et un mécanisme d'allocation d'adresses réseaux à des machines.

DHCP est bâti sur le modèle client-serveur, où la machine désignée serveur DHCP alloue des adresses réseaux et délivre des paramètres de configuration à des machines configurées dynamiquement. D'un bout à l'autre de ce document, le terme "serveur" se réfère à une machine fournissant des paramètres d'initialisation au travers du DHCP, et le terme "client" se réfère à une machine qui demande des paramètres d'initialisation au serveur DHCP.

Une machine ne devrait pas agir en tant que serveur DHCP à moins que cela ne soit spécifié par l'administrateur du système. La diversité des implantations du matériel et des protocoles sur l'Internet conduirait à un manque de fiabilité au niveau des opérations si n'importe quelle machine était autorisée à répondre aux requêtes DHCP. Par exemple, IP nécessite le réglage de nombreux paramètres à l'intérieur du logiciel qui implante le protocole. Parce que IP peut être utilisé sur un grand nombre de matériels réseau, les valeurs par défaut de ces paramètres ne peuvent être devinées ou présupposées correctement. De même, les schémas de distribution d'adresses reposent sur un mécanisme d'élection/défense pour la découverte des adresses d&eac ute;jà utilisées. Les machines IP ne peuvent pas toujours défendre leurs adresses réseaux, ainsi un tel schéma d'allocation d'adresse ne peut garantir que les adresses allouées ne se dupliquent.

DHCP supporte trois mécanismes pour l'allocation des adresses IP. Avec l'allocation automatique, DHCP assigne une adresse IP permanente à un client. Avec l'allocation dynamique, DHCP assigne une adresse IP à un client pour une durée déterminée (ou jusqu'à ce que le client renonce à son adresse). Avec l'allocation manuelle, une adresse IP est assignée par l'administrateur réseau, et DHCP est simplement utilisé pour convoyer les adresses désignées jusqu'au client. Un réseau spécifique utilisera un ou plusieurs de ces mécanismes, cela dépend de la stratégie de l'administrateur réseau.

L'allocation dynamique est le seul des trois mécanismes qui réutilise automatiquement une adresse qui n'est plus utilisée par un client. De plus, l'allocation dynamique est particulièrement utile pour assigner une adresse à un client qui se connectera au réseau de manière temporaire, ou pour partager une liste limitée d'adresses IP entre un groupe de clients qui ne nécessitent pas une adresse permanente. L'allocation dynamique est aussi un bon choix pour assigner une adresse IP à un nouveau client qui se connectera de manière permanente au réseau où les adresses IP sont suffisamment rares pour qu'il soit important de les récupérer quand les anciens clients sont hors connexion. L'allocation manuelle permet à DHCP d'être utilisé pour éliminer les processus enclins à l'erreur de configuration manuelle de machines avec une adresse IP dans d es environnements où (pour diverses raisons) il est préférable de gérer l'attribution des adresses IP en dehors des mécanismes de DHCP.

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

1.1 Changement apporté au RFC 1541

Ce document met à jour les spécifications du protocole DHCP qui apparaissent dans le RFC1541. Un nouveau type de message, DHCPINFORM, a été ajouté ; voir les sections 3.4, 4.3 et 4.4 pour les détails. Le mécanisme de classement pour l'identification des clients DHCP aux serveurs DHCP a été étendu pour inclure les classes "fournisseurs" comme défini dans les sections 4.2 et 4.3. La restriction au niveau du temps de bail minimum a été enlevée. Enfin, plusieurs changements éditoriaux ont été fait pour clarifier le texte et sont le résultat d'expériences réussies dans des tests d'interopérabilité du DHCP.

1.2 Travail lié

Il y a quelques protocoles Internet et mécanismes liés qui s'adressent à quelques éléments du problème de configuration dynamique. Le "Reverse Address Resolution Protocol" (RARP) [10] (au travers des extensions définies dans le RARP dynamique (DRARP) [5]) s'adresse explicitement au problème de la découverte d'adresse réseaux, et inclut un mécanisme d'attribution automatique d'adresse IP. Le "Trivial File Transfer Protocol" (TFTP) [20] pourvoit au transport d'une image d'amorce à partir d'un serveur d'amorces. L'"Internet Control Message Protocol" (ICMP) [16] pourvoit à l'information des machines de routeurs supplémentaires via les messages "ICMP redirect". ICMP peut aussi fournir des informations sur le masque de sous réseau au travers du message "ICMP mask request" et d'autres informations au travers du message (obsolète) "ICMP information request". Les machines peuvent localiser les routeurs au travers du mécanisme ICMP de découverte de réseau [8].

BOOTP est un mécanisme de transport pour une collecte d'information sur la configuration. BOOTP est également extensible, et les extensions officielles [17] ont été définies pour plusieurs paramètres de configuration. Morgan a proposé des extensions au BOOTP pour l'assignation dynamique d'adresses IP [15]. Le "Network Information Protocol" (NIP), utilisé par le projet Athena au MIT, est un mécanisme distribué pour l'allocation dynamique d'adresses IP [19]. Le "Ressource Location Protocol" RLP [1] pourvoit à la situation des services de haut niveaux. Les stations sans disque de Sun Microsytems utilisent une procédure d'amorce qui emploie RARP, TFTP et un mécanisme RPC appelé "bootparams" pour délivrer les informations de configuration et le code du système d'exploitation aux machines sans disque, (Sun Micro Systems, Sun Workstation et SunOs sont des marques d&eacu te;posées de Sun Microsystems, Inc.) Quelques réseaux Sun utilisent aussi DRARP et un mécanisme d'auto-installation pour automatiser la configuration des nouvelles machines dans un réseau existant.

Dans d'autres travaux liés, l'algorithme de découverte du chemin du "Minimum Transmission Unit" (MTU) peut déterminer le MTU d'un chemin Internet arbitraire [14]. Le protocole de résolution d'adresse (ARP) a été proposé comme protocole de transport pour la localisation et la sélection de ressources [6]. Enfin, Les RFC des obligations des machines ("Host Requirement") [3, 4] mentionnent ce qui est requis pour la reconfiguration d'une machine et suggère un scénario pour la configuration initiale d'une machine sans disque.

1.3 Définition des problèmes et solutions

DHCP est défini pour fournir aux clients DHCP les paramètres de configuration définis dans les RFC des obligations des machines ("Host Requirement"). Après avoir obtenus les paramètres via DHCP, un client DHCP devrait être en mesure d'échanger des paquets avec n'importe quelle autre machine sur Internet. Les paramètres de la pile de TCP/IP sont fournis dans l'annexe A.

Tout ces paramètres ne sont pas requis pour un client nouvellement initialisé. Un client et un serveur peuvent négocier seulement les paramètres demandés par le client ou spécifiques à un sous réseau.

DHCP permet, mais n'exige pas, la configuration des paramètres client qui ne sont pas directement liés au protocole IP. DHCP n'est pas destiné à gérer l'inscription des clients nouvellement configurés en relation avec le Service de noms de domaine (DNS) [12, 13].

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

1.4 Exigence

Tout au long de ce document, les mots qui sont utilisés pour définir une importance ou une exigence particulière seront mis en majuscules. Ces mots sont :

o "DOIT"

Ce mot ou l'adjectif "OBLIGATOIRE" signifie que l'item est une nécessité absolue de cette spécification.

o "NE DOIT PAS"

Cette phrase signifie que l'item est absolument prohibé de cette spécification.

o "DEVRAIT"

Ce mot ou l'adjectif "RECOMMANDÉ" signifie qu'il peut exister des raisons valides dans des circonstances particulières pour ignorer cet item, mais les implications complètes devront être comprises et le cas soigneusement étudié avant de choisir un chemin différent.

o "NE DEVRAIT PAS"

Cette phrase signifie qu'il peut exister des raisons valides dans des circonstances particulières quand le comportement de l'item est acceptable ou même utile, mais les implications complètes devront être comprises et le cas soigneusement étudié avant d'implanter un comportement décrit avec cette étiquette.

o "PEUT"

Ce mot ou l'adjectif "OPTIONNEL" signifie que cet item est vraiment optionnel. Par exemple, un distributeur peut choisir d'inclure l'item parce qu'un marché particulier l'exige ou parce qu'il améliore le produit; un autre distributeur peut omettre le même item.

1.5 Terminologie

Ce document utilise les termes suivants :

o "client DHCP"

Un client DHCP est une machine sur Internet utilisant DHCP pour obtenir des paramètres de configuration telle qu'une adresse réseau.

o "serveur DHCP"

Un serveur DHCP est une machine sur Internet qui retourne des paramètres de configuration à un client DHCP.

o "agent de relais BOOTP"

Un agent de relais BOOTP ou agent de relais est une machine sur Internet ou un routeur qui transmet des messages DHCP entre clients et serveurs DHCP. DHCP est conçu pour utiliser le même comportement que l'agent de relais comme spécifié dans le protocole du BOOTP.

o "affectation"

Une affectation est un ensemble de paramètres de configuration, incluant au moins une adresse IP, associé ou affecté à un client DHCP. Les affectations sont gérées par les serveurs DHCP.

1.6 But du projet

La liste suivante précise les différents objectifs du DHCP.

o DHCP devrait être un mécanisme plutôt qu'une stratégie. DHCP doit permettre à l'administrateur système de contrôler les paramètres de configuration là où ils sont désirés, par exemple l'administrateur d'un système local devra être capable de renforcer la stratégie locale concernant les allocations et l'accès aux ressources locales là où elles sont désirées.

o Les clients ne devrait pas exiger de configurations manuelles. Chaque client doit être capable de découvrir les paramètres de configuration locaux sans l'intervention de l'utilisateur et d'incorporer ces paramètres dans sa propre configuration.

o Les réseaux ne devraient pas exiger de configuration manuelle pour chaque client. Dans des circonstances normales, le gestionnaire du réseau ne devrait pas à avoir à entrer les paramètres de configuration pour chaque client.

o DHCP ne devrait pas exiger un serveur sur chaque sous réseau. Pour permettre une meilleure adaptabilité et économie, DHCP doit travailler au travers des routeurs ou via l'intervention des agents de relais BOOTP.

o Un client DHCP doit s'attendre à recevoir des réponses multiples à une demande de paramètres de configuration. Quelques installations peuvent inclure plusieurs serveurs DHCP se chevauchant pour augmenter la fiabilité et les performances.

o DHCP doit coexister avec des machines statiques et non participantes ainsi qu'avec des implantations de protocole réseau déjà en place.

o DHCP doit interagir avec le comportement d'agent de relais BOOTP comme décrit dans le RFC 951 et RFC 1542 [21].

o DHCP doit fournir un service aux clients BOOTP existants.

La liste suivante donne les objectifs spécifiques à une transmission des paramètres de couches réseaux. DHCP doit :

o Garantir que n'importe quelle adresse réseau ne sera pas utilisée par plusieurs clients DHCP en même temps.

o Retenir une configuration DHCP d'un client malgré un redémarrage du client DHCP. Un client DHCP devra, à chaque fois que cela est possible, se voir assigner les mêmes paramètres de configuration (par exemple: une adresse réseau) en réponse à chaque demande.

o Retenir la configuration d'un client DHCP au travers des redémarrages du serveur, et chaque fois que cela est possible, un client DHCP devra se voir assigner les mêmes paramètres de configuration malgré les redémarrages du mécanisme DHCP,

o Permettre une attribution automatique de paramètres de configuration aux nouveaux clients pour éviter la configuration manuelle de ces nouveaux clients,

o Supporter les allocations fixes ou permanentes des paramètres de configuration à des clients particuliers.

 

2. Résumé du protocole

Du point de vue de chaque client, DHCP est une extension du mécanisme BOOTP. Ce comportement permet aux clients BOOTP existants d'interagir avec les serveurs DHCP sans que cela ne nécessite de changement au niveau du logiciel d'initialisation du client. RFC 1542 [2] détaille les interactions entre des clients ou des serveurs BOOTP et DHCP [9]. Il y a quelques nouvelles transactions optionnelles qui optimisent l'interaction entre un client DHCP et les serveurs qui sont décrites dans les sections 3 et 4.

La Figure 1 donne 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 pour les champs donnés dans la figure seront utilisés au travers de ce document pour faire référence aux champs des messages DHCP.

Il y a deux différences fondamentales entre DHCP et BOOTP. La première est que DHCP définit des mécanismes au travers desquels les clients peuvent se voir attribuer une adresse réseau pour une durée déterminée, autorisant la réattribution en série d'adresses réseau à différents clients. La deuxième est que DHCP fournit un mécanisme permettant à un client d'acquérir tous les paramètres de configuration IP qui lui sont nécessaires pour fonctionner.

DHCP fait apparaître un petit changement de terminologie qui permet de clarifier la compréhension d'un des champs. Ce qui fut les "extensions fournisseurs" (vendor extensions) pour le BOOTP a été renommé champ "options" pour le DHCP. De la même manière les données marquées qui ont été utilisées dans le champ "extensions fournisseurs" du BOOTP, et dont on faisait référence en tant que "extensions fournisseurs" sont maintenant appelés simplement "options".

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) | +---------------------------------------------------------------+ | | | fichier (128) | +---------------------------------------------------------------+ | | | options (variable) | +---------------------------------------------------------------+

Figure 1: Format d'un message DHCP

DHCP définit une nouvelle option 'identifiant client' qui est utilisée pour transmettre un identifiant client au serveur DHCP. Ce changement élimine la surcharge du champ 'chaddr' dans les messages BOOTP, où 'chaddr' est utilisé à la fois comme adresse matérielle pour la transmission du message réponse par BOOTP et comme identifiant client. L'identifiant client est une clé opaque, ne pouvant être interprété par le serveur ; par exemple, l'identifiant client peut contenir une adresse matérielle, identique au contenu du champ 'chaddr', ou bien il peut contenir un autre type d'identifiant, comme le nom DNS. L'identifiant client, choisi par le client DHCP, DOIT être propre à ce client à l'intérieur du sous réseau auquel il est rattaché. Si le client utilise un 'identifiant client' dans un message il DOIT utiliser le même identifiant dans tous les messages qui suivent pour s'assurer que le serveur l'identifie clairement. DHCP clarifie l'interprétation du champ 'siaddr' comme étant l'adresse du serveur à utiliser dans le prochain processus de démarrage des clients. Un serveur DHCP peut retourner sa propre adresse dans le champ 'siaddr', si le serveur est configuré pour fournir le prochain service de démarrage (par ex. l'attribution d'une image exécutable d'un système d'exploitation). Un serveur DHCP retourne toujours sa propre adresse dans l'option 'identifiant serveur'.

CHAMP

OCTETS

DESCRIPTION

op

1

Code opération du message / type du message. 1 = BOOTREQUEST, 2 = BOOTREPLY

htype

1

Adresse matérielle, voir la section ARP dans le RFC "Assigned Numbers" ; par ex., '1' = Ethernet 10Mb.

hlen

1

Longueur de l'adresse matérielle (par ex. '6' for Ethernet 10Mb).

hops

1

Mis à zéro par le client, utilisé de manière optionnelle par les agents de relais quand on démarre via un agent de relais

xid

4

Identifiant 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, les secondes s'écoulent depuis le processus d'acquisition ou de renouvellement d'adresse du client

flags

2

Drapeaux (voir figure 2).

ciaddr

4

Adresse IP des clients, rempli seulement si le client est dans un état AFFECTÉ, RENOUVELLEMENT ou REAFFECTATION et peut répondre aux requêtes ARP

yiaddr

4

'votre' (client) adresse IP.

siaddr

4

Adresse IP du prochain serveur à utiliser pour le processus de démarrage; retournée par le serveur dans DHCPOFFER et DHCPACK.

giaddr

4

Adresse IP de l'agent de relais, utilisée pour démarrer via un agent de relais.

chaddr

16

Adresse matérielle des clients.

sname

64

Nom d'hôte du serveur optionnel, chaîne de caractères terminée par un caractère nul.

fichier

128

Nom du fichier de démarrage, chaîne terminée par un caractère nul ; nom "generic" ou nul dans le DHCPDISCOVER, nom du répertoire explicite dans DHCPOFFER.

options

var

Champ de paramètres optionnels. Voir le document d'options pour une liste des options définies.

Table 1: description des champs dans un message DHCP

Le champ 'options' est maintenant de longueur variable. Un client DHCP doit s'attendre à recevoir des messages DHCP avec un champ 'options' d'au moins 312 octets. Ce qui implique qu'un client DHCP doit s'attendre à la réception d'un message jusqu'à 576 octets, taille minimum d'un datagramme qu'une machine IP doit savoir accepter [3]. Les clients DHCP doivent négocier l'utilisation de messages DHCP plus grands à l'aide de l'option 'taille maximum message DHCP'. Le champ d'options peut être étendu d'avantage dans les champs 'fichier' et 'sname'.

Dans le cas où un client utilise DHCP pour une configuration initiale (avant que le logiciel TCP/IP du client n'ait été complètement configuré), DHCP nécessite une utilisation créative des logiciels TCP/IP du client et une interprétation libérale du RFC 1122. le logiciel TCP/IP DOIT accepter et faire suivre à la couche IP tout paquet IP délivré à l'adresse matérielle du client avant que l'adresse IP ne soit configurée; les serveurs DHCP et les agents de relais BOOTP ne pourront pas être capable de délivrer des messages DHCP aux clients qui n'acceptent pas les datagrammes adressés matériel avant que le logiciel TCP/IP ne soit configuré.

Pour travailler avec quelques clients qui ne peuvent accepter les datagrammes adressés IP avant que le logiciel TCP/IP ne soit configuré comme mentionné dans le paragraphe du dessus, DHCP utilise le champ 'flags' [21]. Le bit le plus à gauche est défini comme le drapeau diffusion (B). La sémantique de ce drapeau est vue dans la section 4.1 de ce document. Les bits restants de ce drapeau sont réservés pour des utilisations ultérieures. Ils DOIVENT être positionnés sur zéro par les clients et ignorés par les serveurs et les agents de 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 diffusion (Broadcast) MBZ: DOIT être à zéro (réservé pour une utilisation ultérieure)

Figure 2: Format du champ 'flags'

2.1 Configuration des paramètres

Le premier service fourni par DHCP est de fournir un espace de mémorisation des paramètres réseaux pour les clients de ce réseau. Le modèle DHCP de mémoire persistante est basé sur la mémorisation, comme point d'entrée, d'une valeur clef pour chaque client, cette clef est un identifiant unique (par exemple un nombre IP sous réseau et un identifiant unique à l'intérieur du sous réseau) et la valeur contient les paramètres de configuration du client.

Par exemple, la clef peut être la paire (numéro IP du sous réseau, adresse matérielle) (notez que l'adresse matérielle pourrait être définie par le type de matériel pour satisfaire les possibles duplications d'adresses matérielles résultant d'un problème d'ordonnancement des bits dans un réseau ponté comportant des médias différents) permettant une réutilisation des adresses matérielles de série ou concurrentes sur des sous-réseaux différents, et pour les adresses matérielles qui ne peuvent être globalement uniques. Autrement, la clef peut être la paire (Numéro IP sous réseau, nom d'hôte), permettant au serveur d'assigner des paramètres de manière intelligente à un client DHCP qui a été déplacé sur un sous réseau différent ou qui a chang é d'adresse matérielle (peut-être parce que l'interface réseau à été remplacée à cause d'une défaillance). Le protocole définit que la clef sera (Numéro IP de sous-réseau et adresse matérielle) jusqu'à ce que le client fournisse un identifiant de manière explicite en utilisant l'option 'identifiant client'. Un client peut demander le service DHCP pour récupérer ses paramètres de configuration. L'interface client pour le dépôt des paramètres de configuration consiste en des protocoles messages pour demander les paramètres de configuration et des réponses du serveur pour le transport des paramètres de configuration.

2.2 Allocation dynamique des adresses réseau

Le second service fourni par le DHCP est l'allocation temporaire ou permanente d'adresses réseau (IP) aux clients. Le mécanisme pour l'allocation dynamique d'adresses est simple : un client demande l'utilisation d'une adresse pour une certaine période. Le mécanisme d'allocation (l'ensemble des serveurs DHCP) ne garantit pas une ré allocation de l'adresse pendant le temps demandé et tend à retourner la même adresse réseau à un client donné lorsque celui-ci demande une adresse. Dans ce document, la période pendant laquelle une adresse réseau est allouée à un client est nommée "bail" [11]. Le client peut étendre ce bail avec des requêtes. Le client peut émettre un message pour libérer l'adresse quand il ne l'utilise plus. Le client peut demander une assignation permanente en demandant un bail permanent, un serveur peut choisir de donne r un bail très long mais pas infini pour permettre la détection du retrait d'un client du réseau.

Dans certains environnement il sera nécessaire de réassigner des adresses réseaux du fait de l'épuisement des adresses disponibles. Dans un tel cas le mécanisme d'allocation réutilisera les adresses dont le bail aura expiré. Le serveur devra utiliser n'importe quelle information disponible pour choisir une nouvelle adresse. Par exemple, le serveur peut utiliser la plus petite adresse récemment assignée. Comme contrôle d'uniformité, le serveur allocataire DEVRAIT vérifier l'adresse réutilisée avant d'allouer l'adresse, par ex. par une demande d'écho ICMP, et le client DEVRAIT vérifier la nouvelle adresse reçue, par ex. avec ARP.

 

3. Le protocole Client - serveur

DHCP utilise les messages BOOTP définis dans le RFC 951 et donnés dans le tableau 1 et la figure 1. Le champ 'op' de chaque message DHCP envoyé par un client à un serveur contient BOOTREQUEST. BOOTREPLY est utilisé dans le champ 'op' de chaque message DHCP d'un serveur vers un client. Les 4 premiers octets du champ 'options' d'un message DHCP contiennent les valeurs (décimales) 99, 130, 83 et 99, (il s'agit du même cookie magique que celui défini dans le RFC 1497 [17]). Le reste du champ 'options' consiste en une liste de paramètres marqués qui sont appelé "options". Toutes les "extensions fournisseurs" listées dans le RFC 1497 sont aussi des options DHCP. Le RFC 1533 donne la liste complète des options utilisables dans DHCP.

Plusieurs options ont déjà été définies. L'option "type du message DHCP" doit être incluse dans chaque message. Cette option définit le "type" du message DHCP. Des options supplémentaires peuvent être permises, requises ou non permises ; cela dépend du type de message DHCP.

Au travers de ce document, les messages DHCP qui contiennent une option 'Type du message DHCP' seront liés au type du message. Par ex : un message DHCP avec un 'type du message DHCP' option type 1 seront considérés comme des messages DHCPDISCOVER.

3.1 L'interaction client - serveur - allocation d'une adresse réseau

Le résumé suivant du protocole d'échange entre clients et serveurs se réfère aux messages DHCP décrits dans le tableau 2. Le diagramme temporel de la figure 3 montre les relations temporelles dans une interaction typique entre un client et un serveur. Si le client connaît déjà son adresse, certaines étapes peuvent être omises, cette interaction réduite est décrite dans la section 3.2

1. Le client diffuse un message DHCPDICOVER sur son réseau local physique. Le message DHCPDISCOVER PEUT inclure des options qui suggèrent des valeurs pour les adresses réseau et la durée du bail. Les agents de relais BOOTP peuvent passer le message sur des serveurs DHCP qui ne se trouvent pas sur le même sous réseau physique.

2. Chaque serveur peut répondre avec un message DHCPOFFER qui inclut une adresse réseau valide dans le champ 'yiaddr' (et d'autres paramètres de configuration des options DHCP). Le serveur n'a pas besoin de réserver l'adresse réseau offerte, bien que le protocole fonctionnera de manière optimale si le serveur évite d'allouer les adresses offertes à un autre client. Quand on alloue une nouvelle adresse les serveurs DOIVENT vérifier que l'adresse réseau offerte n'est pas déjà utilisée ; par ex : le serveur devrait vérifier les adresses offertes par une requête d'écho ICMP. Les serveurs DEVRAIENT être implantés de manière à ce que les administrateurs réseaux puissent choisir de désactiver les vérifications des adresses nouvellement allouées. Le serveur transmet un message DHCPOFFER au client, en utilisant l 'agent de relais BOOTP si nécessaire.

Message

Utilisation

DHCPDISCOVER

Diffusion du client pour localiser les serveurs disponibles

DHCPOFFER

Du serveur au client pour répondre au DHCPDISCOVER avec les paramètres de configuration.

DHCPREQUEST

Message client aux serveurs soit (a) qui demande les paramètres à un serveur et décline implicitement les offres de tous les autres, (b) qui confirme la validité des adresses précédemment allouées, par ex : un redémarrage système, ou (c) qui étend le bail pour une adresse réseau en particulier.

DHCPACK

Du serveur au client avec les paramètres de configuration et qui inclut l'adresse réseau déjà attribuée.

DHCPNAK

Du serveur au client indiquant que la notion d'un client pour les adresses réseau est incorrecte. (par ex : si un client est déplacé sur un nouveau sous réseau) ou que le bail du client a expiré.

DHCPDECLINE

Client vers serveur indiquant que l'adresse réseau est déjà utilisée.

DHCPRELEASE

Client vers serveur libérant l'adresse réseau et annulant le bail.

DHCPINFORM

Client vers serveur, demandant seulement les paramètres de configuration locaux ; le client possède déjà une adresse réseau attribuée de manière externe.

Table 2: messages DHCP


Serveur Client Serveur (non sélectionné) (sélectionné) v v v | | | | début initialisation | | | | | _____________/|\____________ | |/DHCPDISCOVER | DHCPDISCOVER \| | | | Détermine la | Détermine la configuration | configuration | | | |\ | ____________/| | \________ | /DHCPOFFER | | DHCPOFFER\ |/ | | \ | | | collecte les réponses | | \| | | Sélectionne la configuration | | | | | _____________/|\____________ | |/ DHCPREQUEST | DHCPREQUEST\ | | | | | | Engage la configuration | | | | | _____________/| | |/ DHCPACK | | | | | Initialisation complète | | | | . . . . . . | | | | fermeture élégante | | | | | |\ ____________ | | | DHCPRELEASE \| | | | | | libération du bail | | | v v v
Figure 3: diagramme temporel des messages échangés entre les clients et les serveurs DHCP quand on alloue une nouvelle adresse

3. Le client reçoit un ou plusieurs messages DHCPOFFER d'un ou plusieurs serveurs. Le client peut choisir d'attendre des réponses multiples. Le client choisit un serveur pour ses paramètres de configuration, basé sur la configuration présente dans le DHCPOFFER. Le client diffuse un message DHCPREQUEST qui DOIT inclure l'option 'identifiant serveur' indiquant quel serveur il a sélectionné et qui PEUT inclure d'autres options spécifiant les valeurs de configuration désirées. L'option 'adresse IP demandée' DOIT être réglée sur la même valeur que 'yiaddr' du message DHCPOFFER provenant du serveur. Ce DHCPREQUEST est diffusé et relayé au travers de l'agent de relais DHCP/BOOTP. Pour s'assurer que n'importe quel agent de relais fasse suivre le message DHCPREQUEST au même serveur DHCP qui a reçu le message DHCPDISCOVER original, le DHCPREQUEST DOIT ut iliser les même valeurs dans l'en-tête du champ 'secs' du message DHCP et être envoyé à la même adresse IP de diffusion que le message DHCPDISCOVER originel. Le client clôture à la fin d'un délai d'attente et retransmet le message DHCPDISCOVER si le client ne reçoit pas de messages DHCPOFFER.

4. Les serveurs reçoivent les diffusions DHCPREQUEST des clients. Les serveurs qui ne sont pas sélectionnés par le message DHCPREQUEST interprètent ce message comme une notification que le client décline leur offre. Le serveur sélectionné dans le message DHCPREQUEST initie une transaction avec le client dans sa mémoire permanente et répond avec un message DHCPACK qui contient la configuration pour le client demandeur. La combinaison entre 'identifiant client' ou 'chaddr' et l'adresse réseau assignée constitue un identifiant unique pour le bail du client. Elle est utilisée à la fois par le client et le serveur pour identifier un bail auquel il sera fait référence dans tous les messages DHCP. Aucun paramètre de configuration contenu dans le message DHCPACK NE DEVRAIT produire de conflit avec ceux du précédent message DHCPOFFER auquel le client r&eacut e;pond. Le serveur NE DEVRAIT PAS vérifier l'adresse réseau offerte a ce stade. Le 'yiaddr' du DHCPACK est initialisé avec l'adresse réseau sélectionnée.

Si le serveur sélectionné est indisponible pour satisfaire la requête du message DHCPREQUEST (par ex : l'adresse réseau demandée a été allouée), le serveur DEVRAIT répondre par un message DHCPNAK.

Un serveur PEUT choisir de marquer comme indisponibles les adresses offertes aux clients dans un message DHCPOFFER. Le serveur DEVRAIT marquer comme disponible une adresse offerte à un client dans un message DHCPOFFER si le serveur ne reçoit pas de message DHCPREQUEST de ce client.

5. Le client reçoit un message DHCPACK avec les paramètres de configuration. Le client DEVRAIT faire une vérification finale sur les paramètres (par ex : ARP pour l'allocation de l'adresse réseau), et noter la durée du bail spécifié dans le DHCPACK. A ce moment, le client est configuré. Si le client détecte que l'adresse est déjà utilisée (par ex : via l'utilisation de ARP) le client DOIT envoyer un DHCPDECLINE au serveur et relancer le processus de configuration. Le client DEVRAIT attendre un minimum de dix secondes avant de relancer la configuration pour éviter un trafic réseau excessif dans le cas d'un bouclage.

Si le client reçoit un DHCPNACK, le client relance le processus de configuration.

Le client clôture la transaction à la fin d'un délai d'attente et retransmet le message DHCPREQUEST s'il ne reçoit ni DHCPACK ni DHCPNACK. Le client retransmet le DHCPREQUEST conformément à l'algorithme de retransmission de la section 4.1.Le client devrait choisir de retransmettre le DHCPREQUEST un nombre suffisant de fois pour espérer contacter le serveur sans faire en sorte qu'il (le client et par extension son utilisateur) n'attende trop longtemps avant d'abandonner; par ex : un client retransmettant comme décrit dans la section 4.1 pourrait retransmettre le DHCPREQUEST 4 fois sur un total de 60 secondes, avant de relancer la procédure d'initialisation. Si le client ne reçoit ni DHCPACK ni DHCPNAK après l'utilisation de l'algorithme de retransmission, il retourne à l'état INIT et relance le processus d'initialisation. Le client DEVRAIT notifier à l'utilisateur que le pr ocessus d'initialisation n'a pas abouti et qu'il est relancé.

6. Le client peut choisir de renoncer au bail sur une adresse réseau en envoyant un DHCPRELEASE au serveur. Le client identifie le bail qu'il libère avec son 'identifiant client' ou 'chaddr' et l'adresse réseau dans le message DHCPRELEASE. Si le client utilise un 'identifiant client' quand il obtient le bail il DOIT utiliser le même 'identifiant client' dans le message DHCPRELEASE.

3.2 Interaction client serveur - Réutilisation d'une adresse réseau anciennement attribuée.

Si un client se souvient d'une adresse réseau qui lui a été attribuée par le passé et souhaite la réutiliser, il peut choisir d'omettre les étapes décrites précédemment. Le diagramme temporel de la figure 4 montre la relation temporelle dans une interaction classique client-serveur pour un client réutilisant une adresse réseau qui lui avait déjà été attribuée dans le passé.

1. Le client diffuse un message DHCPREQUEST sur son sous-réseau local. Le message inclut l'adresse réseau du client dans l'option 'adresse IP demandée'. Comme le client n'a pas encore reçu son adresse réseau, il NE DOIT PAS remplir le champ 'ciaddr'. Les agents de relais BOOTP transmettent le message au serveur DHCP qui n'est pas sur le même sous réseau. Si le client utilise un 'identifiant client' pour obtenir son adresse, le client DOIT utiliser le même 'identifiant client' dans le message DHCPREQUEST.

2. Les serveurs qui connaissent les paramètres de configuration du client répondent avec un DHCPACK au client. Les serveurs NE DEVRAIENT PAS vérifier que l'adresse réseau du client est déjà utilisée; le client peut répondre à une demande d'écho ICMP à cet instant.

    Serveur          Client          Serveur        v                v               v            |                |               |            |             début              |            |          initialisation        |            |                |               |            |               /|\              |            |   ___________/ | \__________   |            | / DHCPREQUEST  |  DHCPREQUEST\ |            |/               |              \|            |                |               |       Localisation          |          Localisation configuration          |         configuration       |                |               |            |\               |              /|            | \              |  ___________/ |            |  \             | /  DHCPACK    |            |   \ _______    |/              |            |     DHCPACK\   |               |            |          Initialisation        |            |             complète           |            |               \|               |            |                |               |            |            (DHCPACKS           |            |             ultérieurs         |            |             ignorés)           |            |                |               |            |                |               |            v                v               v     

Figure 4: Diagramme temporel des messages échangés entre le client DHCP et les serveurs quand il réutilise une adresse ayant été précédemment attribuée.

Si la requête du client est invalide (par ex : le client a changé de sous réseau), les serveurs DEVRAIENT répondre par un message DHCPNAK au client. Les serveurs NE DEVRAIENT PAS répondre si l'exactitude de leurs informations n'est pas garantie. Par exemple, un serveur qui identifie une requête pour une affectation périmée qui est détenue par un autre serveur NE DEVRAIT PAS répondre avec un DHCPNAK à moins que les serveurs n'utilisent un mécanisme explicite pour maintenir une cohérence entre les serveurs.

Si 'giaddr' est 0x0 dans le message DHCPREQUEST, le client est sur le même sous réseau que le serveur. Le serveur DOIT diffuser le message DHCPNAK à l'adresse de diffusion 0xffffffff parce que le client peut ne pas avoir d'adresse réseau correcte ou le bon masque de sous réseau, et le client ne peut pas répondre à une requête ARP. De plus, le serveur DOIT envoyer le message DHCPNAK à l'adresse de l'agent de relais BOOTP, comme enregistré dans le 'giaddr'. L'agent de relais pourra, en retour, faire suivre le message directement, à l'adresse matérielle du client, de manière à ce que le DHCPNAK puisse être délivré même si le client s'est déplacé vers un nouveau réseau.

3.Le client reçoit le message DHCPACK avec les paramètres de configuration. Le client effectue une vérification finale sur les paramètres (comme dans la section 3.1), et note la durée du bail spécifiée dans l'identifiant client ou 'chaddr' et l'adresse réseau. A ce stade, le client est configuré.

Si le client détecte que l'adresse IP dans le message DHCPACK est déjà utilisée, le client DOIT envoyer un message DHCPDECLINE au serveur et relancer le processus de configuration en faisant la requête d'une nouvelle adresse réseau. L'action correspond à un déplacement du client vers l'état INIT dans le diagramme DHCP, qui est décrit dans la section 4.4.

Si le client reçoit un message DHCPNAK, il ne peut réutiliser l'adresse dont il se souvient. Il doit faire la requête d'une nouvelle adresse en relançant le processus de configuration, cette fois en utilisant la procédure (non abrégée) décrite dans la section 3.1. Cette action correspond également à un client qui se place dans l'état INIT du diagramme DHCP.

Le client clôture la transaction à la fin d'un délai d'attente et retransmet le message DHCPREQUEST si le client ne reçoit ni un DHCPACK ni un DHCPNAK. Le client retransmet le DHCPREQUEST en accord avec l'algorithme de retransmission de la section 4.1. Le client devrait choisir de retransmettre le DHCPREQUEST un nombre suffisant de fois pour espérer contacter le serveur sans faire en sorte qu'il (le client, et par extension, l'utilisateur du client) attende trop longtemps avant d'abandonner; par ex : un client retransmettant comme décrit dans la section 4.1 pourrait retransmettre le DHCPREQUEST 4 fois sur un total de 60 secondes, avant de relancer la procédure d'initialisation. Si le client ne reçoit ni DHCPACK ni DHCPNAK après avoir employé l'algorithme de retransmission, le client PEUT choisir d'utiliser une adresse réseau alloué précédemment et les paramètres de configurations pour les baux non expirés. Ceci corresponds à un déplacement vers l'état AFFECTÉ dans le diagramme de la figure 5.

4. Le client peut choisir de renoncer à son bail sur une adresse réseau en envoyant un message DHCPRELEASE au serveur. Le client identifie le bail dont il veut se défaire avec l'identifiant client ou 'chaddr' et l'adresse réseau dans le message DHCPREALEASE.

Notez que dans ce cas, le client retient son adresse réseau localement. Normalement le client ne renonce pas à son bail lors d'un arrêt normal. Lorsque le client doit explicitement renoncer à son bail, et dans ce cas seulement (par ex : le client va être déplacé sur un autre sous réseau), il émettra un message DHCPRELEASE.

3.3 Interprétation et représentation des valeurs de temps

Un client acquièrt un bail pour une adresse réseau pour une période fixe (qui peut être infinie). Dans ce protocole, l'unité de temps est la seconde. La valeur temps 0xffffffff est réservée pour représenter l'infini. Comme un client et un serveur n'ont pas forcément une horloge synchronisée, et pour être interprété correctement par les horloges des clients locaux, le temps est représenté dans les messages par des données relatives. Le temps relatif, représenté en secondes dans un mot de 32 bits non signé, donne une plage de temps relatif de 0 à environ 100 ans, ce qui est suffisant pour les durées mesurées dans DHCP.

L'algorithme pour l'interprétation de la durée du bail donné dans le paragraphe précédent considère que les horloges du client et du serveur sont relativement stables. Si il y a un décalage entre les deux horloges, le serveur peut considérer que le bail a expiré avant que le client ne le fasse. Pour compenser, le serveur peut retourner au client un bail d'une duré plus courte que celle assignée dans sa base de donnée locale des informations du client.

3.4 Obtenir des paramètres avec des adresses réseau configurées de manière externe.

Si un client a obtenu une adresse réseau grâce à d'autres moyens (par ex. configuration manuelle) il peut utiliser une requête DHCPINFORM pour obtenir d'autres paramètres locaux de configuration. Les serveurs recevant un message DHCPINFORM construisent un message DHCPACK avec n'importe quels paramètres de configuration appropriés pour le client sans : allouer d'adresse, vérifier une liaison existante, remplir le 'yiaddr' ou inclure des durées de bail. Les serveurs DEVRAIENT faire une réponse adressée DHCPACK à l'adresse donnée dans le champs 'ciaddr' du message DHCPINFORM.

Le serveur DEVRAIT vérifier l'adresse réseau dans un message DHCPINFORM, mais il NE DOIT PAS vérifier l'existence d'un bail. Le serveur formule un message DHCPACK contenant les paramètres de configurations pour le client ayant émis la requête et envoie le message DHCPACK directement au client.

3.5 Les paramètres client dans le DHCP

Tous les clients ne requièrent pas l'initialisation de tous les paramètres listés dans l'annexe A. Deux techniques sont utilisées pour réduire le nombre de paramètres transmis du serveur vers le client. Premièrement, la plupart des paramètres ont des valeurs par défauts définies dans les RFC des obligations des hôtes ('Host Requirements'), si un client ne reçoit pas de paramètres d'un serveur qui remplacent ces valeurs par défaut, un client utilise ces valeurs par défaut. Deuxièmement, dans son message initial DHCPDISCOVER ou DHCPREQUEST, un client peut fournir au serveur une liste de paramètres spécifiques qui l'intéressent. Si le client inclut une liste de paramètres dans un message DHCPDISCOVER, il DOIT inclure cette liste de paramètres dans un DHCPREQUEST ultérieur.

Le client DEVRAIT inclure l'option 'taille maximum des messages DHCP' pour permettre au serveur de connaître la taille que peuvent prendre ses messages DHCP. Les paramètres retournés à un client peuvent dépasser l'espace alloué dans un message DHCP. Dans ce cas, deux drapeaux optionnels supplémentaires (qui doivent apparaître dans le champ 'options' du message) indiquent que les champs 'fichier' et 'sname' doivent être utilisés en tant qu'options.

Le client peut informer le serveur des paramètres de configuration qui l'intéressent en incluant l'option 'liste des paramètres demandés'. La partie données de cette option liste de manière explicite les options requises par un numéro de marquage.

De plus, le client peut suggérer des valeurs pour les adresses réseau et la durée de bail dans le message DHCPDISCOVER. Le client peut inclure l'option 'Adresse IP demandée' pour suggérer qu'une adresse IP doit être attribuée, et peut inclure 'durée bail adresse IP' pour suggérer la durée de bail qu'il désire. D'autres options, qui sont des suggestions pour les paramètres de configuration, sont permises dans un DHCPDISCOVER ou un DHCPREQUEST. De toutes manières, les options supplémentaires peuvent être ignorées par les serveurs, et de multiples serveurs peuvent, en plus, ne pas retourner des valeurs identiques pour certaines options. Le champ 'adresse IP demandée' doit être rempli dans un message DHCPREQUEST seulement quand le client vérifie les paramètres réseaux obtenus précédemment. Le client remplit le champ 'ciad dr' seulement quand il est correctement configuré avec une adresse IP dans l'état AFFECTÉ, RENOUVELLEMENT, REAFFECTATION.

Si un serveur reçoit un message DHCPREQUEST avec une 'Adresse IP demandée' invalide, le serveur DEVRAIT répondre avec un DHCPNAK et peut choisir de signaler le problème à un administrateur système. Le serveur peut inclure un message d'erreur dans une option 'message'.

3.6 Utilisation de DHCP avec des clients à interface multiple

Un client avec des interfaces réseaux multiples peut utiliser DHCP au travers de chacune de ses interfaces de manière indépendante pour obtenir des informations sur les paramètres de configuration pour chacune de ces interfaces.

3.7 Quand un client doit-il utiliser DHCP ?

Un client doit utiliser DHCP pour obtenir de nouveau ou vérifier son adresse IP et les paramètres réseau chaque fois que les paramètres réseau local ont changé ; par ex : au moment du démarrage système ou après une déconnexion du réseau local, car la configuration du réseau local peut avoir changé sans que le client ou l'utilisateur n'en ait eu connaissance.

Si le client a connaissance d'une précédente adresse réseau et qu'il est incapable de contacter un serveur DHCP local, il peut continuer d'utiliser cette adresse jusqu'à ce que le bail soit expiré. Si le bail expire avant que le client n'ait eu le temps de contacter le serveur DHCP, le client doit immédiatement stopper l'utilisation de l'adresse réseau et peut informer les utilisateurs locaux du problème.

 

4 Spécification du protocole client-serveur

Dans cette section on s'appuie sur le fait que le serveur DHCP possède un bloc d'adresses réseau à partir desquelles il peut satisfaire les requêtes d'adresse. Chaque serveur maintient également, dans un espace de stockage local, une base de données des adresses allouées et des baux.

4.1 Construire et envoyer des messages DHCP

Les clients et serveurs DHCP construisent tout deux des messages DHCP en remplissant les champs de la partie fixe des messages et ajoutant des données marquées dans la zone option de longueur variable. La zone des options inclut d'abord un 'cookie magique' de 4 octets (qui à été décrit dans la section 3) suivi par les options. La dernière option doit toujours être 'end'.

DHCP utilise le protocole de transport UDP. Les messages DHCP d'un client vers un serveur sont envoyés au port (67) du 'serveur DHCP' et les messages d'un serveur vers un client sont envoyé au port (68) 'client DHCP'. Un serveur avec de multiples adresses réseau (par ex : une machine multi-sites) PEUT utiliser n'importe laquelle de ses adresses dans un message DHCP sortant.

Le champ 'identifiant serveur' est utilisé à la fois pour identifier un serveur DHCP dans un message DHCP et comme adresse de destination d'un client vers des serveurs. Un serveur avec plusieurs adresses réseau DOIT être préparé à accepter n'importe qu'elle adresse réseau pour la réception des messages. Pour accommoder les connexités réseaux potentiellement incomplètes, un serveur DOIT choisir une adresse comme étant 'identifiant serveur' qui, pour une meilleur connaissance du serveur, soit accessible à partir du client. Par exemple, si le serveur DHCP et le client DHCP sont connectés sur le même sous-réseau (c'est-à-dire, le champ 'giaddr' dans le message client est à zéro) le serveur DOIT sélectionner l'adresse IP que le serveur utilise comme adresse de communication sur ce sous-réseau en tant que 'identifiant serveur'. S i le serveur utilise des adresses multiples sur ce réseau, n'importe quelle adresse peut être utilisée. Si le serveur a reçu un message au travers d'un agent de relais DHCP, le serveur DEVRAIT choisir une adresse de l'interface sur laquelle il a reçu le message comme 'identifiant serveur' (à moins que le serveur n'ait de meilleures informations). Les clients DHCP DOIVENT utiliser l'adresse IP fournie dans l'option 'identifiant serveur' pour toutes les requêtes adressées au serveur DHCP.

Les messages DHCP diffusés par un client avant qu'il n'ait obtenu son adresse IP doivent avoir mis à 0 leur champ d'adresse source de l'en-tête IP.

Si le champ 'giaddr' dans un message DHCP d'un client n'est pas à zéro, le serveur envoie tous les messages de réponse au port 'serveur DHCP' de l'agent de relais BOOTP dont l'adresse apparaît dans le 'giaddr'. Si le 'giaddr' est à zéro et que le champ 'ciaddr' n'est pas à zéro, alors le serveur adresse les messages DHCPOFFER et DHCPACK à l'adresse du 'ciaddr'. Si 'giaddr' est à zéro et que le bit de diffusion est positionné, alors le serveur diffuse les messages DHCPOFFER et DHCPACK à 0xffffffff. Si le bit de diffusion n'est pas positionné et que 'giaddr' et 'ciaddr' sont à zéro, alors le serveur envoie les messages DHCPOFFER et DHCPACK à l'adresse matérielle du client et à l'adresse 'yiaddr'. Dans tout les cas, quand 'giaddr' est à zéro, le serveur diffuse n'importe quel message DHCPNAK à tous (adresse réseau 0xff ffffff).

Si les options dans un message DHCP s'étendent dans les champs 'sname' et 'fichier', l'option 'surcharge option' DOIT apparaître dans le champ 'options' avec pour valeur 1,2 ou 3 comme spécifié dans le RFC 1533. Si l'option 'surcharge option' est présente dans le champ 'options', les options du champ 'options' DOIVENT être terminées par l'option 'end', et PEUVENT contenir un ou plusieurs 'bourrage' pour remplir le champ d'options. Les options dans les champs 'sname' et 'fichier' (si utilisé comme indiqué par le 'surcharge option') DOIVENT commencer par le premier octet du champ, DOIVENT être terminées par l'option 'end', et DOIVENT être suivies par les options 'bourrage' pour remplir le reste du champ. N'importe quelle option dans les champs 'options', 'sname' et 'fichier' DOIT être entièrement contenue dans ce champ. Les options dans le champ 'options' DOIVENT être interpr&e acute;tées en premier, de manière à ce que n'importe quelle option 'surcharge option' puisse être interprétée. Le champ 'fichier' DOIT être interprété ensuite (si le champ 'surcharge option' indique que le champ 'fichier' contient des options DHCP), suivi par le champ 'sname'.

Les valeurs qui doivent être passées dans le marquage 'option' pourront être trop longues pour tenir sur les 255 octets disponibles pour une seule option (par ex : une liste de routeurs dans l'option 'routeurs' [21]). Les options pourront apparaître une fois seulement, à moins d'être spécifiées autrement dans le document options. Le client concatène les valeurs des occurrences multiples de la même option dans une seule liste de paramètres de configuration.

Les clients DHCP sont responsables de toutes les retransmissions de messages. Le client DOIT adopter une stratégie de retransmission qui incorpore un algorithme aléatoire exponentiel pour déterminer le délai entre les transmissions. Le délai entre les transmission DEVRAIT être choisi de manière à laisser suffisamment de temps au serveur pour répondre, en se basant sur les caractéristiques de l'inter-réseau entre client et serveur. Par exemple, dans un réseau Ethernet à 10Mb/sec, le délai avant la première retransmission DEVRAIT être de 4 secondes modifié de manière aléatoire par la valeur d'un nombre aléatoire uniforme choisi entre -1 et +1. Les clients avec des horloges qui fournissent des résolutions de moins d'une seconde peuvent choisir une valeur aléatoire non entière. Le délai avant retransmission suivan te DEVRAIT être de 8 secondes rendu aléatoire par la valeur d'un nombre uniforme choisi entre -1 et +1. Le délai de retransmission DEVRAIT être doublé pour les retransmission ultérieures jusqu'à un délai maximum de 64 secondes. Le client POURRAIT fournir une indication sur les tentatives de retransmission à l'utilisateur comme un indicateur de progression du processus de configuration.

Le champ 'xid' est utilisé par le client pour associer les messages DHCP entrants avec les requêtes en cours. Un client DHCP DOIT choisir 'xid' de manière à minimiser les risques d'avoir un 'xid' identique à celui utilisé par un autre client. Par exemple, un client peut choisir un 'xid' initial aléatoire à chaque fois que le client redémarre, et ensuite utiliser des 'xid' séquentiels jusqu'au prochain redémarrage. Choisir un nouveau 'xid' pour chaque retransmission est un choix de l'implantation. Un client peut choisir de réutiliser le même 'xid' ou choisir un nouveau 'xid' pour chaque message retransmis.

Normalement les serveurs DHCP et les agents de relais BOOTP tentent de délivrer les messages DHCPOFFER, DHCPACK, et DHCPNAK directement au client en utilisant les livraisons adressées. L'adresse IP de destination (dans l'en-tête IP) est réglée sur l'adresse DHCP 'yiaddr' et l'adresse de destination couche liaison est réglée sur l'adresse DHCP 'chaddr'. Malheureusement, quelques implantations clientes ne sont pas capable de recevoir de tels datagrammes IP adressés jusqu'à ce que l'implantation n'ait été configurée avec une adresse IP valide (conduisant à une boucle sans fin dans laquelle l'adresse IP du client ne peut être livrée jusqu'à ce que le client n'ait été configuré avec une adresse IP valide).

Un client qui ne peut recevoir les datagrammes IP adressés jusqu'à ce que son logiciel n'ai été configuré avec une adresse IP, DEVRAIT régler le bit diffusion dans le champ 'flags' à 1 dans tous les messages DHCPDISCOVER ou DHCPREQUEST qu'il émet. Le bit diffusion pourra fournir un indice au serveur DHCP et à l'agent de relais BOOTP pour diffuser tout message au client sur son sous-réseau. Un client qui peut recevoir des datagrammes IP adressés avant que son logiciel n'ai été configuré POURRAIT mettre le bit diffusion à 0. Le document de clarification BOOTP spécifie les ramifications de l'utilisation du bit de diffusion [21].

Un serveur ou un agent de relais qui envoie ou relaie un message DHCP directement à un client DHCP (c'est-à-dire, pas à un agent de relais spécifié dans le champ 'giaddr') DEVRAIT examiner le bit diffusion dans le champ 'flags'. Si ce bit est à un, le message DHCP DEVRAIT être envoyé en tant que diffusion IP utilisant l'adresse IP de diffusion (de préférence 0xffffffff) comme adresse destination IP et l'adresse de diffusion de la couche liaison comme adresse destination de la couche liaison. Si le bit diffusion est à 0, le message DEVRAIT être envoyé en tant que message IP individuel adressé à l'adresse IP spécifiée dans le champ 'yiaddr' et l'adresse de couche liaison spécifiée dans le champ 'chaddr'. S'il est impossible de faire un adressage, le message PEUT être envoyé comme une diffusion IP qui utilise l'adresse IP de diffusio n (de préférence 0xffffffff) comme adresse IP destination et l'adresse de diffusion de couche liaison comme adresse de couche liaison.

4.2 Les outils de contrôle d'administration d'un serveur DHCP

Les serveurs DHCP ne sont pas obligés de répondre à chaque message DHCPDISCOVER et DHCPREQUEST qu'ils reçoivent. Par exemple, un administrateur réseau, pour avoir un contrôle strict sur les clients attachés au réseau, peut choisir de configurer les serveurs DHCP pour qu'ils répondent seulement aux clients qui ont été précédemment enregistrés au travers d'un mécanisme externe. La spécification DHCP décrit seulement les interactions entre les clients et les serveurs, quand les clients et les serveurs choisissent d'interagir; c'est au delà des limites de la spécification DHCP de décrire tous les contrôles d'administration qu'un administrateur système peut vouloir utiliser. Des implantations particulières du serveur DHCP peuvent incorporer n'importe quels contrôles ou stratégies désirés par un administrateur réseau.

Dans certains environnements, un serveur DHCP devra considérer les valeurs des options de la classe 'fournisseur' incluses dans les messages DHCPDISCOVER ou DHCPREQUEST quand il détermine les paramètres corrects pour un client particulier.

Un serveur DHCP a besoin d'utiliser des identifiants uniques pour associer un client avec son bail. Le client PEUT choisir de fournir de manière explicite l'identifiant au travers de l'option 'identifiant client'. Si le client fournit un 'identifiant client', il DOIT utiliser le même 'identifiant client' dans tout les messages qui suivront, et le serveur DOIT utiliser cet identifiant pour identifier ce client. Si le client ne propose pas l'option 'identifiant client', le serveur DOIT utiliser le contenu de 'chadrr' pour identifier le client. Il est crucial pour un client DHCP d'utiliser un identifiant unique à l'intérieur d'un sous réseau auquel il est attaché dans l'option 'identifiant client'. L'utilisation d'un 'chaddr' en tant qu'identifiant unique pour un client peut conduire à des résultats inattendus, car cet identifiant peut être associé à une interface matérielle qui peut être déplacée vers un autre client. Certains sites peuvent choisir d'utiliser le numéro de série en tant qu'identifiant, pour éviter des changement inattendus dans les adresses réseaux dus au transfert d'interfaces matérielles entre des ordinateurs. Des sites peuvent aussi choisir d'utiliser un nom DNS pour l'identification client, provoquant un adressage associé avec un nom DNS plutôt qu'avec un matériel spécifique.

Les clients sont libre d'utiliser n'importe quelle stratégie dans la sélection d'un serveur DHCP parmi ceux dont ils reçoivent le message DHCPOFFER. L'implantation du client DHCP DEVRAIT fournir un mécanisme à l'utilisateur afin qu'il puisse sélectionner directement des valeurs du 'identifiant classe fournisseur'

4.3 Comportement du serveur DHCP.

Un serveur DHCP traite les messages DHCP provenant d'un client selon l'état courant de l'affectation pour ce client. Un serveur DHCP peut recevoir les messages suivants d'un client :

o DHCPDISCOVER

o DHCPREQUEST

o DHCPDECLINE

o DHCPRELEASE

o DHCPINFORM

Le tableau 3 donne l'utilisation faite par un serveur des champs et des options dans un message DHCP. Le reste de cette section décrit l'action du serveur DHCP pour chaque message entrant.

4.3.1 Le message DHCPDISCOVER

Quand un serveur reçoit un message DHCPDISCOVER d'un client, le serveur choisit une adresse réseau pour le client demandeur. Si aucune adresse n'est disponible, le serveur peut choisir de rapporter le problème à l'administrateur système. Si une adresse est disponible, la nouvelle adresse DEVRAIT être choisie en fonction de :

o L'adresse courante du client telle qu'elle a été enregistrée dans l'affectation du client, SINON

o L'adresse précédente du client telle qu'elle a été enregistrée dans l'affectation du client (maintenant expirée ou relâchée), si cette adresse est dans la suite d'adresses disponibles et pas encore alloué, SINON

o L'adresse demandée dans l'option 'adresse IP demandée' si cette adresse est valide et n'est pas déjà alloué, SINON

o Une nouvelle adresse allouée à partir d'une suite d'adresses valides; l'adresse est sélectionnée en fonction du sous-réseau à partir duquel le message a été reçu (si 'giaddr est 0) ou en fonction de l'adresse de l'agent de relais qui suivait le message ('giaddr' quand différent de 0).

Comme décrit dans la section 4.2, un serveur PEUT, pour des raisons d'administration, assigner une adresse autre que celle demandée, ou peut refuser d'allouer une adresse à un client particulier même si des adresses sont libres.

Il est à noter, que dans certaines architectures réseau (ex., Internet avec plus d'une adresse IP de sous-réseau assignée à un segment physique du réseau), cela peut être le cas quand un client DHCP devra se voir assigner une adresse d'un sous-réseau différent plutôt que celle enregistré dans 'giaddr'. De plus, DHCP ne requièrt pas que le client se voient assigner une adresse identique à l'option 'giaddr'. Un serveur est libre de choisir un autre sous réseau, et il est hors des limites de la spécification du DHCP de décrire les manières par lesquelles l'adresse IP devrait être choisie.

Bien que cela ne soit pas requis pour le bon fonctionnement de DHCP, le serveur NE DEVRAIT PAS réutiliser l'adresse réseau sélectionnée avant que le client ne réponde au message DHCPOFFER du serveur. Le serveur peut choisir d'enregistrer l'adresse telle qu'offerte au client.

Le serveur doit aussi choisir un délai d'expiration pour le bail, comme suit :

o Si le client n'a pas fait la demande d'un bail spécifique dans le message DHCPDISCOVER et que le client possède déjà une adresse réseau, le serveur retourne le temps d'expiration du bail défini précédemment pour cette adresse (Il faut noter que le client doit explicitement demander un bail spécifique pour étendre le délai d'expiration sur une adresse précédemment attribuée), SINON

o Si le client n'a pas fait la demande d'un bail spécifique dans le message DHCPDISCOVER et que le client n'a pas d'adresse réseau attribuée, le serveur assigne le temps de bail par défaut configuré localement, SINON

o SI le client a fait la requête d'un bail spécifique dans le message DHCPDISCOVER (sans faire attention si le client à une adresse réseau assignée), le serveur peut choisir soit de retourner le bail demandé (si le bail est compatible avec la stratégie locale) ou de sélectionner un autre bail.

Champ

DHCPOFFER

DHCPACK

DHCPNAK

'op'

BOOTREPLY

BOOTREPLY

BOOTREPLY

'htype'

(Du RFC "Assigned Numbers")

'hlen'

(longueur de l'Adresse matérielle en octets)

'hops'

0

0

0

'xid'

'xid' du message DHCPDISCOVER client

'xid' du message DHCPREQUEST client

'xid' du message DHCPREQUEST client

'secs'

0

0

0

'ciaddr'

0

'ciaddr' du DHCPREQUEST ou 0

0

'yiaddr'

adresse IP offerte au client

adresse IP assignée au client

0

'siaddr'

adresse IP du serveur d'amorçage suivant

adresse IP du serveur d'amorçage suivant

0

'flags'

drapeaux du message client DHCPDISCOVER

drapeaux du message client DHCPREQUEST

drapeaux du message client DHCPREQUEST

'giaddr'

'giaddr' du message client DHCPDISCOVER

'giaddr' du message client DHCPREQUEST

'giaddr' du message client DHCPREQUEST

'chaddr'

'chaddr' du message client DHCPDISCOVER

'chaddr' du message client DHCPREQUEST

'chaddr' du message client DHCPREQUEST

'sname'

nom d'hôte serveur ou options

nom d'hôte serveur ou options

(inutilisé)

'fichier'

nom du fichier démarrage client ou options

nom du fichier démarrage client ou options

(inutilisé)

'options'

options

options

 
Option

DHCPOFFER

DHCPACK

DHCPNAK

adresse IP demandée

NE DOIT PAS

NE DOIT PAS

NE DOIT PAS

Durée du bail de l'adresse IP

DOIT

DOIT (DHCPREQUEST)

NE DOIT PAS (DHCPINFORM)

NE DOIT PAS

Utilisation des champs 'fichier'/'sname'

PEUT

PEUT

NE DOIT PAS

Type du message DHCP

DHCPOFFER

DHCPACK

DHCPNAK

Liste des Paramètres requis

NE DOIT PAS

NE DOIT PAS

NE DOIT PAS

Message

DEVRAIT

DEVRAIT

DEVRAIT

Identifiant client

NE DOIT PAS

NE DOIT PAS

PEUT

Identifiant de classe fournisseur

PEUT

PEUT

PEUT

Identifiant serveur

DOIT

DOIT

DOIT

Taille maximum des messages

NE DOIT PAS

NE DOIT PAS

NE DOIT PAS

Tout le reste

PEUT

PEUT

NE DOIT PAS


Tableau 3: Champs et options utilisés par les serveurs DHCP

Une fois que l'adresse réseau et le bail ont été déterminés, le serveur construit un message DHCPOFFER avec les paramètres de configurations offerts. Il est important pour tous les serveurs DHCP qu'ils retournent les mêmes paramètres (avec l'exception possible d'une adresse réseau nouvellement allouée) pour s'assurer que le client aura un comportement prévisible quel que soit le serveur choisi par le client. Les paramètres de configuration DOIVENT être sélectionnés en appliquant les règles ci-dessous dans l'ordre. L'administrateur réseau est responsable des multiples configurations des serveurs DHCP pour s'assurer de l'uniformité des réponses de ces serveurs. Le serveur DOIT retourner au client :

o L'adresse réseau du client, comme défini dans les règles données plus haut dans cette section,

o Le délai d'expiration pour le bail du client, comme déterminé dans les règles données plus haut dans cette section,

o Les paramètres requis par le client, en fonction des règles suivantes :

-- Si le serveur a été explicitement configuré avec une valeur par défaut pour le paramètre, le serveur DOIT inclure cette valeur dans une option appropriées du champ 'option', SINON

-- Si le serveur reconnaît le paramètre comme paramètre défini dans le 'Document obligations des machines', le serveur DOIT inclure la valeur par défaut pour ce paramètre comme donné dans la document mentionné ci-dessus dans une option appropriée du champ 'option' SINON

-- Le serveur NE DOIT PAS retourner de valeur pour ce paramètre.

Le serveur doit fournir autant de paramètres demandés que possible et DOIT omettre tous les paramètres qu'il ne peut fournir. Le serveur DOIT inclure chaque paramètre requis une fois seulement, à moins que cela ne soit explicitement permis dans les options DHCP et le document Extensions fournisseurs BOOTP.

o Tout paramètre de l'affectation existante qui diffère des valeurs par défauts du 'Document obligations des machines',

o Tout paramètre spécifique à ce client (comme identifié par le contenu du 'chaddr' et du 'identifiant client' dans le DHCPDISCOVER ou le DHCPREQUEST), par ex. : comme configuré par l'administrateur réseau.

o Tout paramètre spécifique à cette classe de client (comme identifié par le contenu de l'option 'identifiant classe fournisseur' dans le message DHCPDISCOVER ou DHCPREQUEST), par ex. : comme configuré par l'administrateur réseau; les paramètres DOIVENT être identifiés exactement de la même manière entre l'identifiant de 'classe fournisseur' du client et les classes de clients identifiées par le serveur,

o Les paramètres avec des valeurs qui ne sont pas celles par défaut sur le sous-réseau du client.

Le serveur PEUT choisir de retourner le 'identifiant classe fournisseur' utilisé pour déterminer les paramètres dans le message DHCPOFFER, de manière à assister le client afin qu'il puisse choisir un message DHCPDISCOVER. Le serveur insère le champ 'xid' du message DHCPDISCOVER dans le champ 'xid' du message DHCPOFFER et envoie le message DHCPOFFER au client qui fait la demande.

4.3.2 message DHCPREQUEST

Un message DHCPREQUEST peut venir d'un client répondant à un message DHCPOFFER du serveur, d'un client vérifiant une adresse IP précédemment allouée ou d'un client qui rallonge le bail sur une adresse réseau. Si le message DHCPREQUEST contient une option 'identifiant serveur', le message est la réponse à un DHCPOFFER. Sinon, le message est une requête pour vérifier ou étendre un bail existant. Si le client utilise un 'identifiant client' dans un message DHCPREQUEST, il DOIT utiliser le même 'identifiant client' dans tous les messages suivants. Si le client inclut une liste de paramètres requis dans un message DHCPDISCOVER il DOIT inclure cette liste dans tous les messages suivants.

Aucun paramètre de configuration contenu dans le message DHCPACK NE DEVRAIT créer de conflit avec ceux définis précédemment dans le DHCPOFFER auquel le client répond. Le client DEVRAIT utiliser les paramètres du message DHCPACK pour la configuration.

Les clients envoient les messages DHCPREQUEST comme suit :

o DHCPREQUEST généré durant l'état SELECTION :

Les clients insèrent l'adresse du serveur choisi dans 'identifiant serveur', 'ciaddr' doit être à 0, 'adresse IP demandée' DOIT être rempli avec l'adresse 'yiaddr' du DHCPOFFER choisi.

Notez que le client peut choisir de collecter plusieurs DHCPOFFER et peut choisir la meilleure offre. Le client notifie son choix en identifiant le serveur d'offre dans le DHCPREQUEST. Si le client ne reçoit aucune offre acceptable, il peut choisir d'essayer un autre DHCPOFFER. A ce stade, les serveurs peuvent ne pas recevoir le DHCPREQUEST spécifique à partir duquel ils peuvent décider si le client a accepté ou non l'offre. Parce que les serveurs n'ont assigné aucune adresse réseau sur la base d'un DHCPOFFER, ils sont libres de réutiliser les adresses réseau offertes en réponse à une demande. En tant que détail de l'implantation, les serveurs NE DEVRAIENT PAS réutiliser les adresses proposées et pourraient utiliser un mécanisme temporel spécifique à l'implantation, pour décider quand réutiliser de telles adresses.

o DHCPREQUEST généré pendant l'état INIT-REBOOT :

'identifiant serveur' NE DOIT PAS être rempli, l'option 'adresse IP demandée' DOIT être remplie avec l'adresse client précédemment assignée. 'ciaddr' doit être à 0. Le client cherche à vérifier une adresse précédemment allouée, une configuration en cache. Le serveur DEVRAIT envoyer un message DHCPNAK au client si l'adresse IP demandée est incorrecte, ou est sur un réseau erroné.

Déterminer si le client, dans un état INIT-REBOOT, est sur le bon réseau, se fait grâce à l'examen du 'giaddr', de l'option 'adresse IP demandée' et grâce à une vérification dans la base de données. Si le serveur DHCP détecte qu'un client est sur le mauvais réseau (c'est-à-dire, le résultat de l'application d'un masque local ou d'un masque distant (si 'giadr' n'est pas nul) sur 'adresse IP demandée' ne correspond pas à la réalité) alors le serveur POURRAIT envoyer un message DHCPNAK au client.

Si le réseau est correct, alors le serveur DHCP devrait vérifier si la notion qu'a le client de son adresse IP est correcte. Sinon, le serveur POURRAIT envoyer un message DHCPNAK au client. Si le serveur DHCP n'a pas de trace de ce client, alors il DOIT rester muet, et PEUT émettre une alerte vers l'administrateur réseau. Ce comportement est nécessaire pour la coexistence des serveurs DHCP non communicants sur le même segment de réseau physique.

Si 'giaddr' est 0x0 dans le message DHCPREQUEST, le client est sur le même sous-réseau que le serveur. Le serveur DOIT diffuser le message DHCPNAK à l'adresse de diffusion 0xffffffff parce que le client peut ne pas avoir la bonne adresse réseau ou le bon masque de sous-réseau, et le client peut ne pas pouvoir répondre aux requêtes ARP.

Si 'giaddr' est mis dans le message DHCPREQUEST, le client est sur un réseau différent. Le serveur DOIT mettre le bit de diffusion dans le DHCPNAK, de manière à ce que les agents de relais diffusent le DHCPNAK au client, parce que le client peut ne pas avoir la bonne adresse réseau ou le bon masque de sous-réseau et le client peut ne pas répondre aux requêtes ARP.

o DHCPREQUEST généré pendant l'état RENOUVELLEMENT :

'identifiant serveur' NE DOIT PAS être rempli, 'adresse IP demandée' NE DOIT PAS être rempli, 'ciaddr' DOIT être rempli avec l'adresse IP du client. Dans cette situation, le client est complètement configuré et essaie d'étendre son bail. Ce message sera adressé, donc aucun agent de relais ne sera utilisé dans cette transmission. Parce que 'giaddr' n'est pas rempli, le serveur DHCP fera confiance à la valeur 'ciaddr' et l'utilisera quand il répondra à ce client.

Un client peut choisir de renouveler ou d'étendre son bail jusqu'à T1. Le serveur peut choisir de ne pas étendre le bail (selon la stratégie de l'administrateur réseau), mais devrait retourner un message DHCPACK.

 

o DHCPREQUEST généré pendant l'état REAFFECTATION :

'identifiant serveur' NE DOIT PAS être rempli, 'adresse IP demandée' NE DOIT PAS être rempli, 'ciadr' DOIT être rempli avec l'adresse IP du client. Dans cette situation, le client est complètement configuré et essaye d'étendre son bail. Ce message DOIT être diffusé à l'adresse de diffusion 0xffffffff. Le serveur DHCP DEVRAIT vérifier la validité de 'ciaddr' avant de répondre au DHCPREQUEST.

Le DHCPREQUEST d'un client en REAFFECTATION est destiné à satisfaire les sites qui possèdent plusieurs serveurs DHCP et un mécanisme pour maintenir une certaines cohésion entre les différents baux contrôlés par les divers serveurs. Un serveur DHCP PEUT étendre le bail d'un client seulement s'il dispose de l'autorisation locale de le faire.

4.3.3 Message DHCPDECLINE

Si un serveur reçoit un message DHCPDECLINE, le client a découvert par d'autres moyens que l'adresse réseau suggérée est déjà utilisée. Le serveur DOIT marquer l'adresse réseau comme étant indisponible et DEVRAIT informer l'administrateur du réseau local d'un éventuel problème de configuration.

4.3.4 Message DHCPRELEASE

Quand il reçoit un message DHCPRELEASE, le serveur marque l'adresse réseau comme non allouée. Le serveur DEVRAIT avoir un enregistrement des paramètres d'initialisation du client pour une réutilisation ultérieure de l'adresse par ce même client.

4.3.5 Message DHCPINFORM

Le serveur répond à un message DHCPINFORM en envoyant un message DHCPACK directement à l'adresse donnée dans le champ 'ciaddr' du message DHCPINFORM. Le serveur NE DOIT PAS envoyer un temps d'expiration du bail au client et NE DEVRAIT PAS remplir le champ 'yiaddr'. Le serveur inclut d'autres paramètres, comme défini dans la section 4.3.1.

4.3.6 Les messages clients

Le tableau 4 détaille les différences entre les messages des clients selon les différents états.

 	
INIT-REBOOT

SELECTION

RENOUVELLEMENT

REAFFECTATION

diff./adressé

diffusé

diffusé

adressé

diffusé

IP serveur

DOIT PAS

DOIT

DOIT PAS

DOIT PAS

IP demandée

DOIT

DOIT

DOIT PAS

DOIT PAS

ciaddr

zéro

zéro

adresse IP

adresse IP

Table 4: Les messages clients selon les différents états.

4.4 Les comportement des clients DHCP

Le figure 5 donne un diagramme d'état des transitions pour un client DHCP. Un client peut recevoir les messages suivants d'un serveur :

o DHCPOFFER

o DHCPACK

o DHCPNAK

Le message DHCPINFORM n'est pas montré dans la figure 5. Un client envoie simplement un DHCPINFORM et attend les messages DHCPACK. Une fois que le client a sélectionné ses paramètres, il a accompli le processus de configuration.

Le tableau 5 donne l'utilisation, par un client, des champs et les options dans un message DHCP. Le reste de la section décrit l'action d'un client DHCP pour chaque message entrant. Dans la section suivante la description correspond à la configuration complète décrite précédemment dans la section 3.1 et le texte correspond à un résumé de la procédure de configuration vue dans la section 3.2.

--------                               -------                         |        | +-------------------------->|       |<-------------------+   | INIT-  | |     +-------------------->| INIT  |                    |   | REBOOT |DHCPNAK/         +---------->|       |<---+               |   |        |Redém. |         |            -------     |               |    --------  |  DHCPNAK/     |               |                        |       |      Rejet offre     |      -/envoi DHCPDISCOVER              |   -/envoi DHCPREQUEST        |               |                        |       |      |     |      DHCPACK            v        |               |    -----------     |   (non accepté)/   -----------   |               |   |           |    | envoi DHCPDECLINE |           |                  |   |REDEMARRAGE|    |         |         | SELECTION |<----+            |   |           |    |        /          |           |     |DHCPOFFER/  |    -----------     |       /            -----------   |  |Collecte    |       |            |      /                  |   |       |  réponses  |   DHCPACK/         |     /  +----------------+   +-------+            |   enregistre bail, |    |   v  Select. offre/                         |   tempos T1, T2   ------------ envoi DHCPREQUEST      |               |       |   +----->|            |             DHCPNAK, bail expiré/     |       |   |      |  REQUETE   |                 Arrêt réseau          |       DHCPOFFER/ |            |                       |               |       Rejet       ------------                        |               |       |   |        |        |                   -------------         |       |   +--------+     DHCPACK/              |             |        |       |              enregistre bail,     -----|REAFFECTATION|        |       |                tempos T1, T2     /     |             |        |       |                     |        DHCPACK/   -------------         |       |                     v     enregistre bail,    ^               |       +-------------> -----------      /tempos T1,T2  |               |               +----->|           |<---+               |               |               |      |  AFFECTÉ  |<---+               |               |   DHCPOFFER, DHCPACK,|           |    |           T2 expire/    DHCPNAK/   DHCPNAK/Rejet      -----------     |            Diffusion  Arrêt réseau             |       |   |           |           DHCPREQUEST         |               +-------+   |         DHCPACK/          |               |                      T1 expire/     enregistre bail,  |               |                 envoi DHCPREQUEST   tempos T1, T2     |               |               pour location serveur   |               |               |                          |     --------------         |               |                          |    |              |--------+               |                          +--->|RENOUVELLEMENT|                        |                               |              |------------------------+                                --------------                                      

Figure 5: Diagramme des états de transition pour les clients DHCP

4.4.1 Initialisation et allocation des adresses réseau

Le client commence par un état INIT et formule un message DHCPDISCOVER. Le client DEVRAIT attendre une durée aléatoire comprise entre 1 et 10 secondes pour désynchroniser l'utilisation du DHCP au lancement. Le client règle 'ciaddr' sur 0x00000000. Le client PEUT faire une demande de paramètres spécifiques en incluant l'option 'liste des paramètres demandés'. Le client PEUT suggérer une adresse réseau et/ou un bail en incluant les options 'adresse IP demandée' et 'durée du bail adresse IP '. Le client DOIT inclure l'adresse réseau matérielle dans le champs 'chaddr' si elle est nécessaire pour la livraison des réponses au message DHCP. Le client PEUT inclure un identifiant unique différent dans le 'identifiant client' comme vu dans la section 4.2. Si le client inclut une liste de paramètres requis dans le message DHCPDISCOVER il DOIT inclure ce tte liste dans tout les messages suivants.

Le client génère et enregistre un identifiant de transaction aléatoire et insère cet identifiant dans le champ 'xid'. Le client enregistre sa propre heure locale pour calculer l'expiration de son bail. Le client diffuse ensuite le DHCPDISCOVER sur l'adresse de diffusion matérielle, sur l'adresse IP de diffusion 0xfffffff et sur le port UDP du serveur DHCP.

Si le 'xid' d'un message DHCPOFFER entrant ne correspond pas au 'xid' du plus récent message DHCPDISCOVER reçu, le DHCPOFFER doit être rejeté sans notification. Tout message DHCPACK entrant doit être rejeté sans notification.

Le client collecte les messages DHCPOFFER sur une période de temps, choisit un message DHCPOFFER parmi les (potentiellement nombreux) messages DHCPOFFER entrants (par ex : le premier DHCPOFFER arrivant ou celui du serveur précédemment utilisé) et extrait l'adresse du serveur de l'option 'identifiant serveur' du message DHCPOFFER. Le temps pendant lequel le client collecte les messages et le mécanisme utilisé pour choisir un DHCPOFFER dépendent des implantations.

Champ

DHCPDISCOVER DHCPINFORM

DHCPREQUEST

DHCPDECLINE, DHCPRELEASE

'op'

BOOTREQUEST

BOOTREQUEST

BOOTREQUEST

'htype'

(Du RFC "Assigned Numbers")

'hlen'

(longueur de l'Adresse matérielle en octets)

'hops'

0

0

0

'xid'

choisi par le client

'xid' du message DHCPOFFER serveur

choisi par le client

'secs'

0 ou nb secondes depuis départ processus DHCP

0 ou nb secondes depuis départ processus DHCP

0

'flags'

drapeau 'BROADCAST' levé si le client demande une réponse diffusée

drapeau 'BROADCAST' levé si le client demande une réponse diffusée

0

'ciaddr'

0 (DHCPDISCOVER) adresse réseau du client(DHCPINFORM)

0 ou adresse réseau du client(BOUND/RENEW/REBIND)

0 (DHCPDECLINE) adresse réseau du client(DHCPRELEASE)

'yiaddr'

0

0

0

'siaddr'

0

0

0

'giaddr'

0

0

0

'chaddr'

adresse matérielle du client

adresse matérielle du client

adresse matérielle du client

'sname'

options, si indiqué dans option 'sname/fichier' sinon inutilisé

options, si indiqué dans option 'sname/fichier' sinon inutilisé

(inutilisé)

'fichier'

options, si indiqué dans option 'sname/fichier' sinon inutilisé

options, si indiqué dans option 'sname/fichier' sinon inutilisé

(inutilisé)

'options'

options

options

(inutilisé)

Option

DHCPDISCOVER DHCPINFORM

DHCPREQUEST

DHCPDECLINE, DHCPRELEASE

adresse IP demandée

PEUT (DISCOVER) NE DOIT PAS (INFORM)

DOIT (dans SELECTION ou INIT-REBOOT)

NE DOIT PAS (dans AFFECTATION ou RENOUVELLEMENT)

DOIT (DHCPDECLINE)

NE DOIT PAS (DHCPRELEASE)

Durée du bail IP

PEUT (DISCOVER) NE DOIT PAS (INFORM)

PEUT

NE DOIT PAS

Utilisation des champs 'fichier'/'sname'

PEUT DHCPDISCOVER/ DHCPINFORM

PEUT

DHCPREQUEST

PEUT DHCPDECLINE/ DHCPRELEASE

Identifiant client

PEUT

PEUT

PEUT

Identifiant classe fournisseur

PEUT

PEUT

NE DOIT PAS

Identifiant serveur

NE DOIT PAS

DOIT (après SELECTION) NE DOIT PAS (après INIT-REBOOT, AFFECTÉ, RENOUVELLEMENT ou REAFFECTATION)

DOIT

Liste des Paramètres requis

PEUT

PEUT

NE DOIT PAS

Taille maximum des messages

PEUT

PEUT

NE DOIT PAS

Message

NE DEVRAIT PAS

NE DEVRAIT PAS

DEVRAIT

Site spécifique

PEUT

PEUT

NE DOIT PAS

Autres

PEUT

PEUT

NE DOIT PAS


Table 5: Champs et options utilisés par les clients DHCP

 

Si les paramètres sont valides, le client enregistre l'adresse du serveur qui fournit les paramètres à partir du champ 'identifiant serveur' et envoie cette adresse dans le champ 'identifiant serveur' d'un message diffusé DHCPREQUEST. Une fois le message DHCPACK d'un serveur reçu, le client est initialisé et se met en AFFECTÉ. Le message DHCPREQUEST contient le même 'xid' que le DHCPOFFER. Le client enregistre le délai d'expiration du bail comme étant la somme des temps auxquels les requêtes originales ont été envoyées et la durée du bail d'un message DHCPACK. Le client DEVRAIT faire une vérification sur l'adresse suggérée pour s'assurer que l'adresse n'est pas déjà prise. Par exemple, si le client est sur un réseau supportant l'ARP, le client émet une requête ARP pour la valeur suggérée. Quant on diffus e une requête ARP pour l'adresse suggérée, le client doit mettre sa propre adresse matérielle comme adresse matérielle de l'envoyeur, et 0 pour l'adresse IP de l'envoyeur, pour éviter la confusion entre les différents caches ARP d'autres machines d'un même sous-réseau. Si l'adresse réseau semble être utilisée, le client DOIT envoyer un DHCPDECLINE au serveur. Le client DEVRAIT diffuser une réponse ARP pour annoncer la nouvelle adresse IP du client et vider toutes les entrées du cache ARP périmées sur les machines de son réseau.

4.4.2 Initialisation avec une adresse réseau connue

Le client commence par un état INIT-REBOOT et envoie un message DHCPREQUEST. Le client DOIT mettre sa propre adresse réseau pour l'option 'adresse IP demandée' dans le message DHCPREQUEST. Le client peut spécifier des paramètres de configurations en incluant l'option 'liste paramètres demandés'. Le client génère et enregistre un identifiant de transaction aléatoire et insère cet identifiant dans le champ 'xid'. Le client enregistre sa propre heure locale pour le calcul de l'expiration de son bail. Le client NE DOIT PAS inclure un 'identifiant serveur' dans le message DHCPREQUEST. Le client diffuse le DHCPREQUEST sur son adresse de diffusion sur le réseau local et sur le port UDP 'serveur DHCP'.

Une fois que le champ 'xid' lie le message DHCPREQUEST du client au serveur dans le message DHCPACK, le client est initialisé et passe en état AFFECTÉ. Le client enregistre l'expiration du bail comme étant la somme du temps auquel le message DHCPREQUEST a été envoyé et la durée du bail du message DHCPACK.

4.4.3 Initialisation avec une adresse réseau assignée de manière externe.

Le client envoie un message DHCPINFORM. Le client peut faire la requête de paramètres de configuration spécifiques en incluant l'option 'liste paramètres demandés'. Le client génère et enregistre un identifiant de transaction aléatoire et insère cet identifiant dans le 'xid'. Le client place sa propre adresse réseau dans le champ 'ciaddr'. Le client NE DOIT PAS faire de demande de durée du bail.

Le client adresse alors le message DHCPINFORM au serveur DHCP s'il connaît l'adresse serveur, autrement il diffuse le message aux adresses de diffusion. DHCPINFORM DOIT être dirigé vers le port UDP 'serveur DHCP'.

Une fois le message DHCPACK avec un champ 'xid' vérifiant que le message DHCPINFORM du client vient bien du serveur, le client est alors initialisé.

Si le client ne reçoit pas un DHCPACK dans un délai raisonnable (60 secondes ou 4 essais si on utilise la période définie dans la section 4.1), alors il DEVRAIT afficher un message informant l'utilisateur du problème, et DEVRAIT commencer un processus réseau en utilisant des valeurs par défaut correctes (Annexe A).

4.4.4 Utilisation de la diffusion et de l'adressage unique

Le client DHCP diffuse les message DHCPDISCOVER, DHCPERQUEST et DHCPINFORM, à moins que le client ne connaisse l'adresse du serveur DHCP. Le client adresse les messages DHCPRELEASE au serveur. Parce que le client décline l'utilisation de l'adresse IP fournie par le serveur, le client diffuse les messages DHCPDECLINE.

Quand le client DHCP connaît l'adresse d'un serveur DHCP, soit dans un état INIT ou REBOOT, le client peut utiliser cette adresse dans le DHPDISCOVER ou DHCPREQUEST plutôt que l'adresse IP de diffusion. Le client peut aussi utiliser l'adressage pour envoyer des messages DHCPINFORM à un serveur DHCP connu. Si le client ne reçoit aucune réponse aux messages DHCP envoyés à l'adresse IP d'un serveur DHCP connu, le client DHCP se remet à utiliser l'adresse IP de diffusion.

4.4.5 Réacquisition et expiration.

Le client enregistre deux valeurs temporelles, T1 et T2 qui spécifient les durées au bout desquelles le client essaie d'étendre son bail sur son adresse réseau. T1 est le temps au bout duquel le client entre en état RENOUVELLEMENT et tente de contacter le serveur qui a émis l'adresse réseau du client. T2 est le temps au bout duquel le client entre en état REAFFECTATION et tente de contacter un serveur. T1 DOIT expirer avant T2, qui à son tour DOIT arriver à terme avant le moment auquel expire le bail.

Pour éviter le besoin d'horloge synchronisée, T1 et T2 sont exprimés dans les options comme temps relatifs [2].

Au temps T1 le client passe en RENOUVELLEMENT et envoie (par message adressé) un message DHCPREQUEST au serveur pour étendre son bail. Le client met 'ciaddr' dans le DHCPREQUEST avec sa propre adresse réseau. Le client enregistre l'heure locale à laquelle le DHCPREQUEST à été envoyé pour calculer la durée du bail. Le client NE DOIT PAS inclure un 'identifiant serveur' dans le message DHCPREQUEST.

Tout message DHCPACK qui arrive avec un 'xid' qui ne correspond pas avec le 'xid' du DHCPREQUEST client est rejeté sans notification. Quand le client reçoit un DHCPACK du serveur, le client calcule la duré du bail en faisant la somme du temps après lequel le client doit envoyer le message DHCPREQUEST et la durée du bail obtenu dans le message DHCPACK. Le client a fait de nouveau l'acquisition de son adresse réseau, et retourne en état AFFECTÉ et peut continuer son processus réseau.

Si aucun DHCPACK n'arrive avant T2, le client passe en REAFFECTATION et envoie (via diffusion) un message DHCPREQUEST pour étendre son bail. Le client règle le champ 'ciaddr' du DHCPREQUEST avec sa propre adresse réseau. Le client NE DOIT PAS inclure de 'identifiant serveur' dans le message DHCP. T1 et T2 sont configurables par le serveur via les options. La valeur par défaut de T1 est (0.5*durée_du_bail) et celle de T2 = (0.875*durée_du_bail). Les valeurs de T1 et T2 DEVRAIENT être choisies dans une plage englobant la valeur par défaut, avec un léger delta aléatoire, pour éviter la synchronisation de la réacquisition du client.

Un client PEUT choisir de renouveler ou étendre son bail sur T1. Le serveur PEUT choisir d'attendre le bail en accord avec la stratégie de l'administrateur réseau. Le serveur DEVRAIT retourner T1 et T2 et leurs valeurs DEVRAIENT être ajustées à partir de leurs valeurs d'origine pour prendre en compte le temps de bail restant.

Que ce soit en RENOUVELLEMENT ou en REAFFECTATION si le client ne reçoit pas de réponse à son message DHCPREQUEST, le client DEVRAIT attendre la moitié du temps restant avant T2 (pour RENOUVELLEMENT) et la moitié du temps de bail restant (pour REAFFECTATION), jusqu'à un minimum de 60 secondes, avant de retransmettre le message DHCPREQUEST.

Si le bail expire avant que le client ne reçoive un DHCPACK, le client passe en état INIT, il DOIT alors immédiatement stopper tout processus réseau et nécessite une initialisation des paramètres réseau comme si le client n'était pas initialisé. Si le client reçoit alors un DHCPACK allouant l'adresse réseau qu'il possédait précédemment, il DEVRAIT continuer son processus réseau. Si le client obtient une nouvelle adresse réseau, il NE DOIT PAS continuer à utiliser l'adresse préalable et DEVRAIT avertir l'utilisateur local du problème.

4.4.6 DHCPRELEASE

Si le client n'a plus besoin de son adresse réseau (par ex : le client est arrêté normalement) il envoie un DHCPRELEASE au serveur. Notez que le fonctionnement correct du DHCP ne dépend pas de la transmission correcte des messages DHCPRELEASE.

 

5. Remerciements

L'auteur remercie tous les membres (trop nombreux pour être mentionnés) du groupe de travail 'DHC WG' pour leurs efforts inlassables et continus dans le développement du DHCP et de ce document.

Les efforts de J. Allard, Mike Carney, Dave Lapp, Fred Lien et John Mendonca dans les sessions de tests pour l'interopérabilité du DHCP sont particulièrement reconnus.

Le développement de ce document fut en partie soutenu par des subventions du CNRI (Corporation for National Research Initiatives), de l'université Bucknell et par Sun Microsystems.

 

6. Références

[1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December 1983.

[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 1533, Lachman Technology, Inc., Bucknell University, October 1993.

[3] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989.

[4] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support, STD 3, RFC 1123, USC/Information Sciences Institute, October 1989.

[5] Brownell, D, "Dynamic Reverse Address Resolution Protocol (DRARP)", Work in Progress.

[6] Comer, D., and R. Droms, "Uniform Access to Internet Directory Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer Communications Review), 20(4):50--59, 1990.

[7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford and SUN Microsystems, September 1985.

[8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991.

[9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534, Bucknell University, October 1993.

[10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", RFC 903, Stanford, June 1984.

[11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency", In Proc. of the Twelfth ACM Symposium on Operating Systems Design, 1989.

[12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.

[13] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

[14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.

[15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached Hosts", Work in Progress.

[16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981.

[17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, USC/Information Sciences Institute, August 1993.

[18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

[19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic Assignment of IP Addresses for use on an Ethernet. (Available from the Athena Project, MIT), 1989.

[20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, June 1981.

[21] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, Carnegie Mellon University, October 1993.

 

7. Considérations concernant la sécurité

DHCP est construit directement sur UDP et IP, ce qui est peu sécurisé. De plus DHCP est généralement fait pour rendre plus aisée la maintenance de machines distantes ou sans disques. Tout en n'étant pas impossible, configurer de telles machines avec des mots de passe ou des clefs peut être difficile voire gênant. De plus, DHCP dans sa forme actuelle est assez peu sécurisé.

Des serveurs DHCP non autorisés peuvent facilement être montés. De tels serveurs peuvent envoyer de fausses informations aux clients comme une fausse adresse IP, des informations de routage incorrectes (routeurs usurpés...), des serveurs de nom de domaines incorrects... De manière évidente, une fois ce type de serveurs mis en place, un attaquant peut compromettre plus gravement les systèmes induits en erreur.

Des clients DHCP malintentionnés peuvent se faire passer pour des clients légitimes et récupérer les informations destinées à ces clients légitimes. Là où l'allocation dynamique de ressources est utilisée, un client malintentionné peut demander toute les ressources pour lui, et ainsi interdire l'accès aux ressources aux clients légitimes.

 

8. Adresse de l'auteur

Ralph Droms
Computer Science Department
323 Dana Engineering 
Bucknell University 
Lewisburg, PA 17837 
Phone: (717) 524-1145 
EMail: droms@bucknell.edu 
EMail: droms@bucknell.edu

A. Paramètres de Configuration machine

IP-layer_parameters,_per_host:    Be a router                     on/off                 HRC 3.1    Non-local source routing        on/off                 HRC 3.3.5    Policy filters for    non-local source routing        (list)                 HRC 3.3.5    Maximum reassembly size         integer                HRC 3.3.2    Default TTL                     integer                HRC 3.2.1.7    PMTU aging timeout              integer                MTU 6.6    MTU plateau table               (list)                 MTU 7 IP-layer_parameters,_per_interface:    IP address                      (address)              HRC 3.3.1.6    Subnet mask                     (address mask)         HRC 3.3.1.6    MTU                             integer                HRC 3.3.3    All-subnets-MTU                 on/off                 HRC 3.3.3    Broadcast address flavor        0x00000000/0xffffffff  HRC 3.3.6    Perform mask discovery          on/off                 HRC 3.2.2.9    Be a mask supplier              on/off                 HRC 3.2.2.9    Perform router discovery        on/off                 RD 5.1    Router solicitation address     (address)              RD 5.1    Default routers, list of:            router address          (address)              HRC 3.3.1.6            preference level        integer                HRC 3.3.1.6    Static routes, list of:            destination             (host/subnet/net)      HRC 3.3.1.2            destination mask        (address mask)         HRC 3.3.1.2            type-of-service         integer                HRC 3.3.1.2            first-hop router        (address)              HRC 3.3.1.2            ignore redirects        on/off                 HRC 3.3.1.2            PMTU                    integer                MTU 6.6            perform PMTU discovery  on/off                 MTU 6.6 Link-layer_parameters,_per_interface:    Trailers                       on/off                 HRC 2.3.1    ARP cache timeout              integer                HRC 2.3.2.1    Ethernet encapsulation         (RFC 894/RFC 1042)     HRC 2.3.3 TCP_parameters,_per_host:    TTL                            integer                HRC 4.2.2.19    Keep-alive interval            integer                HRC 4.2.3.6    Keep-alive data size           0/1                    HRC 4.2.3.6 Key:    MTU = Path MTU Discovery (RFC 1191, Proposed Standard)    RD = Router Discovery (RFC 1256, Proposed Standard)