Protocole BOOTP

Le protocole BOOTP, beaucoup plus récent, est beaucoup plus efficace que RARP et tend, avec DHCP, à le supplanter.

Les principaux inconvénients de RARP sont :

d'être de bas niveau (interaction avec le matériel) et donc d'être très difficilement intégrables dans des applications serveurs de haut niveau,
de gaspiller beaucoup de place sur le réseau avec des trames très courtes, ce qui nécessite d'utiliser des bits de bourrage si les trames physiques peuvent ou même doivent être beaucoup plus longues (par exemple Ethernet),
de nécessiter une adresse physique fixe, ce qui est incompatible avec les réseaux qui attribuent des adresses physiques dynamiquement.

De plus, le protocole RARP étant souvent utilisé pour le démarrage de stations diskless, de nombreuses informations autres que l'adresse IP sont nécessaires, en particulier une image mémoire pour démarrer. Le protocole BOOTP (BOOTstrap Protocol) utilise UDP et IP, et peut donc être utilisé au sein d'une application. Il ne nécessite qu'un seul échange de trames, diffusées dans les deux sens en broadcast limité au réseau (adresse = 255.255.255.255), dont la longueur fixe est de 279 octets. Parmi les informations qu'elle contient, citons :

le code indiquant s'il s'agit d'une requête ou d'une réponse,
l'adresse physique du client (qui risque d'être le seul champ rempli dans la trame de requête, comme avec RARP),
l'adresse IP du client (le demandeur) remplie par lui s'il la connaît,
l'adresse IP du client remplie en réponse par le serveur si le client ne la connaît pas,
l'adresse IP ou le nom d'une machine serveur, si le client connaît le serveur auquel il doit s'adresser,
l'adresse IP d'un routeur,
le nom du fichier de boot à utiliser. Dans la requête, le client indique seulement un nom générique (par exemple "Unix") ou même un champ nul, alors que la trame renvoyée par le serveur contient le véritable nom du fichier de boot, que le client peut demander à l'étape suivante (en utilisant le protocole de transfert TFTP : Trivial File Transfert Protocol) et qui contient l'image mémoire du système pour démarrer. Cela offre la possibilité à un serveur d'une part de prendre en compte des configurations hétérogènes, avec plusieurs systèmes d'exploitation et des machines différentes, d'autre part de ne pas gérer lui-même toutes les images mémoire. Le serveur joue alors simplement le rôle de serveur d'images mémoire.

Notons pour finir que, le protocole BOOTP utilisant le protocole UDP, les trames de requête et de réponse peuvent être perdues. A cause de cela, le client utilise un délai de timeout au-delà duquel il réémet la trame, avec une temporisation aléatoire, et en contrepartie il peut traiter la duplication des réponses (en ne traitant que la première et en ignorant les autres). De plus il force UDP à utiliser le champ Checksum (paragraphe VIII.1) et force à 1 le bit NF de Non Fragmentation dans le datagramme IP (paragraphe VI.3).

Page prec. Début page Page suiv.