BOOTP et DHCP - DEPARTEMENT INFORMATIQUE IUT Aix

Réseaux - Cours 3
BOOTP et DHCP : Amorçage et configuration automatique
Cyril Pain-Barre
IUT Informatique Aix-en-Provence
Semestre 2 - version du 20/4/2010
1/67
Cyril Pain-Barre
BOOTP et DHCP
1/73
Introduction
Pour utiliser TCP/IP (et bénéficier notamment des services
d’Internet), tout ordinateur a besoin d’être configuré
La configuration minimale requise comprend :
l’adresse IP
le masque de sous-réseau
l’adresse d’un routeur
desquels découle une table de routage minimale
D’autres éléments sont aussi appréciables :
serveur de noms : permet la traduction allegro.iut.univ-aix.fr en
139.124.187.4
serveur de domaines windows : chargé de la gestion des
groupes (WORKGROUP, etc.)
serveur d’authentification : chargé de vérifier le couple
utilisateur/mot de passe
serveur d’impression : chargé de gérer des requêtes d’impression
etc.
2/67
Cyril Pain-Barre
BOOTP et DHCP
2/73
Nécessité de l’autoconfiguration
L’autoconfiguration des stations est parfois nécessaire :
ordinateur sans disque dur : contient un microprogramme en
ROM commun à tous les ordinateurs du constructeur. Il ne
peut contenir une configuration spécifique
ordinateur nomade (portable) : la configuration doit changer
d’un réseau à l’autre
Pour l’administrateur réseau, il est préférable de centraliser les
adresses attribuées plutôt que d’intervenir sur chaque
ordinateur
Trois protocoles ont été développés pour résoudre ces
problèmes :
RARP (Reverse ARP) : obsolète, il ne permettait que d’obtenir
une adresse IP
BOOTP : permet d’obtenir toutes les informations nécessaires
DHCP : extension de BOOTP
3/67
Cyril Pain-Barre
BOOTP et DHCP
3/73
Le protocole BOOTP : BOOTstrap Protocol
(RFC 951 mis à jour par la RFC 1542)
4/67
Cyril Pain-Barre
BOOTP et DHCP
4/73
Objectifs de BOOTP
BOOTP a été initialement défini pour répondre à trois besoins :
TCP/IP : permettre l’autoconfiguration de la pile TCP/IP
système d’exploitation : donner suffisamment d’information
à un ordinateur sans disque pour qu’il puisse télécharger une
image de son système d’exploitation
informations du constructeur : permettre à un ordinateur
sans disque d’obtenir des informations spéciques à son modèle
qui ne peuvent être stockées en ROM en usine car
dépendantes du contexte.
5/67
Cyril Pain-Barre
BOOTP et DHCP
5/73
Démarrage d’une station sans disque avec BOOTP
La station (client BOOTP) diffuse une requête BOOTP (demandant
implicitement sa configuration TCP/IP et un système d’exploitation)
BOOTP nécessite un réseau à diffusion
Un serveur BOOTP répond en indiquant la configuration TCP/IP, des
informations propres au modèle de la station, ainsi que les informations
permettant de récupérer le système d’exploitation :
l’adresse d’un serveur possédant l’image du système souhaité
le chemin complet de cette image sur le serveur
À ce stade, la station est configurée au niveau TCP/IP
La station procède ensuite au téléchargement de son système,
généralement avec TFTP :
devient client TFTP et contacte le serveur indiqué par le serveur BOOTP
le serveur TFTP renvoie l’image du système
La station est maintenant opérationnelle
6/67
Cyril Pain-Barre
BOOTP et DHCP
6/73
Démarrage avec BOOTP et TFTP : illustration
réseau à diffusion
7/67
Cyril Pain-Barre
BOOTP et DHCP
7/73
Démarrage avec BOOTP et TFTP : illustration
requête BOOTP (broadcast)
réseau à diffusion
7/67
Cyril Pain-Barre
BOOTP et DHCP
8/73
Démarrage avec BOOTP et TFTP : illustration
serveur BOOTP
requête BOOTP (broadcast)
réseau à diffusion
7/67
Cyril Pain-Barre
BOOTP et DHCP
9/73
Démarrage avec BOOTP et TFTP : illustration
serveur BOOTP
réponse BOOTP
réseau à diffusion
7/67
Cyril Pain-Barre
BOOTP et DHCP
10/73
Démarrage avec BOOTP et TFTP : illustration
serveur BOOTP
Configuration TCP/IP obtenue
réseau à diffusion
La suite dépend de la station :
si seule la configuration TCP/IP était nécessaire, la station est
configurée
mais pour une station sans disque, il faut télécharger le
système d’exploitation dont les ”coordonnées” ont été fournies
dans la réponse BOOTP
7/67
Cyril Pain-Barre
BOOTP et DHCP
11/73
Démarrage avec BOOTP et TFTP : illustration
serveur TFTP
requête TFTP
réseau à diffusion
7/67
Cyril Pain-Barre
BOOTP et DHCP
12/73
Démarrage avec BOOTP et TFTP : illustration
serveur TFTP
téléchargement TFTP
réseau à diffusion
7/67
Cyril Pain-Barre
BOOTP et DHCP
13/73
Situation de BOOTP dans TCP/IP
BOOTP est un protocole d’application
BOOTP
Il utilise UDP pour transporter ses messages
L’utilisation d’IP permet de traverser des
routeurs
En conséquence, le serveur BOOTP n’est pas
forcément sur le même réseau : utilisation
possible d’un ou plusieurs relais BOOTP
client BOOTP
UDP
IP
serveur
BOOTP
relais BOOTP
Internet
la requête du client est retransmise en unicast
et la réponse reviendra en unicast au relais (ou au client)
Les messages BOOTP sont transmis avec le bit Don’t Fragment à 1 (IP).
Cyril Pain-Barre
BOOTP et DHCP
8/67
14/73
Envoi des requête et réponse BOOTP
Requête BOOTP :
envoyée en diffusion limitée IP 255.255.255.255 et adresse source 0.0.0.0
le port UDP destination est celui réservé aux serveurs BOOTP : 67
Le protocole prévoit qu’un client puisse émettre une requête
même s’il connaı̂t déjà son adresse IP pour obtenir les autres
informations. Dans ce cas, l’adresse source n’est plus 0.0.0.0.
Réponse BOOTP : comment le serveur peut-il renvoyer la réponse ?
envoi en unicast à l’adresse IP du client impossible si :
le serveur ne peut mettre à jour le cache ARP (le client ne peut pas
répondre à une requête ARP)
le logiciel IP du client refuse un datagramme en unicast s’il ne connaı̂t
pas son adresse
envoi en broadcast (255.255.255.255)
toutes les stations le recevront
le port destination ne peut pas être quelconque pour ne pas perturber des
applications éventuelles d’autres stations : toutes les réponses doivent
être envoyées au port 68 réservé aux clients BOOTP
Cyril Pain-Barre
BOOTP et DHCP
9/67
15/73
Format des messages BOOTP
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
Adresse IP Serveur
Adresse Physique Client
16 octets
Nom Serveur
64 octets
Nom du fichier d’amorce
128 octets
taille minimale = 300 octets
Adresse IP Routeur
minimum
64 octets
Zone Constructeurs
10/67
Cyril Pain-Barre
BOOTP et DHCP
16/73
Messages BOOTP : opération
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Indique la nature du message :
1 = requête (BOOTREQUEST)
2 = réponse (BOOTREPLY)
Votre Adresse IP
Adresse IP Serveur
Adresse Physique Client
16 octets
Nom Serveur
64 octets
Nom du fichier d’amorce
128 octets
taille minimale = 300 octets
Adresse IP Routeur
minimum
64 octets
Zone Constructeurs
11/67
Cyril Pain-Barre
BOOTP et DHCP
17/73
Messages BOOTP : type réseau et longueur des adresses
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
Renseignés par le client
B
Inutilisé (à zéro)
Adresse IP Client
Adressephysique
IP
Indiquent le type de réseau et la longueurVotre
de l’adresse
Adresse
Si Type Réseau = 1 alors Ethernet (cf. RFC
1700) IP Serveur
Adresse IP Routeur
Adresse Physique Client
16 octets
Nom Serveur
64 octets
Nom du fichier d’amorce
128 octets
taille minimale = 300 octets
et Lg Adr Phys vaut 6
minimum
64 octets
Zone Constructeurs
12/67
Cyril Pain-Barre
BOOTP et DHCP
18/73
Messages BOOTP : sauts
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Mis à 0 par le client
Votre Adresse IP
Incrémenté de 1 par les relais
Ne doit jamais
Adresse
dépasser
IP Serveur
16 (message détruit par le 16° relais)
Adresse Physique Client
16 octets
Nom Serveur
64 octets
Nom du fichier d’amorce
128 octets
taille minimale = 300 octets
Souvent valeur
limite
fixée à 4
Adresse
IP Routeur
minimum
64 octets
Zone Constructeurs
13/67
Cyril Pain-Barre
BOOTP et DHCP
19/73
Messages BOOTP : identifiant transaction
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
Valeur (aléatoire) placée
par le
Adresse
IPclient
Serveur
Adresse Physique Client
16 octets
Nom Serveur
64 octets
Nom du fichier d’amorce
128 octets
taille minimale = 300 octets
Permet d’associer laAdresse
réponseIP
à Routeur
la requête
minimum
64 octets
Zone Constructeurs
14/67
Cyril Pain-Barre
BOOTP et DHCP
20/73
Messages BOOTP : secondes
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
IP Routeur
Renseigné par leAdresse
client, indique
le nombre de secondes
écoulées depuis la première tentative d’obtention d’une
réponse : le serveur (ou relais) traite en priorité les clients ayant
Adresse
Physique Client
attendu le plus
longtemps
16 octets
Nom Serveur
64 octets
Nom du fichier d’amorce
128 octets
taille minimale = 300 octets
Adresse IP Serveur
minimum
64 octets
Zone Constructeurs
15/67
Cyril Pain-Barre
BOOTP et DHCP
21/73
Messages BOOTP : bit B
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Adresse
Client
est renseigné
(légèrePhysique
contradiction...)
si 0, le mode d’envoi de la réponse dépend du serveur (ou relais) :
16 octets
unicast si le serveur (relais) peut mettre à jour son cache ARP
Nom Serveur
64 octets
Nom du fichier d’amorce
128 octets
taille minimale = 300 octets
Votre Adresse IP
Adresse IP Serveur
Renseigné par le client
Adresse IP Routeur
si à 1, le client ne peut pas recevoir la réponse en unicast qui
devra être transmise en broadcast sauf si le champ Adresse IP Client
broadcast sinon
minimum
64 octets
Zone Constructeurs
16/67
Cyril Pain-Barre
BOOTP et DHCP
22/73
Messages BOOTP : adresse physique du client
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
Adresse IP Serveur
Adresse Physique Client
16 octets
Nom Serveur
64 octets
taille minimale = 300 octets
Adresse IP Routeur
128 octets
Le client indique ici son adresse physique de taille Lg Adr Phys, les octets restants étant à 0
Le serveur cherchera une correspondance
de cette adresse (pour le type et la longueur
Nom du fichier d’amorce
mentionnés) dans sa base pour fournir les renseignements demandés
minimum
64 octets
Zone Constructeurs
17/67
Cyril Pain-Barre
BOOTP et DHCP
23/73
Messages BOOTP : nom du fichier d’amorce
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Le client peut indiquer ici un nom générique pour le système
Votre Adresse IP
d’exploitation souhaité comme "unix" ou "windows"
Les octets non utilisés sont à 0
Adresse IP Serveur
taille minimale = 300 octets
Si ce champ est laissé à 0 par le client, le serveur fournira les
Adresse IP Routeur
"coordonnées" d’un système par défaut
Adresse Physique Client
16 octets
Nom Serveur
64 octets
Nom du fichier d’amorce
128 octets
minimum
64 octets
Zone Constructeurs
18/67
Cyril Pain-Barre
BOOTP et DHCP
24/73
Messages BOOTP : adresse IP client
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
Adresse IP Serveur
mais si le client a déjà obtenu une adresse il peut l’indiquer ici.
Adresseenvoyés
Physique
Dans ce cas, il doit être prêt à recevoir les datagrammes
à Client
cette adresse et doit répondre aux requêtes ARP la concernant, et le
16 octets
taille minimale = 300 octets
Adresse IP Routeur
Le standard recommande fortement de laisser ce champ à 0
serveur (relais) enverra la réponse en unicast à cette adresse
Nom Serveur
64 octets
Nom du fichier d’amorce
128 octets
minimum
64 octets
Zone Constructeurs
19/67
Cyril Pain-Barre
BOOTP et DHCP
25/73
Messages BOOTP : votre adresse IP
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
Adresse IP Serveur
Adresse Physique Client
du client (si différente
du champ Adresse IP Client, c’est
Nom Serveur
celle que devra ensuite utiliser le client)
minimum
64 octets
Zone Constructeurs
128 octets
Nom du fichier d’amorce
64 octets
En réponse, le serveur indique dans ce champ l’adresse IP
16 octets
taille minimale = 300 octets
Adresse IP Routeur
20/67
Cyril Pain-Barre
BOOTP et DHCP
26/73
Messages BOOTP : nom serveur
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Renseigné par le client si celui−ci désire obtenir les informations d’un serveur
Identification Transaction
en particulier.
Secondes
zéro) par 0).
Contient le nom du serveur
souhaité (code B
ASCII de Inutilisé
la chaîne(àterminée
Les octets non utilisés doivent être
à 0.
Adresse
IP Client
Seul le serveur se reconnaissant doit
répondre.
Votre
Adresse IP
Adresse Physique Client
16 octets
Nom Serveur
64 octets
Nom du fichier d’amorce
128 octets
Zone Constructeurs
64 octets
taille fixe = 300 octets
Un relais peut décider de transmettre la requête au serveur si celui−ci n’est
Adresse IP Serveur
pas sur le même réseau.
Adresse IP Routeur
21/67
Cyril Pain-Barre
BOOTP et DHCP
27/73
Messages BOOTP : nom serveur
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
Adresse IP Serveur
Adresse Physique Client
16 octets
Nom Serveur
64 octets
Nom du fichier d’amorce
128 octets
taille fixe = 300 octets
Adresse IP Routeur
En réponse, le serveur peut indiquer ici le nom du serveur (en principe
64 octets
TFTP) que le client doit contacter pour télécharger son système
d’exploitation, mais
essentielle sera placée dans le champ
Zonel’information
Constructeurs
Adresse IP Serveur.
22/67
Cyril Pain-Barre
BOOTP et DHCP
28/73
Messages BOOTP : adresse IP serveur
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
Adresse IP Serveur
16 octets
taille minimale = 300 octets
Adresse IP Routeur
Adresse Physique Client
En réponse, le serveur place dans ce champ l’adresse du serveur (en principe TFTP)
auprès duquel le client pourra télécharger son système d’exploitation.
Nom Serveur
64 octets
Nom du fichier d’amorce
128 octets
minimum
64 octets
Zone Constructeurs
23/67
Cyril Pain-Barre
BOOTP et DHCP
29/73
Messages BOOTP : adresse IP routeur
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
Adresse IP Serveur
Adresse Physique Client
16 octets
taille minimale = 300 octets
Adresse IP Routeur
Ce champ est très mal nommé car ne désigne en aucun cas l’adresse d’un routeur !
Le serveur enverra sa réponse à cette adresse si le champ Adresse IP Client
Nom du fichier d’amorce
minimum
64 octets
Zone Constructeurs
128 octets
n’est pas renseigné mais que ce champ l’est.
64 octets
Il est renseigné par le premier relais ayant retransmis la requête et indique
l’adresse IP de son interface ayantNom
reçu Serveur
la requête.
24/67
Cyril Pain-Barre
BOOTP et DHCP
30/73
Messages BOOTP : zone constructeurs
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
Adresse IP Serveur
Adresse Physique Client
64 octets
Nom Serveur
Ce champ est assez mal nommé : il contient des
16 octets
taille minimale = 300 octets
Adresse IP Routeur
informations de natures diverses.
minimum
64 octets
Zone Constructeurs
128 octets
Nom du fichier d’amorce
25/67
Cyril Pain-Barre
BOOTP et DHCP
31/73
Messages BOOTP : zone constructeurs
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
Adresse
IP Serveur
Le client place ici des informations à commuiquer
au serveur.
au serveur d’interpréter correctement les informations contenues dans ce champ
et/ou indiquant au serveur la forme que doit prendre
cePhysique
champ en
réponse.
Adresse
Client
Actuellement, le "magic cookie" standard est 99.130.83.99 (notation décimale
16 octets
taille minimale = 300 octets
Adresse
IP Routeur
Les 4 premiers octets de ce champ doivent contenir
un "magic
cookie" permettant
pointée) et doit être présent même si le client n’a aucune information à communiquer,
Parmi les informations que peut fournir le client, il yNom
a le type
de machine ou son
Serveur
numéro de série.
minimum
64 octets
Zone Constructeurs
128 octets
Nom du fichier d’amorce
64 octets
suivi de 255 et de zéros.
26/67
Cyril Pain-Barre
BOOTP et DHCP
32/73
Messages BOOTP : zone constructeurs
0
1
1
2
2
3 3
bits : 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ération
Type Réseau
Lg Adr Phys
Sauts
Identification Transaction
Secondes
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
Adresse IP Serveur
Le serveur répondra
en principe
selon
les souhaits du client.
Adresse
Physique
Client
16 octets
Les 4 premiers octets contiennent un "magic cookie" qui peut être différent
de celui du client et lui indiquant comment interpréter son contenu.
64 octets
taille minimale = 300 octets
Adresse IP Routeur
Parmi les informations que peut fournir le serveur, il y a le masque de sous−réseau,
Nom
des adresses de routeurs,
desServeur
adresses de serveurs DNS, etc.
minimum
64 octets
Zone Constructeurs
128 octets
Nom du fichier d’amorce
27/67
Cyril Pain-Barre
BOOTP et DHCP
33/73
La zone constructeurs
Le ”Magic Cookie” (clé de décodage) 99.130.83.99 est en
principe le seul utilisé et figure dans les 4 premiers octets de
tout message BOOTP
La RFC 2132 (mise à jour par la suite par plusieurs RFC)
définit un ensemble de champs, appelés options, qui suivent
le magic cookie
Chaque option débute par un code sur 1 octet qui identifie
l’option
Deux options particulières sont définies :
End Option : (code 255) marque la fin des options
Pad Option : (code 0) sert au bourrage pour remplir les 64
octets de la zone constructeurs, ou si cette zone dépasse 64
octets, pour la faire tenir sur un multiple de 4 octets
Les codes 128 à 254 sont réservés à un usage spécifique
propres aux sites et ne sont pas normalisés
Les autres codes sont rangés en catégories
Cyril Pain-Barre
BOOTP et DHCP
28/67
34/73
Les catégories des options
Codes
0, 255
1 à 18
19 à 25
26 à 33
34 à 36
37 à 39
40 à 49
64, 65
68 à 76
Catégorie
proviennent de la RFC 1497
configuration
configuration
configuration
configuration
générale IP de l’hôte
IP spécifique à l’interface de l’hôte
niveau liaison spécifique à l’interface
TCP spécifique à l’interface
configuration des services et applications
À part les options 0 et 255 qui n’occupent que l’octet de leur code,
toutes les options ont la forme suivante :
Code
Taille
Données
1 octet
1 octet
Taille octets
même si Taille vaut 0 (dans ce cas, pas de données).
Cyril Pain-Barre
BOOTP et DHCP
29/67
35/73
Quelques options d’intérêt
Masque de sous-réseau : doit être communiqué avant l’option
routeurs
code taille
1
4
masque
m1 m2 m3 m4
Décalage de temps : entier en complément à 2 représentant le
décalage en secondes par rapport à la date universelle (UTC)
code taille
2
4
décalage
d1
d2
d3
d4
Routeurs : listés par ordre de préférence. n doit être un
multiple de 4
code taille
3
n
adresse routeur 1
a1
a2
a3
adresse routeur 2
a4
a1
a2
a3
a4
...
n/4 adresses
30/67
Cyril Pain-Barre
BOOTP et DHCP
36/73
Quelques options d’intérêt (suite)
Serveurs DNS : listés par ordre de préférence. n doit être multiple de 4
code taille
6
n
adresse serveur 1
a1
a2
a3
adresse serveur 2
a4
a1
a2
a3
a4
...
n/4 adresses
Serveurs d’impression : listés par ordre de préférence. n doit être un
multiple de 4
code taille
9
n
adresse serveur 1
a1
a2
a3
adresse serveur 2
a4
a1
a2
a3
a4
...
n/4 adresses
Nom d’hôte : le nom du client, par exemple allegro. Peut être
complètement qualifié mais le nom de domaine doit être fourni par
l’option idoine
code taille
12
n
nom d’hôte
h1
h2
h3
h4
...
hn
31/67
n octets
Cyril Pain-Barre
BOOTP et DHCP
37/73
Quelques options d’intérêt (suite)
Nom de domaine : le domaine DNS que le client doit utiliser
pour résoudre les noms d’hôte, par exemple
iut.univ-aix.fr.
code taille
15
n
nom de domaine
d1
d2
d3
...
d4
dn
n octets
Conjugué au nom d’hôte, on obtient un nom complètement
qualifié, ex : allegro.iut.univ-aix.fr.
Taille de l’image du système d’exploitation : entier non signé
sur 16 bits indiquant la taille de l’image en nombre de blocs
de 512 octets
code
13
taille image
2
t1
t2
32/67
Cyril Pain-Barre
BOOTP et DHCP
38/73
Quelques options d’intérêt (suite)
Capacité de routage IP : indique si le client doit agir comme un
routeur. Non, si la valeur est 0, et oui si elle vaut 1
code
19
valeur
1
0/1
TTL IP par défaut : indique le TTL que doit utiliser IP pour l’émission
de datagrammes
code
23
1
TTL
Serveurs NTP (Network Time Protocol) : serveurs permettant de
synchroniser l’heure sur une horloge atomique, listés par ordre de
préférence, n doit être un multiple de 4
code taille
42
n
adresse serveur 1
a1
a2
a3
adresse serveur 2
a4
a1
a2
a3
a4
...
n/4 adresses
33/67
Cyril Pain-Barre
BOOTP et DHCP
39/73
Quelques options d’intérêt (suite)
Serveurs SMTP (mails sortants) : listés par ordre de préférence, n doit
être un multiple de 4
code taille
69
n
adresse serveur 1
a1
a2
a3
adresse serveur 2
a4
a1
a2
a3
a4
...
n/4 adresses
Serveurs de noms (NetBIOS over TCP/IP) : serveurs de noms
Windows, listés par ordre de préférence, n doit être un multiple de 4
code taille
44
n
adresse serveur 1
a1
a2
a3
adresse serveur 2
a4
a1
a2
a3
a4
...
n/4 adresses
34/67
Cyril Pain-Barre
BOOTP et DHCP
40/73
Stratégie de retransmission des requêtes BOOTP
BOOTP utilisant UDP et IP, les requêtes et les réponses
peuvent se perdre, être retardées, dupliquées, etc.
Le client BOOTP doit retransmettre sa requête s’il n’obtient
pas de réponse avant l’expiration d’un temporisateur
Le temporisateur ne doit pas être fixe
Sa durée est tirée aléatoirement :
entre 0 et 2n+1 secondes pour la ne tentative
mais 2n+1 ne doit pas dépasser 60
À chaque retransmission de sa requête, le client doit mettre à
jour le champ Secondes
Le client BOOTP peut recevoir plusieurs réponses à sa
requête : il ne doit traiter que la première et ignorer les autres
35/67
Cyril Pain-Barre
BOOTP et DHCP
41/73
Transmission de la réponse (BOOTREPLY) par un serveur
Dans le cas normal, la destination du message BOOTREPLY émis
par un serveur est, par ordre de préférence :
1
Adresse IP Client, port 68 si ce champ n’est pas nul
2
Adresse IP Routeur, port 67 si ce champ n’est pas nul : le
client n’est (probablement) pas sur le même réseau, et la
réponse est transmise au premier relais ayant retransmis la
requête
3
Votre Adresse IP, port 68 si le bit B est à 0 : le client est sur
le même réseau et peut recevoir la réponse en unicast.
L’adresse destination de la trame est celle indiquée dans le
champ Adresse Physique Client
4
255.255.255.255, port 68 si le bit B est à 1 : le client est sur
le même réseau mais ne peut recevoir la réponse en unicast.
L’adresse destination de la trame est celle de diffusion du
réseau physique
36/67
Cyril Pain-Barre
BOOTP et DHCP
42/73
Transmission de la réponse (BOOTREPLY) par un relais
Un relais reçoit le message BOOTREPLY et doit le transmettre au
client qui doit se trouver sur un réseau auquel est connecté le
relais. La destination du message sera, par ordre de préférence :
1
Votre Adresse IP, port 68 si le bit B est à 0 : le client est sur
le même réseau et peut recevoir la réponse en unicast.
L’adresse destination de la trame est celle indiquée dans le
champ Adresse Physique Client
2
255.255.255.255, port 68 si le bit B est à 1 : le client est sur
le même réseau mais ne peut recevoir la réponse en unicast.
L’adresse destination de la trame est celle de diffusion du
réseau physique.
Dans les deux cas, l’interface utilisée par le relais doit être celle
correspondant au champ Adresse IP Routeur
37/67
Cyril Pain-Barre
BOOTP et DHCP
43/73
Traitement des erreurs
Il existe de nombreux cas d’erreur en réception d’un
BOOTREQUEST ou d’un BOOTREPLY, que ce soit par le client,
un relais ou un serveur, comme par exemple :
un BOOTREPLY reçu par un relais alors que le champ
Adresse IP Routeur ne correspond pas à l’une de ses adresses
un BOOTREQUEST reçu par un relais qui excède la limite
autorisée
sachant qu’un serveur ou un relais BOOTP devrait aussi
écouter le port 68, reçoit un datagramme sur ce port
Dans tous les cas, le message en question est ignoré et ne donne pas
lieu à l’émission d’un message d’erreur
38/67
Cyril Pain-Barre
BOOTP et DHCP
44/73
Le protocole DHCP :
Dynamic Host Configuration Protocol
(RFC 2131 mis à jour par les RFC 3396 et 4361)
39/67
Cyril Pain-Barre
BOOTP et DHCP
45/73
Limitations de BOOTP
BOOTP a été conçu pour un environnement statique où une
station reçoit toujours la même adresse IP. En conséquence :
l’administrateur doit configurer manuellement au moins un
serveur BOOTP à chaque fois qu’une station est ajoutée au
réseau pour lui affecter une adresse IP disponible
pour un ensemble de n adresses IP disponibles, il n’est pas
possible de configurer un parc d’un nombre de stations
supérieur à n, même si jamais plus de n stations ne seront
actives en même temps
40/67
Cyril Pain-Barre
BOOTP et DHCP
46/73
La configuration dynamique par DHCP
DHCP rend possible l’allocation dynamique d’adresses :
l’administrateur fournit au serveur DHCP un ensemble
d’adresses IP que le serveur gèrera seul
lorsqu’une station demande une adresse, le serveur lui alloue
une adresse parmi celles prévues et qu’il n’a pas encore
attribué
41/67
Cyril Pain-Barre
BOOTP et DHCP
47/73
Les différentes allocations de DHCP
DHCP va plus loin et prend en charge simultanément trois types d’allocation :
l’allocation statique : un client obtiendra toujours la même
adresse, spécifiée par l’administrateur (attribution de type BOOTP)
l’allocation dynamique temporaire : une adresses est allouée
dynamiquement mais pour une durée limitée. On dit que l’adresse
est louée avec un bail. Le client peut ensuite demander le
renouvellement du bail. S’il ne le fait pas, l’adresse pourra être
attribuée à un autre client quand le bail expire
l’allocation dynamique permanente : une adresse peut être
allouée dynamiquement mais de façon permanente à un ordinateur
qui se connecte pour la première fois. Une requête de cet ordinateur
après un redémarrage se traduira par une allocation statique. Ce cas
est mis en œuvre par l’utilisation d’un bail infini. En pratique, un
serveur n’attribue qu’un bail très grand pour vérifier que le client est
toujours connecté.
Cyril Pain-Barre
BOOTP et DHCP
42/67
48/73
Étapes normales d’obtention d’adresse par le client
Dans les grandes lignes, l’obtention d’une adresse par le client
passe par les étapes suivantes :
1
Émission d’un DHCPDISCOVER en broadcast afin de
demander une adresse (et autres informations). Ce message
peut contenir une adresse souhaitée (par exemple, une adresse
obtenue précédemment)
2
Réception d’une ou plusieurs offres de la part de serveurs
(message DHCPOFFER)
3
Sélection d’une offre et demande au serveur l’attribution
proposée (message DHCPREQUEST en broadcast contenant
les informations fournies par le serveur)
4
Réception de la confirmation du serveur (message DHCPACK)
43/67
Cyril Pain-Barre
BOOTP et DHCP
49/73
Quelques problèmes potentiels
Sans les énumérer tous, certains cas empêchent le processus précédent :
Aucun serveur ne répond au DHCPDISCOVER, le client réémet le
message après un timeout
Aucun serveur ne répond au DHCPREQUEST, le client réémet le
message au maximum 4 fois, sinon recommence la procédure
Le serveur ne réserve pas forcément l’adresse proposée dans le
DHCPOFFER et peut répondre par un DHCPNAK au
DHCPREQUEST
En réception du DHCPACK suite au DHCPREQUEST, le client doit
vérifier que l’adresse n’est pas déjà utilisée en émettant une requête
ARP. Si déjà attribuée (une réponse ARP est reçue), doit envoyer un
DHCPDECLINE en broadcast et recommencer la procédure (en
attendant minimum 10 secondes)
Remarque : avant d’envoyer un DHCPOFFER, le serveur peut vérifier par
un ping que l’adresse proposée n’est pas déjà utilisée. . .
44/67
Cyril Pain-Barre
BOOTP et DHCP
50/73
Renouvellement du bail par le client
Une fois une adresse affectée, le client devra renouveller le bail avant son
expiration s’il souhaite continuer à l’utiliser. Ce renouvellement passe par
les étapes suivantes :
1
2
à 50% de la durée du bail, émission d’un DHCPREQUEST (unicast)
contenant l’adresse attribuée
3 cas possibles :
le serveur ne répond pas : la demande devra être réémise en broadcast
à 87,5% de la durée du bail
le serveur répond défavorablement (message DHCPNAK) : le client
doit cesser d’utiliser cette adresse mais peut recommencer le
processus d’obtention (voir précédemment)
le serveur répond favorablement (message DHCPACK) : ce message
indique une nouvelle durée du bail
3
la demande à 87,5% de la durée du bail diffère de la précédente par
la destination (broadcast). Si aucun serveur ne répond aucune
nouvelle demande ne doit être émise et le client devra cesser
d’utiliser l’adresse à expiration du bail
Cyril Pain-Barre
BOOTP et DHCP
45/67
51/73
Résiliation anticipée (dite ”élégante”)
Lorsqu’un client n’a plus besoin d’une adresse (par exemple, une
station sur le point d’être déplacée de réseau), il doit la résilier de
manière à permettre au serveur de l’allouer à un autre client.
Pour cela, il doit envoyer un message DHCPRELEASE en unicast au
serveur, qui inclut l’adresse en question, et doit cesser de l’utiliser.
46/67
Cyril Pain-Barre
BOOTP et DHCP
52/73
Demande de paramètres uniquement
Si le client a déjà une adresse obtenue par ailleurs (ex configuration
manuelle), il peut uniquement demander les autres paramètres qui
lui manquent.
Pour cela, le message à utiliser est DHCPINFORM qui liste les paramètres souhaités, qui peut être envoyé en unicast (le client connaı̂t
un serveur) ou en broadcast. Le serveur répond par un DHCPACK
envoyé en unicast.
47/67
Cyril Pain-Barre
BOOTP et DHCP
53/73
Automate d’états d’un client DHCP
Démarrage
Initialisation
DHCPACK / −
ou DHCPNAK / −
ou − / DHCPRELEASE
− / DHCPRELEASE
PR
/D
ilis
é
(ut
K
AC
CP
DH
CP
NA
K
ou
ma
xD
HC
Demande
DH
/ DHCPREQUEST
Choix d’une offre
timeout
/ DHCPREQUEST
HC
EQ
U
Sélection
Validation
Lien
ou
DH
−/
CP
NA
DH
K/
CP
RE
−
LE
AS
E
87,5% de la durée de location
DHCPACK / −
CP
ES
T/
EC
−
LIN
E
DH
e)
DHCPOFFER / −
arrêt timer
−/
PD
timeout / DHCPDISCOVER
Location Terminée
R
E
OV
C
DIS
Relié
/ DHCPREQUEST
CK
Renouvellement
/−
PA
ion
cat
e lo
e d ST
é
r
E
u
QU
la d
de CPRE
50% / DH
C
DH
48/67
Cyril Pain-Barre
BOOTP et DHCP
54/73
Les ordinateurs multiconnectés
Pour DHCP et BOOTP, si un ordinateur possède plusieurs
interfaces qui doivent être configurées automatiquement, cela se
traduit par une requête pour chaque interface.
Même s’il n’y a qu’un seul client DHCP, celui-ci se trouve dans un
état différent pour chaque interface.
49/67
Cyril Pain-Barre
BOOTP et DHCP
55/73
Situation de DHCP dans TCP/IP
DHCP est un protocole d’application
DHCP étend BOOTP : un serveur DHCP
est aussi un serveur BOOTP
En conséquence :
DHCP utilise les mêmes ports UDP
DHCP permet l’utilisation d’un ou plusieurs
relais BOOTP ou DHCP
Les relais doivent toujours transmettre au même
serveur/relais les messages provenant d’un même
client. Cette règle s’applique aussi pour BOOTP.
Client
UDP
IP
Serveur/Relais
DHCP
port 68
DHCP
DHCP
port 67
UDP
port 68 (pour éliminer les messages
adressés par erreur)
UDP
Cyril Pain-Barre
BOOTP et DHCP
50/67
56/73
Format des messages DHCP
Même format que BOOTP à
part le champ Options
(renommé) qui a une taille
variable
bits :
0
1
1
2
2
3 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ération
Type Réseau
Secondes
Tout client DHCP doit pouvoir
accepter un minimum de 312
octets d’options
Sauts
B
Inutilisé (à zéro)
Adresse IP Client
Votre Adresse IP
Adresse IP Serveur
Nom Serveur
Nom du fichier d’amorce
128 octets
Options
Toute la différence se situe
dans le champ Options
Cyril Pain-Barre
taille
variable
1 pour un message du
client vers le serveur
2 pour un message du
serveur vers le client
Adresse Physique Client
64 octets
taille fixe = 236 octets
Adresse IP Routeur
16 octets
L’interprétation des autres
champs ne change pas par
rapport à BOOTP. Notamment,
le champ Opération vaut :
Lg Adr Phys
Identification Transaction
51/67
BOOTP et DHCP
57/73
Le champ Options de DHCP
Comme BOOTP, doit commencer par le magic cookie
99.130.83.99 sur 4 octets
Toutes les options de BOOTP sont valides pour DHCP
Des options spécifiques à DHCP sont ajoutées
Le type du message DHCP est codé dans l’option Type de
Message :
code
taille
type
53
1
1à8
où type vaut :
1
2
3
4
5
6
7
8
:
:
:
:
:
:
:
:
DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPDECLINE
DHCPACK
DHCPNAK
DHCPRELEASE
DHCPINFORM
Cyril Pain-Barre
52/67
BOOTP et DHCP
58/73
Quelques options d’intérêt de DHCP
Adresse demandée : utilisée dans un DHCPDISCOVER par le client
pour demander une adresse en particulier
code taille
50
4
adresse
a1
a2
a3
a4
Temps de location : le temps est exprimé par un entier non signé sur 32
bits.
code taille
51
4
temps
t1
t2
t3
t4
Utilisée par :
le client dans DHCPDISCOVER ou DHCPREQUEST pour préciser la
durée souhaitée du bail
le serveur dans DHCPOFFER et DHCPACK pour indiquer la durée
accordée (qui prime sur celle souhaitée)
Un temps tout à 1 (0xFFFFFFFF en hexa) indique un bail permanent
(allocation dynamique permanente).
53/67
Cyril Pain-Barre
BOOTP et DHCP
59/73
Quelques options d’intérêt de DHCP
Adresse IP du serveur :
code taille
54
4
adresse
a1
a2
a3
a4
Utilisée dans les messages DHCPOFFER et DHCPREQUEST
(et éventuellement dans DHCPACK et DHCPNAK).
Adresse que doit utiliser le client pour ses envois en unicast au
serveur.
Dans un DHCPREQUEST, indique aux autres serveurs l’offre
choisie par le client
54/67
Cyril Pain-Barre
BOOTP et DHCP
60/73
Quelques options d’intérêt de DHCP
Paramètres demandés : indique n paramètres que souhaite
obtenir le client
code taille
55
n
codes d’options
c1
c2
c3
...
c4
cn
n octets
Utilisée dans les DHCPDISCOVER et DHCPREQUEST.
Chaque paramètre ci indiqué est le code de l’option
correspondante.
Le serveur fournit les paramètres dans les DHCPOFFER et DHCPACK.
Il peut ne fournir qu’une partie des paramètres demandés.
55/67
Cyril Pain-Barre
BOOTP et DHCP
61/73
Quelques options d’intérêt de DHCP
Longueur maximale des messages DHCP : la longueur est exprimée par
un entier non signé sur 16 bits
code taille
57
2
longueur
t1
t2
Utilisée par un client dans les messages DHCPDISCOVER ou
DHCPREQUEST pour indiquer la longueur maximale des messages qu’il peut recevoir (comprenant en-têtes IP et UDP).
La longueur minimale est 576 (min. 312 octets d’options).
56/67
Cyril Pain-Barre
BOOTP et DHCP
62/73
Quelques options d’intérêt de DHCP
Temps de renouvellement : exprimé par un entier non signé
sur 16 bits
code taille
58
4
temps
t1
t2
t3
t4
Utilisée éventuellement par un serveur dans les messages
DHCPOFFER et DHCPACK pour indiquer le temps en
secondes qui doit s’écouler pour que le client passe de l’état
Relié à l’état Renouvellement.
Si elle n’est pas présente, ce temps est 50% de la durée du bail
57/67
Cyril Pain-Barre
BOOTP et DHCP
63/73
Quelques options d’intérêt de DHCP
Temps de validation du lien : exprimé par un entier non signé
sur 16 bits
code taille
59
4
temps
t1
t2
t3
t4
Utilisée éventuellement par un serveur dans les messages
DHCPOFFER et DHCPACK pour indiquer le temps en
secondes qui doit s’écouler pour que le client passe de l’état
Relié à l’état Validation Lien (après être passé par
Renouvellement).
Si elle n’est pas présente, ce temps est 87,5% de la durée du bail
58/67
Cyril Pain-Barre
BOOTP et DHCP
64/73
Surcharge d’options
Lorsque le serveur a beaucoup d’informations à communiquer au
client, il peut décider d’utiliser les champs Nom du fichier d’amorce
et Nom Serveur pour y placer des options. Dans ce cas, il doit
utiliser l’option Surcharge d’options pour en informer le client :
code
taille
valeur
52
1
1−3
où valeur est :
1 : Nom du fichier d’amorce est utilisé pour des options
2 : Nom Serveur est utilisé pour des options
3 : les deux sont utilisés pour des options
Dans ce cas, les champs surchargés doivent commencer par des options, suivies de l’option End et d’un éventuel bourrage (options
Pad).
59/67
Cyril Pain-Barre
BOOTP et DHCP
65/73
Surcharge d’options (suite)
En cas de surcharge, le client devra traiter dans l’ordre :
1
les options du champ Options
2
les options du champ Nom du fichier d’amorce
3
les options du champ Nom Serveur
Enfin, deux options sont prévues pour remplacer ces champs :
Nom du Fichier de Boot :
code taille
67
n
nom du fichier de boot
f1
f2
f3
...
f4
fn
n octets
Nom du Serveur TFTP :
code taille
66
n
nom du serveur TFTP
s1
s2
s3
...
s4
sn
n octets
60/67
Cyril Pain-Barre
BOOTP et DHCP
66/73
Procédure de redémarrage d’un client
Lorsqu’un client redémarre, il peut essayer d’utiliser l’adresse précédente
(s’il l’a stockée) même si le bail a expiré, mais doit vérifier qu’il peut le
faire
Pour cela, il envoie un message DHCPREQUEST en broadcast en
indiquant l’adresse précédente dans l’option Adresse demandée
Si le serveur est d’accord, il envoie un DHCPACK :
le client vérifie par ARP que l’adresse n’est pas utilisée et passe à l’état
Relié
sinon doit envoyer un DHCPDECLINE et recommencer la procédure
d’attribution
Si le serveur n’est pas d’accord, il envoie un DHCPNAK et le client
recommence la procédure d’attribution d’adresse
Au cas où le serveur ne répond pas, le client réémet jusqu’à 4 fois la
requête puis recommence la procédure d’attribution d’adresse
Un serveur doit autant que possible allouer la même adresse
(et les mêmes paramètres) à un client.
Cyril Pain-Barre
BOOTP et DHCP
61/67
67/73
Interopérabilité entre DHCP et BOOTP (RFC 1534)
un serveur DHCP doit servir un client BOOTP si l’administrateur l’y a
autorisé. Pour cela il doit se comporter comme un serveur BOOTP :
l’adresse allouée est soit statique soit permanente (bail infini)
la réponse doit prendre la forme d’un BOOTREPLY : n’inclut pas
d’option Type de Message (mais pourrait contenir des options DHCP,
normalement ignorées par les anciens clients BOOTP)
la réponse du serveur est la fin de l’échange
un relais BOOTP doit relayer les messages de clients DHCP
un relais DHCP n’est rien d’autre qu’un relais BOOTP
un client DHCP peut accepter la réponse d’un serveur BOOTP et
considère alors que :
le bail est infini
la discussion est close à la réception du BOOTREPLY
mais doit préférer les réponses d’un serveur DHCP.
62/67
Cyril Pain-Barre
BOOTP et DHCP
68/73
Extrait de /etc/dhcpd.conf d’allegro
ddns-update-style none;
shared-network iutinfo {
option domain-name
option domain-name-servers
option netbios-name-servers
option netbios-node-type 8;
option time-offset
"iut.univ-aix.fr";
139.124.187.10, 139.124.1.2, 139.124.187.3,
193.50.125.2;
139.124.187.3, 139.124.187.20,139.124.187.15;
-5;
# Eastern Standard Time
subnet 139.124.187.0 netmask 255.255.255.0 {
option routers
139.124.187.1;
option subnet-mask
255.255.255.0;
range dynamic-bootp 139.124.187.226 139.124.187.240;
default-lease-time 6000000;
max-lease-time 72000000;
63/67
Cyril Pain-Barre
BOOTP et DHCP
69/73
Extrait de /etc/dhcpd.conf d’allegro (suite)
host portcpb {
hardware ethernet 00:0F:1F:13:34:9A;
fixed-address 139.124.187.34;
}
host a65 {
hardware ethernet 00:0b:db:88:af:d4;
fixed-address 139.124.187.65;
}
group {
use-host-decl-names on; # permet d’envoyer le nom d’hote host-name
host e193 {
hardware ethernet 00:18:8b:1e:b1:6a;
fixed-address 139.124.187.193;
}
}
host assopc {
hardware ethernet 00:0B:6A:3B:E4:8B;
fixed-address 139.124.187.225;
}
} #fin subnet 139.124
} #fin shared-network iutinfo
Cyril Pain-Barre
BOOTP et DHCP
64/67
70/73
Captures de messages client/serveur DHCP
Ces captures ont été réalisées avec le logiciel Wireshark :
au Département d’Informatique
au Laboratoire des Sciences de l’Information et des Systèmes
(LSIS)
65/67
Cyril Pain-Barre
BOOTP et DHCP
71/73
Fichier de sauvegarde des baux du client
En l’occurrence, /var/lib/dhcp3/dhclient.eth0.leases :
lease {
interface "eth0";
fixed-address 139.124.187.34;
option subnet-mask 255.255.255.0;
option time-offset -5;
option routers 139.124.187.1;
option dhcp-lease-time 6000000;
option dhcp-message-type 5;
option domain-name-servers 139.124.187.10,139.124.1.2,139.124.187.3,193.50.125.2;
option dhcp-server-identifier 139.124.187.4;
option netbios-name-servers 139.124.187.3,139.124.187.20,139.124.187.15;
option domain-name "iut.univ-aix.fr";
renew 6 2008/04/26 17:27:19;
rebind 4 2008/05/29 07:56:50;
expire 6 2008/06/07 00:16:50;
}
66/67
Cyril Pain-Barre
BOOTP et DHCP
72/73
Fichier de sauvegarde des baux du client (suite)
lease {
interface "eth0";
fixed-address 172.16.203.109;
option subnet-mask 255.255.255.0;
option dhcp-lease-time 43200;
option routers 172.16.203.250;
option dhcp-message-type 5;
option dhcp-server-identifier 172.16.203.190;
option domain-name-servers 193.51.217.162,193.51.217.130;
option domain-name "u-3mrs.fr";
renew 5 2008/03/28 02:51:03;
rebind 5 2008/03/28 02:51:03;
expire 5 2008/03/28 02:51:03;
}
67/67
Cyril Pain-Barre
BOOTP et DHCP
73/73