DHCP

1. Le service DHCP.
1.1. Introduction.

Le DHCP fournit des paramtres de configuration pour des machines Internet. DHCP est constitu de 2 parties :
Un protocole pour la livraison de paramtres de configuration de machines spcifiques partir d'un serveur
DHCP et un mcanisme dallocation dadresses rseaux des machines.

DHCP est bti sur le modle client - serveur, o la machine dsigne serveur DHCP alloue des adresses rseaux
et dlivre des paramtres de configuration des machines configures dynamiquement. Dun bout lautre de ce
document, le terme "serveur" se rfre une machine fournissant des paramtres d'initialisation au travers du
DHCP, et le terme "client" se rfre une machine qui demande des paramtres d'initialisation au serveur
DHCP.

Une machine ne devrait pas agir en tant que serveur DHCP moins que cela ne soit spcifi par l'administrateur
du systme. La diversit des implantations du matriel et des protocoles sur l'Internet conduirait un manque de
fiabilit au niveau des oprations si n'importe quelle machine tait autorise rpondre aux requtes DHCP. Par
exemple, IP ncessite le paramtrage de nombreux paramtres l'intrieur du logiciel qui implante le protocole.
Parce quIP peut tre utilis sur un grand nombre de matriels rseaux, les valeurs par dfaut de ces paramtres
ne peuvent tre devines ou prsupposes pour tre correctes. De mme, les schmas de distribution d'adresses
reposent sur un mcanisme dlection/dfense pour la dcouverte des adresses dj utilises. Les machines IP ne
peuvent pas toujours dfendre leurs adresses rseaux, ainsi un tel schma d'allocation d'adresse ne peut garantir
que les adresses alloues ne se dupliquent.

