DHCP
Introduction
DHCP et Bootp sont des protocoles permettant de configurer automatiquement l'environnement IP des équipements réseau : adresse IP, masque de réseau, routeur par défaut, adresse de serveurs DNS, etc….
Ces dispositifs permettent de s'affranchir des reconfigurations manuelles des postes, suite à des déménagements ou des modifications d'architecture.
Bootp
Le protocole Bootp est défini par les RFCs :
· RFC951 Bootpstrap Protocol
· RFC1542 Clarifications and Extensions for Bootp
Le mécanisme est le suivant :
1. Le client émet par broadcast une trame de requête Bootp, contenant son adresse MAC.
2. Le serveur Bootp du réseau reçoit ce broadcast ; si l'adresse MAC du PC est présente dans sa table Bootp, il envoie alors une réponse Bootp, contenant les paramètres de configuration IP du client (adresse IP, masque de réseau, routeur par défaut, serveur DNS, etc….).
3. Le client reçoit la trame et configure son stack TCP/IP.
4. Le client adresse ensuite au serveur Bootp (ou à un autre serveur si cela a été spécifié dans la réponse Bootp) une requête de transfert tftp afin d'obtenir un fichier de configuration.
5. Une fois que le client a obtenu les détails de sa configuration, il peut optionnellement émettre une requête de transfert tftp d'image système (si cela a été spécifié dans le fichier de configuration reçu).
La durée de bail d'une adresse IP n'est pas configurable ; elle ne peut prendre qu'une valeur infinie.
D'après ce mécanisme, le serveur Bootp doit avoir connaissance de l'adresse MAC du client Bootp pour être autorisé à lui répondre, et disposer des paramètres IP qui lui sont associés.
Une table faisant correspondre pour chaque client Bootp son adresse MAC et les paramètres IP associés doit donc être manuellement renseignée pour chaque équipement. Ce mécanisme pose le problème d'une administration difficile.
Le protocole Bootp est basé sur IP/UDP. Un protocole plus ancien, RARP avait été défini pour permettre à un client d'obtenir une adresse IP à partir de son adresse MAC. Mais s'appuyant sur le protocole de liaison de données, RARP nécessite sur le poste client des modifications du noyau ou des pilotes de la carte réseau ,pour permettre son interprétation.
DHCP
DHCP, Dynamic Host Configuration Protocol, est un protocole client/serveur défini par les RFCs :
· RFC2131 Dynamic Host Configuration Protocol
· RFC2132 DHCP Options and Bootp Vendor Extensions
DHCP est basé sur le protocole Bootp, l'enrichissant de nouvelles fonctionnalités, comme l'allocation dynamique d'adresses IP : il n'est plus utile de renseigner manuellement une table de correspondance adresse MAC / adresse IP. Une adresse IP peut être attribuée à partir d'un pool d'adresses IP disponibles.
Le format de la trame DHCP est le suivant :
0 8 16 24 31
| Type du message (op)1 | Type de l'adresse MAC (htype)2 | Longueur de l'adresse MAC (hlen) | (hops) |
| Identifiant de la transaction choisi aléatoirement (xid)3 | |||
| Temps écoulé depuis le début de la transaction (secs) | (flags)4 | ||
| Adresse IP du client renseignée uniquement en cas de statut Bound, Renew, Rebinding (ciaddr) | |||
| Adresse IP du client renvoyée par le serveur DHCP ('your IP address') (yiaddr) | |||
| Adresse IP du serveur à utiliser dans la prochaine étape du processus Bootp (siaddr)5 | |||
| Adresse IP de l'agent de relais DHCP (giaddr) | |||
| Adresse MAC du client (16 octets) (chaddr) | |||
| Adresse optionnelle d'un serveur (64 octets) (sname) | |||
| Nom du fichier de boot renseigné dans les DHCP Offer (128 octets) (file) | |||
| Paramètres complémentaires définis à partir d'une liste déterminée d'options (options)6 | |||
| (op)1 : | Type du message. | |||
| | 1 = BootRequest | (trame DHCP émise par le client à destination du serveur) | ||
| | 2 = BootReply | (trame DHCP émise par le serveur à destination du client) | ||
| | | |||
| (htype)2 : | Type de l'adresse MAC | |||
| | Exemple : | 1 = Ethernet 10Mb/s | ||
| | | |||
| (xid)3 : | Identifiant de la transaction choisi aléatoirement. | |||
| | Utilisé pour associer les requêtes d'un client et les réponses d'un serveur à une même transaction DHCP, il est choisi par le client DHCP et doit être unique sur le réseau local. | |||
| | | |||
| (flags)4: | Le bit positionné le plus à gauche de ce champ est appelé le "Flag de Broadcast". | |||
| | | |||
| (siaddr)5 : | Adresse IP du serveur à utiliser dans la prochaine étape du processus Bootp. | |||
| | Ce champ est renseigné dans les messages DHCP Offer et DHCP Ack. | |||
| | | |||
| (options)6 : | Exemple d'option : | |||
| | 'Type' | · Type du message DHCP, champ impérativement renseigné dans toute trame DHCP. | ||
| | | · L'option type 1 correspond à un message DHCP Discover. | ||
| | 'Server Identifier' | · Identifiant du serveur DHCP | ||
| | 'Requested IP Address' | · Adresse IP souhaitée par le client DHCP | ||
| | 'IP Address Lease Time' | · Durée de bail de l'adresse IP | ||
| | 'Parameter Request List' | · Liste des paramètres IP attendus par le client | ||
Ce format de trame correspond à celui de la trame Bootp à quelques différences près :
· Le champ 'vendor extensions' est renommé 'options' ; il est désormais de longueur variable (de 64 octets dans la trame Bootp). Les clients DHCP peuvent négocier une taille maximale de trames DHCP échangées en positionnannt le champ option 'Maximum DHCP Message Size'.
· Les deux octets qui suivent le champ 'secs' ne sont pas utilisés par la trame Bootp. La norme DHCP nomme ce champ 'flags', et attribue un rôle au bit positionné le plus à gauche du champ (le "Flag de Broadcast").
· Flag de broadcast
Certains clients DHCP ne sont pas capables de recevoir des datagrammes unicast avant que leur stack TC/IP ne soit configuré.
Dans ce cas, le client DHCP positionne à 1 le "Flag de Broadcast" (le bit le plus à gauche du champ 'flags') sur toute trame DHCP qu'il émet. Un serveur DHCP recevant une telle trame répond alors systématiquement par broadcast.
Si le "Flag de Broadcast" n'est pas positionné, les réponses des serveurs peuvent être émises sous forme d'unicast, l'adresse MAC destinatrice étant celle du champ 'chaddr' lu dans la trame cliente et l'adresse IP destinatrice étant celle offerte par le serveur.
Relais BootP (Bootp Relay)
Les communications DHCP sont basées sur des flux IP broadcastés. Un serveur DHCP ne recoit donc pas les requêtes DHCP des clients qui n'appartiennent pas à son domaine de diffusion.
Le mécanisme de relais Bootp permet à un client DHCP de passer outre cette limitation.
Lorsqu'un agent de relais Bootp reçoit une trame de broadcast DHCP, il la transmet aux serveurs DHCP appartenant à d'autres réseaux (par unicast ou par broadcast), en renseignant le champ 'giaddr' avec sa propre adresse IP. IL incrémente également le champ 'hops'. Une limite peut être fixée pour la valeur de ce champ afin de contrôler le nombre de retransmissions d'une même trame : au delà de cette limite, l'agent de relais supprime la trame.
Un serveur DHCP, qui reçoit une trame DHCP dont le champ 'giaddr' n'est pas à zéro, sait que la trame provient d'un client DHCP qui n'est pas joignable par broadcast. Il adresse alors sa réponse par unicast à l'agent de relais. L'agent de relais transmet la trame au client DHCP par broadcast ou par unicast en fonction du positionnement du "Flag de Broadcast".
Négociation DHCP
Le mécanisme DHCP définit les étapes de négociation suivantes :
1. Le client DHCP émet, par broadcast sur le réseau local, une trame de découverte DHCP, "DHCP Discovery", qui permet de :
· découvrir les serveurs DHCP du réseau,
· et demander l'obtention d'une configuration IP.
Le tableau suivant présente les adresses des en-têtes IP de la trame DHCP Discovery :
| Protocole | Adresse Source | Adresse Destination |
| MAC | Adresse MAC du client DHCP | FF FF FF FF |
| IP | 255.255.255.255 | 0.0.0.0 |
Le client renseigne le champ 'chaddr' de la trame DHCP par son adresse MAC, afin que les serveurs aient connaissance de son adresse MAC, même si la trame a été transmise par un agent de relais Bootp.
Le client peut éventuellement :
· spécifier une liste de paramètres attendus pour sa configuration, en renseignant le champ option 'Parameter Request List' dans sa trame de découverte,
· suggérer des valeurs pour l'adresse réseau en renseignant le champ option 'Requested IP Address', ou une durée de bail, dans le champ option 'IP Address Lease Time'.
2. Un serveur DHCP reçoit ce broadcast.
S'il est capable de satisfaire la demande, il répond en émettant une trame "DHCP Offer", incluant les paramètres requis par le client DHCP, et les valeurs qu'il lui a éventuellement suggérées (par broadcast ou unicast en fonction du positionnement du "Flag Broadcast" et de l'intervention d'un agent de relais).
Le serveur indique l'adresse IP qu'il propose au client en renseignant le champ 'yiaddr' de sa trame d'offre, et remplit à l'identique le champ option 'Requested IP Address'.
Un serveur DHCP renseigne le champ option 'Server Identifier' de toute trame DHCP qu'il émet.
La norme suggère au serveur DHCP :
· d'être capable de vérifier que l'adresse IP proposée n'est pas déjà utilisée sur le réseau (par des échos ICMP par exemple) — cette vérification, toutefois, ne doit pas avoir lieu en cas de renouvellement de bail,
· de laisser le choix à l'administrateur d'activer ou non cette vérification,
· et d'enregistrer un "Binding" pour cette offre, afin de ne pas proposer la même adresse à plusieurs clients.
La norme recommande de respecter la stratégie suivante pour l'attribution d'une adresse IP :
a. S'il existe déjà un "Binding" pour ce client, et qu'il est en cours de validité, le serveur attribue la même adresse IP que celle mentionnée dans le "Binding".
b. S'il existe déjà un "Binding", mais qu'il n'est plus valide (le bail a expiré, ou il a été préalablement libéré par le client), le serveur attribue la même adresse IP que celle mentionnée dans le "Binding", à condition que celle-ci soit encore valide et qu'elle n'ait pas été réattribuée.
c. Si le client a suggéré une adresse IP dans le champ option 'Requested Ip Address', le serveur lui attribue la même adresse, si celle-ci est toujours valide et qu'elle n'a pas été déjà attribuée.
d. Le serveur attribue une adresse IP choisie à partir d'un pool d'adresse renseigné administrativement.
La norme recommande également de baser l'adresse IP sur le réseau IP d'où provient le message "DHCP Discovery" :
· l'adresse réseau du serveur DHCP si le client est sur le même réseau physique,
· ou l'adresse réseau de l'agent de relais Bootp si le champ 'giaddr' de la trame de découverte DHCP n'est pas à zéro.
Cette stratégie d'attribution d'adresse IP n'est qu'une recommandation. Il n'est pas du ressort de la norme de fixer le choix.
Un serveur DHCP doit être en mesure d'attribuer une adresse IP différente de celle réclamée par le client, peut décider de ne pas attribuer d'adresse IP, même s'il reste des adresses libres, et ce pour des raisons administratives.
3. Le client reçoit l'offre, et peut décider d'accepter ou d'attendre éventuellement d'autres propositions de serveurs DHCP.
Il signifie son accord au serveur DHCP dont il retient l'offre, par une trame de broadcast "DHCP Request" dont :
· le champ option 'Server Identifier' est renseigné par l'identifiant du serveur DHCP sélectionné,
· et le champ 'ciaddr' est renseigné par le contenu du champ 'yiaddr' lu dans la trame d'offre DHCP.
La trame reprend les paramètres de l'offre, ou peut les modifier pour suggérer de nouvelles valeurs, (en renseignant les champs options adéquats).
Si le client ne reçoit aucune offre acceptable, il peut décider de renouveler le processus de configuration en émettant une nouvelle trame de découverte.
4. Les serveurs reçoivent le broadcast.
Ceux qui ne reconnaissent pas leur identifiant dans la trame de broadcast sont, par là même, notifiés du refus de leur offre.
Si le serveur sélectionné par le client DHCP est capable de satisfaire les options souhaitées, il acquitte la demande en émettant une trame "DHCP Ack", par broadcast ou unicast en fonction du positionnement du "Flag Broadcast" et de l'intervention d'un agent de relais ; il lui confirme l'adresse IP et les paramètres associés, et enregistre le "Binding" dans sa base d'information.
Si le serveur DHCP n'est pas capable de satisfaire la demande du client, il renvoie un acquittement négatif par un broadcast "DHCP Nack". La norme recommande alors au serveur d'être capable d'émettre un message informant l'administrateur du problème.
Si le client DHCP n'a pas sélectionné d'offre, les serveurs DHCP ne sont notifiés ni du refus de leur offre, ni de son acceptation. La norme recommande alors aux serveurs de conserver le "Binding" jusqu'à expiration d'un time-out, et de le libérer au delà.
Le PC reçoit le message d'acquittement.
La norme suggère au client DHCP de vérifier que l'adresse proposée n'est pas utilisée par le réseau (par une requête ARP par exemple).
Si elle ne l'est pas, le client, à ce stade, a achevé sa configuration. La norme recommande ensuite au client d'émettre une trame de réponse ARP afin de mettre à jour le cache des hosts du réseau.
Sinon, il décline l'offre du serveur DHCP par un unicast "DHCP Decline", et recommence le processus de configuration, après 10s de délais, durée recommandée par la norme. Le serveur DHCP qui reçoit cette trame doit alors enregistrer l'adresse IP comme non valide. La norme recommande au serveur d'être alors capable d'émettre un message informant l'administrateur du problème.
Si le client a reçu un message de non acquittement, il recommence le processus de configuration en émettant une nouvelle trame de découverte.
Si le client n'a pas reçu de message d'acquittement, ni de non acquittement, il reémet un broadcast de "DHCP Request".
Si le client DHCP n'obtient pas de réponse après un certain nombre de tentatives — nombre défini par un algorithme de retransmission qui, d'après une recommandation de la norme, ne doit pas durer plus d'une minute — il recommence le processus de configuration.
Le schéma ci-dessous illustre le mécanisme de configuration IP par DHCP, dans le cas où les serveurs et le client sont sur le même réseau local (même domaine de diffusion) :
Cas Particuliers
Libération d'adresse
Un client qui souhaite libérer son bail envoie au serveur DHCP un message "DHCP Release". Un tel message n'est pas envoyé lorsque le PC s'éteint.
Renouvellement de bail
Un client qui souhaite renouveler le bail de son adresse IP, envoie un message "DHCP Request", mais :
· sans renseigner le champ 'Server Identifier', ni le champ 'Requested IP Address',
· en précisant, dans le champ 'ciaddr', l'adresse IP qui lui a été préalablement attribuée.
Le message est envoyé par unicast au serveur qui a préalablement attribué l'adresse IP, et qui enverra en retour un unicast d'acquittement.
Le client qui a été configuré par DHCP a reçu, en argument du message DHCP Ack, deux timers T1 et T2.
T1 est le temps au bout duquel le client demande une extension de son bail : il émet une trame "DHCP Request" adressée au serveur qui lui a attribué son adresse IP (il passe de l'état BOUND à l'état RENEWING). Il renseigne le champ 'ciaddr' avec son adresse IP courante, mais laisse le champ option 'Server Identifier' à zéro.
Dès qu'il reçoit un message d'acquittement DHCP, le client retourne à l'état BOUND.
Si le client ne reçoit pas de message d'acquittement au bout de T2, il envoie une trame "DHCP Request" par broadcast à tous les serveurs. Il passe alors à l'état REBINDING.
Dès qu'il reçoit un message d'acquittement DHCP, il retourne à l'état BOUND.
Si le client DHCP ne reçoit pas de trame d'acquittement avant l'expiration de son bail (T1 < T2 < Durée de bail), il passe à l'état INIT et recommence le processus de configuration IP en émettant une trame de découverte DHCP.
Ces timers sont configurables par le serveurs, via des champs options des trames DHCP transmises au client. Par défaut :
T1 = 0,5 x (Durée de bail)
T2 = 0,875 x (Durée de bail)
Négociation DHCP excluant l'adresse IP
Lorsqu'un client DHCP a reçu une adresse IP par un moyen externe (configuration manuelle de l'administrateur), il émet une trame "DHCP Inform" pour obtenir le reste de sa configuration IP.
Il renseigne le champ 'ciaddr' par son adresse IP.
Les serveurs répondent au client par un unicast d'acquittement, adressé à l'adresse IP lue dans le champ 'ciaddr',
· sans allouer de nouvelle adresse,
· ni vérifier l'adresse annoncée dans les "Bindings",
· et sans inclure de durée de bail.
La norme recommande toutefois au serveur DHCP de vérifier que l'adresse annoncée par le client n'est pas déjà utilisée, et de laisser le champ 'yiaddr' à zéro dans la trame d'acquittement.
Reboot d'un client DHCP
Un client qui reboote, mais qui a gardé la connaissance de l'adresse IP qui lui a précédemment été attribuée par DHCP, émet une trame "DHCP Request" :
· en renseignant le champ 'Requested IP Adress'
· et en laissant à 0 le champ 'Server Identifier'.
Il passe ainsi de l'état INIT-REBOOT à l'état REBOOTING.
A réception d'une trame d'acquittement DHCP, il atteint le statut BOUND.
Diagramme d'état
Le diagramme suivant présente les différents états d'un client DHCP et les transitions possibles entre ces états.
Transport des messages DHCP
Les messages DHCP sont transportés par le protocole UDP. Les messages émis par un client vers un serveur DHCP (correspondant au type de trame DHCP 'BootRequest') utilisent le port 67. Les messages émis par les serveurs à destination des clients DHCP (correspondant au type de trame DHCP 'BootReply') utilisent le port 68.
Configuration administrative des serveurs DHCP
Les serveurs DHCP ne sont pas contraints de répondre à tous les messages de découverte ou de requêtes DHCP. Les spécifications de la norme ne portent que sur les interactions entre clients et serveurs lorsque ceux-ci ont choisi de communiquer. Les contrôles administratifs des autorisations de réponses sont du ressort de l'administrateur, qui peut, par exemple, configurer les serveurs DHCP pour ne répondre qu'à une liste prédéfinie de clients.
Les modes de configuration usuellement employés pour les serveurs DHCP sont les suivants :
· Bootp Manuel
Cette configuration correspond au support du protocole Bootpstrap : l'adresse MAC doit être connue, son association avec une adresse IP est manuelle et le bail est permanent.
· Bootp Automatique
Cette configuration permet à un PC d'obtenir par Bootp une adresse à partir d'un pool d'adresses IP dont le bail est permanent.
· DHCP Dynamique
Les adresses IP sont assignées par DHCP à partir d'un pool d'adresses IP, les durées de bail étant configurables.
· DHCP Manuel
Il s'agit de l'équivalent DHCP du Bootp Manuel. L'adresse MAC du PC doit être connue et assignée statiquement à une adresse IP ; le bail est permanent.
· DHCP Automatique
Il s'agit de l'équivalent DHCP du Bootp Automatique.
0 commentaires:
Enregistrer un commentaire