BOOTP : Tout savoir sur le précurseur du DHCP
L'équipe éditoriale IONOS
Afin de pouvoir communiquer sur des réseaux comme Internet, les systèmes participants nécessitent une adresse IP. Bien que cette dernière puisse être attribuée manuellement, en pratique, la plupart des appareils obtiennent aujourd’hui leur adresse de façon automatique. Pour ce faire, le protocole de communication DHCP est utilisé. Celui-ci aide les systèmes cherchant à établir une connexion à acquérir les informations nécessaires. À l’aube de l’informatique, des réseaux, etc., le Bootstrap Protocol, également connu sous le nom de BOOTP, assumait encore la fonction de gestionnaire d’adresses.
Qu’est-ce que le BOOTP (Bootstrap Protocol) ?
En septembre 1985, le Stanford University Network Group publiait dans RFC 951 la première version du Bootstrap Protocol (BOOTP). Développé en collaboration avec une équipe du fabricant de systèmes informatiques Sun Microsystems, ce protocole de communication permettait pour la première fois aux terminaux et aux postes de travail sans disque dur utilisés à l’époque d’obtenir en plus de l’adresse IP des informations telles que l’adresse de la passerelle, l’adresse du serveur de démarrage et le registre du fichier de démarrage (nécessaires au chargement du système d’exploitation). Il vint remplacer le Reverse Address Resolution Protocol (RARP) utilisé jusqu’alors qui livrait exclusivement des adresses réseau et pouvait uniquement être utilisé dans les sous-réseaux.
Le Bootstrap Protocol fait partie de la suite des protocoles Internet et fonctionne – à l’instar de nombreux autres protocoles de la pile – selon le modèle du client-serveur. La communication de messages en vue de la transmission de l’information réseau est donc effectuée entre un client BOOTP et le serveur BOOTP. Le protocole minimal et sans connexion User Datagram Protocol (UDP) (ports 67 et 68) est utilisé comme protocole pour le transport des paquets de données correspondants. Comparé au TCP, ce protocole UDP est non seulement moins complexe mais supporte également la télédiffusion, contrairement au protocole standard pour le transport de données. Étant donné que le client ne connaît ni sa propre adresse ni l’adresse du serveur BOOTP lors de l’établissement de la connexion, cette méthode de communication de messages, dans le cadre de laquelle tous les participants du réseau sont contactés, est la seule solution pour une acquisition automatique de l’adresse.
Fonctionnement de la communication d’informations réseau via BOOTP
L’attribution d’une adresse via BOOTP est basée sur une communication simple en deux étapes entre le client et le serveur. Dans ce cadre, la composante client est à l’initiative de cette communication. Étant donné que le client ne connaît ni sa propre adresse IP ni celle du serveur BOOTP, il envoie une requête générale (« BOOTREQUEST ») à l’adresse de diffusion universelle 255.255.255.255. Le serveur qui écoute les requêtes du port UDP 67 reçoit et traite cette requête. Dans ce cadre, sa tâche principale consiste à attribuer l’adresse IP adéquate à l’adresse MAC du système du client. Par télédiffusion, la réponse (« BOOTREPLY ») est ensuite renvoyée avec les autres informations réseau au client qui peut alors acquérir le système d’exploitation via le réseau.
lorsque le client connaît déjà l’adresse du serveur BOOTP, il peut également envoyer la requête directement au serveur par connexion unicast.
Voici à quoi ressemble la structure des messages envoyés par le client et le serveur lors de la communication par le biais du Bootstrap Protocol :
Chaque message BOOTP commence avec le champ op de 8 bits qui définit le type d’opération ou de message. En cas de requêtes du client, la valeur de ce champ est définie sur 1 (pour BOOTREQUEST) et sur 2 s’il s’agit d’une réponse du serveur (pour BOOTREPLY). Cette valeur est à chaque fois suivie de 8 bits qui caractérisent le type (« htype ») ainsi que la longueur de l’adresse matérielle (« hlen »). Le champ « hops » comporte également 8 bits et indique le nombre de stations intermédiaires que le paquet doit traverser pour atteindre le destinataire. En cas de requêtes du client, la valeur est toujours définie sur 0.
Le bloc suivant contient un ID de transaction aléatoire d’une longueur de 32 bits qui est généré par le client et sera utilisé ultérieurement dans la réponse du serveur afin de permettre au client de l’associer formellement. Le client remplit par ailleurs le champ « secs » (16 bits) qui indique les secondes écoulées depuis la tentative de démarrage du client. L’information d’introduction est complétée par un autre champ de 16 bits qui reste entièrement vide. Les autres entrées du paquet BOOTP sont les informations propres au réseau qui sont expliquées de façon détaillée dans la liste suivante :
- Adresse IP du client (ciaddr) : le label « ciaddr » (client ip address) indique le champ de 32 bits dans lequel le client a renseigné son adresse IP s’il l’a connaît déjà. Si tel n’est pas le cas, le champ prend la valeur 0.
- Adresse IP du client (yiaddr) : le champ « yiaddr » (your ip address) est également réservé à l’adresse IP du client. Contrairement à la section du paquet citée précédemment, ce champ de 32 bits est toutefois complété par le serveur si le client ne connaît pas son adresse IP au moment de la création de la requête de réseau.
- Adresses IP du serveur (siaddr) : dans la séquence de 32 bits « siaddr » (server ip address), le serveur BOOTP communique son adresse IP au client.
- Adresse IP de la passerelle (giaddr) : si une passerelle/gateway (par ex. un routeur) est intégrée au processus de communication, son adresse est renseignée dans le champ « giaddr » (gateway ip address).
- Adresse matérielle du client (chaddr) : l’adresse matérielle (128 bits) fait partie des champs obligatoires du client dans le cadre de la communication des messages du Bootstrap Protocol. Sans cet ID, également appelé adresse de l’appareil ou adresse MAC, le serveur ne peut ni attribuer la bonne adresse au client ni affecter les paramètres réseau adéquats.
- Nom d’hôte du serveur (sname) : en option, le serveur peut d’autre part indiquer son nom d’hôte dans la réponse BOOTP. Un champ d’une longueur de 512 bits est disponible à cet effet dans lequel il peut insérer une chaîne de caractère correspondante terminée par un zéro (un zéro marque la fin de la chaîne).
- Nom du fichier de démarrage (file) : l’indication d’un fichier de démarrage précis, dont le client a besoin pour démarrer le système d’exploitation sur le terminal concerné ou la station de travail, est également facultative. Ce champ prévoit également une chaîne de caractère terminée par un zéro qui représente dans ce cas le chemin de registre complet du fichier. La séquence de caractères peut atteindre ici une longueur de 1024 bits. Dans la requête du client, ce champ comporte soit la valeur 0 soit un nom générique.
- Informations spécifiques au fabricant (vend) : la conclusion potentielle du message du protocole BOOTP est constituée par des informations spécifiques au fabricant, qui ne sont pas couvertes par le protocole. Il peut par exemple s’agir de l'indication de types et de numéros de série de matériel spécifiques. Par ailleurs, ce champ d’information disposant d’une longueur de 512 bits peut être réservé pour un troisième processus Bootstrap ou de noyau.
Au total, les messages BOOTP peuvent donc avoir une longueur allant jusqu’à 2400 bits (300 octets). Le datagramme UDP/IP complet, incluant la requête ou la réponse du Protocole Bootstrap intégrée, dispose de la structure suivante :
Le BOOTP et DHCP : pourquoi le Bootstrap Protocol n’est-il plus utilisé ?
Pour les clients terminaux et les stations de travail sans disque dur, le BOOTP représentait la solution idéale afin d’obtenir une adresse IP personnelle dans le réseau souhaité et d’acquérir le système d’exploitation de cette façon. Le fait que l’acquisition de l’adresse puisse être réalisée en même temps que le processus de démarrage grâce au protocole de communication était aussi simple que pratique pour les ordinateurs fixes utilisés dans les réseaux de taille gérable. Le fait que l’administrateur doive configurer manuellement les tableaux d’informations du réseau du serveur BOOTP était alors peu problématique.
Toutefois, alors que les réseaux sont devenus toujours plus conséquents et les ordinateurs toujours plus indépendants et plus mobiles (du fait du développement des appareils mobiles), l’absence de possibilité d’automatisation du processus de configuration a été perçue négativement. Le souhait d’un nouveau protocole s’est fait sentir. Son successeur fut trouvé en 1993 avec le Dynamic Host Configuration Protocol (DHCP) (spécification finale dans le RFC 2131). Même si le DHCP se base en grande partie sur la structure du Bootstrap Protocol, il est complété par différentes options de configuration supplémentaires et offre aux clients cherchant à établir une connexion la possibilité d’attribuer des adresses réseau réutilisables. D’autre part, l’attribution d’informations d’adresses avec DHCP est également possible pendant le fonctionnement du système ; aucun redémarrage n’est nécessaire comme dans le cas du BOOTP.
Le BOOTP par rapport au DHCP : les principales différences :
| BOOTP | DHCP | |
| Configuration automatique | L’attribution d’adresses IP présuppose une configuration manuelle des tableaux d’adresse | Supporte une attribution et une acquisition automatiques des adresses IP (mais également une configuration manuelle) |
| Adresses IP temporaires | Impossible | Possible pour une période limitée |
| Compatibilité avec les appareils mobiles | La configuration IP et l’accès aux informations de réseau ne sont pas possibles | Supporte la mobilité des clients réseau |
| Taux d’erreur | Taux d’erreur important du fait de la configuration manuelle | Presque aucune erreur grâce à la configuration automatique des composants réseau |
| Prérequis système | Aucun | Nécessite un disque dur pour l’enregistrement et la transmission des informations |
Grâce aux différentes optimisations, le DHCP s’est rapidement établi comme protocole standard pour la gestion des adresses IP dans les réseaux, tandis que le protocole BOOTP a aujourd’hui uniquement une valeur historique. Toutefois, comme le DHCP supporte le Bootstrap Protocol, les serveurs DHCP peuvent en principe répondre à tout type de demandes provenant d’un client BOOTP.