DHCP supporte 3 mcanismes pour l'allocation des adresses IP. L'allocation automatique : DHCP assigne une
adresse IP permanente un client. L'allocation dynamique : DHCP assigne une adresse IP un client pour une
dure dtermine (ou jusqu' ce que le client renonce son adresse). L'allocation manuelle, une adresse IP est
assigne par l'administrateur rseau, et DHCP est simplement utilis pour convoyer les adresses dsignes
jusqu'au client. Un rseau spcifique utilisera un ou plusieurs de ces mcanismes, cela dpend de la stratgie de
l'administrateur rseau.

L'allocation dynamique est la seule des 3 mcanismes qui rutilise automatiquement une adresse qui n'est plus
utilise par un client. De plus, l'allocation dynamique est particulirement utile pour assigner une adresse un
client qui se connectera au rseau de manire temporaire, ou pour partager une liste limite d'adresses IP entre un
groupe de clients qui ne ncessitent pas une adresse permanente. L'allocation dynamique est aussi un bon choix
pour assigner une adresse IP un nouveau client qui se connectera de manire permanente au rseau o les
adresses IP sont suffisamment rares pour qu'il soit important de les rcuprer quand les anciens clients sont hors
connexion. L'allocation manuelle permet DHCP d'tre utilis pour liminer les processus enclins lerreur de
configuration manuelle de machines avec une adresse IP dans des environnements o (pour diverses raisons) il
est prfrable de grer l'attribution des adresses IP en dehors des mcanismes de DHCP.

DHCP utilise le protocole de transport UDP. Les messages DHCP d'un client vers un serveur sont envoys 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 rseau (par ex : une machine multi-sites) peut utiliser n'importe laquelle
de ses adresses dans un message DHCP sortant.

Avantages de DHCP dans l'administration d'un rseau ?

1. Le protocole DHCP offre une configuration de rseau TCP/IP fiable et simple, empche les conflits
d'adresses et permet de contrler l'utilisation des adresses IP de faon centralise. Ainsi, si un paramtre
change au niveau du rseau, comme, par exemple l'adresse de la passerelle par dfaut, il suffit de
changer la valeur du paramtre au niveau du serveur DHCP, pour que toutes les stations aient une prise
en compte du nouveau paramtre ds que le bail sera renouvel. Dans le cas de l'adressage statique, il
faudrait manuellement reconfigurer toutes les machines.
2. Economie d'adresse : ce protocole est presque toujours utilis par les fournisseurs d'accs Internet qui
disposent d'un nombre d'adresses limit. Ainsi grce DHCP, seules les machines connectes en ligne
ont une adresse IP. En effet, imaginons un fournisseur d'accs qui a plus de 1000 clients. Il lui faudrait 5
rseaux de classe C, s'il voulait donner chaque client une adresse IP particulire. S'il se dit que chaque
client utilise en moyenne un temps de connexion de 10 mn par jour, il peut s'en sortir avec une seule
classe C, en attribuant, ce que l'on pourrait appeler des "jetons d'accs" en fonction des besoins des
clients.
3. Les postes itinrants sont plus faciles grer
4. Le changement de plan d'adressage se trouve facilit par le dynamisme d'attribution.

Avec DHCP, il suffit d'attribuer une adresse au serveur. Lorsqu'un ordinateur client DHCP demande l'accs au
rseau en TCP-IP, son adresse est alloue dynamiquement l'intrieur d'une plage d'adresses dfinie sur le
serveur.
L'administrateur de rseau contrle le mode d'attribution des adresses IP en spcifiant une dure de bail qui
indique combien de temps l'hte peut utiliser une configuration IP attribue, avant de devoir solliciter le
renouvellement du bail auprs du serveur DHCP.

L'inconvnient :

Le client utilise des trames de broadcast pour rechercher un serveur DHCP sur le rseau, cela charge le rseau. Si
vous avez une entreprise avec plusieurs centaines de personnes qui ouvrent leur session le matin 8 h ou l'aprs
midi 14 h, il peut s'en suivre de graves goulets d'tranglement sur le rseau. L'administrateur devra donc
rflchir srieusement l'organisation de son rseau.

1.2. Allocation d'une adresse rseau.

Nous aborderons dans ce paragraphe linteraction entre un client et un serveur DHCP dans le cas o le client na
pas encore reu un bail prcdent pour une adresse IP. Si le client connat dj son adresse, certaines tapes
peuvent tre omises, cette interaction rduite est dcrite dans la section suivante.

Octet1 Octet2 Octet3 Octet4
op(1) htype(1) hlen(1) hops(1)
xid(4)
secs(2) flags(2)
ciaddr(4)
yiaddr(4)
siaddr(4)
giaddr(4)
chaddr(4)
sname(16)
file(128)
options (dpend de la norme RFC 2132)

Format dun paquet de type DHCP.

Pour le champ des options, nous retrouvons le format suivant :

Octet1 Octet2 Octet3
Code de loption Longueur Donnes

1. Le client diffuse un message DHCPDICOVER sur son rseau local physique. Le message DHCPDISCOVER
peut inclure des options qui suggrent des valeurs pour les adresses rseau et la dure du bail. Les agents de
relais BOOTP peuvent passer le message sur des serveurs DHCP qui ne se trouvent pas sur le mme sous rseau
physique. Nous reviendrons ultrieurement sur la raison dexister des agents de relais BOOTP.
Dans le paquet DHCP, nous retrouverons les informations de champs suivants :

Nom du champ Valeur Description
xid Nombre alatoire Nombre alatoire gnr par le client
ciaddr 0.0.0.0 Adresse IP du client (uniquement si le client a dj une adresse)
siaddr 0.0.0.0 Adresse IP du serveur DHCP
giaddr 0.0.0.0 Adresse IP de lagent DHCP
chaddr 00 11 2F 50 66 A1 Adresse matrielle du client

Au niveau UDP, IP et ARP, nous retrouverons les informations suivantes :

Adresse IP source 0.0.0.
Adresse IP de destination 255.255.255.255
Adresse MAC source ex : 00 11 2F 50 66 A1 (adresse MAC du client)
Adresse MAC de destination FF FF FF FF FF FF
Au niveau UDP Port source 68, port de destination 67

Nous retrouvons un champ doptions reprises dans le protocole RFC 2132 et nous nous limiterons aux options
les plus courantes. Dans le champ doptions, nous retrouverons :

DHCP option 53 DHCP Discover

2. Chaque serveur peut rpondre avec un message DHCPOFFER qui inclut une adresse rseau valide dans le
champ 'yiaddr' (et d'autres paramtres de configuration des options DHCP). Le serveur n'a pas besoin de rserver
l'adresse rseau offerte, bien que le protocole fonctionnera de manire optimale si le serveur vite d'allouer les
adresses offertes un autre client. Quand on alloue une nouvelle adresse les serveurs doivent vrifier que
l'adresse rseau offerte n'est pas dj utilise ; par ex : le serveur devrait vrifier les adresses offertes par une
requte d'cho ICMP. Les serveurs devraient tre implants de manire ce que les administrateurs rseaux
puissent choisir de dsactiver les vrifications des adresses nouvellement alloues. Le serveur transmet un
message DHCPOFFER au client, en utilisant l'agent de relais BOOTP si ncessaire.

ciaddr 0.0.0.0 Adresse IP du client
yiaddr 192.168.1.100 Adresse IP propose par le serveur DHCP


Adresse IP source 192.168.1.2 (adresse IP du serveur DHCP)
Adresse IP de destination 255.255.255.255 (adresse pas encore connue du client)
Adresse MAC source ex : 00 0F 66 C8 A1 38 (adresse MAC du serveur DHCP)
Adresse MAC de destination ex : 00 11 2F 50 66 A1 (adresse MAC du client)


DHCP option 53 DHCP Offer
DHCP option 1 Masque de sous rseau. Ex : 255.255.255.0
DHCP option 3 Routeur par dfaut. Ex : 192.168.1.1
DHCP option 51 Dure de location de ladresse IP. Ex : 1 jour
DHCP option 54 Adresse du serveur DHCP. Ex : 192.168.1.2

3. Le client reoit un ou plusieurs messages DHCPOFFER d'un ou plusieurs serveurs. Le client peut choisir
d'attendre des rponses multiples. Le client choisit un serveur pour ses paramtres de configuration, bas sur la
configuration prsente dans le DHCPOFFER. Le client diffuse un message DHCPREQUEST qui doit inclure
l'option 'identifiant serveur' indiquant quel serveur il a slectionn et qui peut inclure d'autres options spcifiant
les valeurs de configuration dsires. Loption 'adresse IP demande' doit tre rgle sur la mme 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 mme serveur DHCP qui reu le message DHCPDISCOVER original, le
DHCPREQUEST doit utiliser les mme valeurs dans l'en-tte du champ 'secs' du message DHCP et tre envoy
la mme adresse IP de diffusion que le message DHCPDISCOVER originel. Le client clture la fin dun
dlai dattente et retransmet le message DHCPDISCOVER si le client ne reoit pas de messages DHCPOFFER.

ciaddr 0.0.0.0 Adresse IP du client (pas encore dfinie car le serveur doit confirmer
ce choix)


Adresse IP source 0.0.0.0
Adresse MAC source ex : 00 11 2F 50 66 A1 (adresse MAC du client)
Adresse MAC de destination ex : 00 0F 66 C8 A1 38 (adresse MAC du serveur DHCP)


DHCP option 53 DHCP Request
DHCP option 50 Adresse demande. Ex : 192.168.1.100

4. Les serveurs reoivent les diffusions DHCPREQUEST des clients. Les serveurs qui ne sont pas slectionns
par le message DHCPREQUEST utilisent le message comme notification que le client dcline leur offre. Le
serveur slectionn dans le message DHCPREQUEST engage une liaison pour le client dans sa mmoire
permanente et rpond avec un message DHCPACK qui contient la configuration pour le client demandeur. La
combinaison entre 'identifiant client' ou 'chaddr' et l'adresse rseau assigne constitue un identifiant unique pour
le bail du client et sont utiliss la fois par le client et le serveur pour identifier un bail auquel il sera fait
rfrence dans tous les messages DHCP. N'importe quel paramtre de configuration dans le message DHCPACK
ne devrait pas produire de conflit avec ceux du prcdent message DHCPOFFER auquel le client rpond. Le
serveur ne devrait pas vrifier l'adresse rseau offerte ce stade. Le 'yiaddr' du DHCPACK est rempli avec
l'adresse rseau slectionne.



Adresse MAC source ex : 00 0F 66 C8 A1 38 (adresse MAC du serveur DHCP)
Adresse MAC de destination ex : 00 11 2F 50 66 A1 (adresse MAC du client)

Si le serveur slectionn est indisponible pour satisfaire au message DHCPREQUEST (par ex : l'adresse rseau
demande a t alloue), le serveur devrait rpondre 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 reoit pas de message DHCPREQUEST de ce client.

5. Le client reoit un message DHCPACK avec les paramtres de configuration. Le client devrait faire une
vrification finale sur les paramtres (par ex : ARP pour l'allocation de l'adresse rseau), et noter la dure du bail
spcifi dans le DHCPACK. A ce moment, le client est configur. Si le client dtecte que l'adresse est dj
utilise (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 seconde avant de relancer la
configuration pour viter un trafic rseau excessif dans le cas d'un bouclage.


DHCP option 53 DHCP ACK
DHCP option 1 Masque de sous rseau. Ex : 255.255.255.0
DHCP option 3 Routeur par dfaut. Ex : 192.168.1.1
DHCP option 51 Dure de location de ladresse IP. Ex : 1 jour
DHCP option 54 Adresse du serveur DHCP. Ex : 192.168.1.2

Si le client reoit un DHCPNACK, le client relance le processus de configuration.

Le client clture la fin dun dlai dattente et retransmet le message DHCPREQUEST si le client ne reoit ni
DHCPACK ni DHCPNACK. Le client retransmet le DHCPREQUEST conformment l'algorithme de
retransmission de la section 4.1.Le client devrait choisir de retransmettre le DHCPREQUEST suffisamment de
fois pour esprer contacter le serveur sans faire en sorte que le client (et l'utilisateur du client) n'attende trop
longtemps avant d'abandonner; par ex : un client retransmettant comme dcrit dans la section 4.1 pourrait
retransmettre le DHCPREQUEST 4 fois sur un total de 60 seconds, avant de relancer la procdure
d'initialisation. Si le client ne reoit ni DHCPACK ni DHCPNAK aprs lutilisation de lalgorithme de
retransmission, il retourne ltat INIT et relance le processus dinitialisation. Le client DEVRAIT notifier
l'utilisateur que le processus d'initialisation n'a pas abouti et qu'il est relanc.

6. Le client peut choisir de renoncer au bail sur une adresse rseau en envoyant un DHCPRELEASE au serveur.
Le client identifie le bail qu'il libre avec son 'identifiant client' ou 'chaddr' et l'adresse rseau dans le message
DHCPRELEASE. Si le client utilise un 'identifiant client' quand il obtient le bail il DOIT utiliser le mme
'identifiant client' dans le message DHCPRELEASE.

1.3. Agent de relai BOOTP.

Lorsquun rseau est compos de plusieurs segments spars par des routeurs ou des switchs, ceux-ci ne sont pas
configurs pour laisser passer des paquets de diffusion qui doivent rester local au segment dans lequel ils sont
gnrs. Cela peut nous obliger utiliser plusieurs serveurs DHCP, un par segment ce qui augment le cot et la
maintenance. Nous pouvons envisager aussi de prvoir au niveau des routeurs des agents de relai BOOTP dont le
seul rle sera de faire passer les paquets de diffusion de type DHCP.

Nous reprendrons uniquement le cas de figure ou le client na pas encore reu de bail pour une adresse IP
comme voqu au paragraphe 1.2. Lagent relai doit pouvoir accepter tout paquet de diffusion utilisant les ports
67 et 68 du protocole de transport UDP. Nous mettrons en vidence lutilisation du champ giaddr. Les
diffrentes adresses MAC et adresses IP seront les suivantes :

Rle Adresse matrielle Adresse IP
Client 00 11 2F 50 66 A1 Sur le segment 192.168.2.0/24
Agent relai DHCP 00 10 DB 57 DA 26 192.168.2.100/24
Serveur DHCP 00 0F 66 C8 A1 38 192.168.1.2/24

1. Le client diffuse un message DHCPDICOVER sur son rseau local physique. Lagent relai va intercepter ce
paquet de diffusion sur son port 68 et le rediriger par son port 67 vers le serveur DHCP. A ce niveau, laccs au
serveur DHCP ne se fera plus par diffusion mais directement vers ladresse du serveur connue de lagent relai.

ciaddr 0.0.0.0 Adresse IP du client (uniquement si le client a dj une adresse)


Adresse IP source 192.168.2.100
Adresse MAC source 00 10 DB 57 DA 26 (celle de lagent)
Adresse MAC de destination 00 0F 66 C8 A1 38 (celle du serveur)

2. A ce stade, il nest pas possible que plusieurs serveurs puissent rpondre la demande puisque lagent relai a
transmis le paquet vers un seul serveur. Celui-ci pourra donc transmettre une offre, non pas directement vers le
client mais vers lagent relai dont il connait ladresse MAC. Il est noter que le serveur DHCP retrouve ladresse
IP de lagent relai au travers du champ giaddr et quil peut donc attribuer une adresse dans le bon pool savoir
dans notre cas 192.168.2.0/24. Ce serveur, dans notre exemple, se situe sur le segment 192.168.1.0/24 et peut
donc disposer dun deuxime pool dadresse qui serait 192.168.1.0/24.



Adresse MAC source 00 0F 66 C8 A1 38 (adresse MAC du serveur DHCP)
Adresse MAC de destination 00 10 DB 57 DA 26 (adresse MAC de lagent relai)

3. Lagent relai va donc maintenant rediriger ce paquet vers le client qui na pas encore dadresse. Cette
redirection va donc devoir seffectuer via une diffusion et nous retrouverons donc les paquets suivants :



Adresse IP source 192.168.2.100 (adresse IP de lagent DHCP)
Adresse MAC source 00 10 DB 57 DA 26 (adresse MAC de lagent relai)
Adresse MAC de destination FF FF FF FF FF FF (adresse MAC de diffusion)

De manire similaire, nous retrouverons les tapes 4 et 5 savoir le paquet DHCPREQUEST et DHCPACK.

1.4. Rutilisation d'une adresse rseau anciennement attribue.

Si un client se souvient et souhaite rutiliser une adresse rseau anciennement attribue, il peut choisir d'omettre
les tapes dcrites prcdemment. Le diagramme montre la relation dans une interaction classique client -
serveur pour un client rutilisant une adresse rseau anciennement attribue.

1. Le client diffuse un message DHCPREQUEST sur son sous - rseau local. Le message inclut l'adresse rseau
du client dans l'option 'adresse IP demande' (option 50). Comme le client n'a pas encore reu son adresse
rseau, 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 mme sous rseau. Si le client utilise un 'identifiant client' pour obtenir son adresse, le
client doit utiliser le mme 'identifiant client' dans le message DHCPREQUEST.

2. Les serveurs qui connaissent les paramtres de configuration du client rpondent avec un DHCPACK au
client. Les serveurs ne devraient pas vrifier que l'adresse rseau du client est dj utilise; le client peut
rpondre une demande d'cho ICMP cet instant.
Si la requte du client est invalide (par ex : le client a chang de sous rseau), les serveurs devraient rpondre par
un message DHCPNAK au client. Les serveurs ne devraient pas rpondre si lexactitude de leurs informations
nest pas garantie. Par exemple, un serveur qui identifie une requte pour une affectation prime qui est dtenue
par un autre serveur ne devrait pas rpondre avec un DHCPNAK moins que les serveurs n'utilisent un
mcanisme explicite pour maintenir une cohrence entre les serveurs.

Si 'giaddr' est 0x0 dans le message DHCPREQUEST, le client est sur le mme sous rseau 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 rseau correcte ou le bon masque de sous rseau, et le client ne peut pas rpondre une requte
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
matrielle du client, de manire ce que le DHCPNAK puisse tre dlivr mme si le client s'est dplac vers un
nouveau rseau.

3. Le client reoit le message DHCPACK avec les paramtres de configuration. Le client effectue une
vrification finale sur les paramtres, et note la dure du bail spcifie dans lidentifiant client ou 'chaddr' et
l'adresse rseau. A ce stade, le client est configur.

Si le client dtecte que l'adresse IP dans le message DHCPACK est dj utilise, le client DOIT envoyer un
message DHCPDECLINE au serveur et relancer le processus de configuration en faisant la requte d'une
nouvelle adresse rseau. L'action correspond un dplacement du client vers l'tat INIT dans le diagramme
DHCP.

Si le client reoit un message DHCPNAK, il ne peut rutiliser l'adresse dont il se souvient. Il doit faire la requte
d'une nouvelle adresse en relanant le processus de configuration, cette fois en utilisant la procdure (non
abrge). Le client clture la fin dun dlai dattente et retransmet le message DHCPREQUEST si le client ne
reoit ni un DHCPACK ni un DHCPNAK. Le client retransmet le DHCPREQUEST en accord avec l'algorithme
de retransmission prcdemment abord. Le client devrait choisir de retransmettre le DHCPREQUEST
suffisamment de fois pour esprer contacter le serveur sans faire en sorte que le client (et l'utilisateur du client)
n'attende trop longtemps avant d'abandonner; par ex : un client pourrait retransmettre le DHCPREQUEST 4 fois
sur un total de 60 secondes, avant de relancer la procdure d'initialisation. Si le client ne reoit ni DHCPACK ni
DHCPNAK aprs avoir employ l'algorithme de retransmission, le client peut choisir d'utiliser une adresse
rseau allou prcdemment et les paramtres de configurations pour les baux non expirs. Ceci correspond un
dplacement vers l'tat AFFECT.

4. Le client peut choisir de renoncer son bail sur une adresse rseau en envoyant un message DHCPRELEASE
au serveur. Le client identifie le bail dont il veut se dfaire avec lidentifiant client ou 'chaddr' et l'adresse rseau
dans le message DHCPREALEASE.

Notez que dans ce cas, le client retient son adresse rseau localement, normalement le client ne renonce pas son
bail lors dun arrt normal. Uniquement dans le cas ou le client doit explicitement renoncer son bail, par ex : le
client va tre dplac sur un autre sous rseau, le client enverra un message DHCPRELEASE.

1.5. Interprtation et reprsentation des valeurs de temps

Un client acquire un bail pour une adresse rseau pour une priode fixe (qui peut tre infinie). Dans ce
protocole, lunit de temps est la seconde. La valeur temps 0xffffffff est rserve pour infini. Comme un client et
un serveur n'ont pas forcement une horloge synchronise et pour tre interprt correctement par les horloges des
clients locaux, le temps est reprsent dans les messages par des donnes relatives. Le temps relatif, reprsent
en secondes dans un mot de 32 bit non sign, donne une plage de temps relatif de 0 environ 100 ans, ce qui est
suffisant pour les temps mesurs dans DHCP.

1.6. Obtenir des paramtres avec des adresses rseau dj configures.

Si un client a obtenu une adresse rseau grce d'autres moyens (par ex. configuration manuelle) il peut utiliser
une requte DHCPINFORM pour obtenir d'autres paramtres locaux de configuration. Les serveurs recevant un
message DHCPINFORM construisent un message DHCPACK avec n'importe quels paramtres de configuration
appropris pour le client sans : allouer d'adresse, vrifier une liaison existante, remplir le 'yiaddr' ou inclure des
dures de bail. Les serveurs devraient faire une rponse adresse DHCPACK l'adresse donne dans le champ
'ciaddr' du message DHCPINFORM.

Le serveur devrait vrifier l'adresse rseau dans un message DHCPINFORM, mais il ne doit pas vrifier
l'existence d'un bail. Le serveur formule un message DHCPACK contenant les paramtres de configurations
pour le client ayant mis la requte et envoie le message DHCPACK directement au client.

1.7. Acquisition et expiration.

Le client maintient deux temporisateurs, T1 et T2 qui spcifient les temps auxquels le client essaie d'tendre son
bail sur son adresse rseau. T1 est le temps au bout duquel le client entre en tat RENOUVELLEMENT et tente
de contacter le serveur qui a mis l'adresse rseau du client. T2 est le temps au bout duquel le client entre en tat
REAFFECTATION et tente de contacter un serveur. T1 doit tre plus rcent que T2, qui doit tre plus rcent que
la date laquelle expire le bail.

Pour viter le besoin d'horloge synchronise, T1 et T2 sont exprims dans les options comme temps relatifs.

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 rseau. Le client enregistre l'heure locale laquelle le DHCPREQUEST t envoy pour
calculer la dure 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 silencieusement. Quand le client reoit un DHCPACK du serveur, le client calcule la dur du bail en
faisant la somme du temps auquel le client envoie le message DHCPREQUEST et la dure du bail obtenu dans
le message DHCPACK. Le client a fait de nouveau l'acquisition de son adresse rseau, et retourne en tat
AFFECT et peut continuer son processus rseau.

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 rgle le champ 'ciaddr' du DHCPREQUEST avec sa
propre adresse rseau. 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 dfaut de T1 est (0.5*dure_du_bail) et celle de T2 =
(0.875*dure_du_bail). Les temps T1 et T2 devraient tre choisis avec une petite notion de " hasard " autour de
la valeur par dfaut, 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 stratgie de l'administrateur rseau. Le serveur devrait retourner T1 et T2 et leurs valeurs
devraient tre ajustes 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 reoit pas de rponse 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 reoive un DHCPACK, le client passe en tat INIT, il doit alors
immdiatement stopper tout processus rseau et ncessite une initialisation des paramtres rseau comme si le
client n'tait pas initialis. Si le client reoit alors un DHCPACK allouant la prcdente adresse rseau du client
il devrait continuer son processus rseau. Si le client obtient une nouvelle adresse rseau, il ne doit pas continuer
utiliser l'adresse pralable et devrait avertir l'utilisateur local du problme.

1.8. Installation et configuration dun serveur sous Linux.

DHCP

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DHCP

Transféré par

Droits d'auteur :

Formats disponibles

1. Le service DHCP.

Vous aimerez peut-être aussi