Résumé

  • BOOTP permettait à un client sans disque de demander son adresse IP, un serveur et un nom de fichier avant de disposer d’une connectivité IP normale ; un transfert distinct, généralement TFTP, récupérait ensuite le fichier.
  • La réponse posait un second problème : sans adresse, le client ne pouvait pas répondre à ARP. RFC 951 proposait soit une entrée ARP temporaire sur le serveur, soit une réponse diffusée en broadcast ; des règles ultérieures ont permis le relais entre sous-réseaux.

Au démarrage, une station sans disque ne possédait pas encore de système d’exploitation capable de configurer son réseau. Son programme en mémoire morte pouvait envoyer une demande, mais il lui fallait d’abord connaître l’adresse à utiliser et le fichier à charger. Ce n’est qu’ensuite qu’elle pouvait réclamer le fichier. La séquence semblait circulaire : comment recevoir une réponse de niveau réseau avant de disposer d’une identité réseau utilisable ?

Bill Croft et John Gilmore ont décrit ce problème dans la RFC 951, en septembre 1985. BOOTP n’était pas un protocole de transfert de fichiers. Il prenait en charge la première phase : déterminer l’adresse et choisir le fichier d’amorçage. Le programme en mémoire morte du client pouvait demander une adresse, un serveur et un nom de fichier ; après la réponse, une seconde phase — généralement TFTP — pouvait charger le fichier en mémoire. Le document envisageait un démarrage automatique, sans intervention humaine. Il décrivait une conception, pas un recensement des machines qui l’utilisaient. (RFC 951, §§2, 7.5.)

La requête n’avait pas besoin d’une adresse IP encore inconnue. Si le client et le serveur n’étaient pas déjà spécifiés, le client pouvait envoyer un paquet IP/UDP avec l’adresse source zéro vers 255.255.255.255, soit une diffusion sur le câble local. La requête contenait aussi le type et l’adresse matérielle du client, ainsi qu’un identifiant de transaction. Le serveur pouvait associer cette adresse matérielle à une adresse IP dans sa propre base, placer le résultat dans le champ yiaddr de la réponse et sélectionner un chemin complet vers le fichier d’amorçage. Une demande générique telle que unix pouvait ainsi aboutir à un fichier adapté à ce client. La fiche locale du serveur faisait donc partie du démarrage. (RFC 951, §§2–3, 7.1, 7.3 et 9.)

La première réponse avait son propre problème de l’œuf et de la poule. Normalement, un serveur a besoin d’ARP pour trouver l’adresse de liaison correspondant à une destination IP. Or le client ne connaissait pas encore son adresse et ne pouvait répondre à la requête ARP du serveur. La RFC 951 décrivait deux solutions. Une machine dotée des mécanismes nécessaires dans son noyau ou son pilote pouvait créer une entrée ARP temporaire à partir des adresses matérielle et IP proposées, avec une durée limitée. La RFC précisait que UNIX 4.2 BSD disposait de cette capacité. À défaut, le serveur pouvait diffuser la réponse sur l’interface du client. Le contournement dépendait donc des moyens locaux de la machine émettrice. (RFC 951, §4.)

Les deux ports UDP avaient eux aussi un rôle dans le retour de la réponse. Les requêtes arrivaient sur le port serveur BOOTP, 67 ; les réponses partaient vers le port client, 68. RFC 951 explique que deux ports permettaient au noyau d’écarter les réponses diffusées sur les machines qui n’écoutaient pas le port client, sans réveiller ni planifier les démons BOOTP des autres hôtes. Un port client choisi au hasard aurait aussi pu faire paraître la diffusion destinée à un autre processus en écoute. Ce détail ne relevait pas d’un simple rangement du protocole : il évitait qu’une réponse individuelle de démarrage devienne un événement applicatif pour tout le segment. (RFC 951, §3.)

Le serveur d’amorçage ne se trouvait pas toujours sur le câble local. RFC 951 rendait le démarrage à travers des passerelles facultatif et coopératif. Une passerelle, ou un autre agent, pouvait recevoir la diffusion, renseigner giaddr avec le réseau du client et transmettre la demande au serveur. Les auteurs déconseillaient les rediffusions globales, susceptibles de créer des boucles. En octobre 1993, RFC 1542 précisa cette frontière : un agent relais BOOTP n’était pas un simple routeur IP qui transmet un datagramme de façon transparente. Il pouvait recevoir le message BOOTP comme destination finale et en produire un nouveau. La fonction pouvait être hébergée sur un routeur ou sur une machine distincte reliée au sous-réseau du client. Le relais était un rôle configuré, doté de règles de traitement propres. (RFC 951, §8 ; RFC 1542, §§4–4.1.)

Il faut donc éviter de réduire BOOTP à un « ancien DHCP ». RFC 2131 décrit ensuite DHCP comme une extension du mécanisme BOOTP et conserve son format de message et son comportement de relais pour permettre l’interopérabilité. Elle souligne également une différence majeure : DHCP peut accorder un bail de durée finie et réutiliser une adresse lorsque le client n’en a plus besoin. Le modèle de 1985 de BOOTP recherchait plutôt l’adresse et le choix du fichier dans les enregistrements du serveur. DHCP conserve aussi l’attribution manuelle ; la différence n’est donc pas que toutes les adresses sont devenues temporaires, mais que l’allocation dynamique est entrée dans le protocole. (RFC 2131, §§1–2.)

Le rôle historique de BOOTP était modeste, mais nécessaire. Il ne rendait pas une machine sans disque autonome, n’authentifiait pas un utilisateur et ne transférait pas lui-même l’image du système. Il définissait comment une machine munie d’une adresse matérielle mais dépourvue d’identité IP utilisable pouvait demander les éléments suivants de son démarrage, comment un serveur pouvait les choisir et comment la réponse pouvait revenir avant le fonctionnement normal d’ARP. Dans ce cas, la connectivité commençait par une diffusion locale, une fiche explicite dans un serveur et une réponse acheminée par un mécanisme spécial.

Sources et limites

RFC 951 était une proposition de protocole : elle décrit un comportement prévu, pas l’ampleur de son déploiement. La mention d’une capacité de cache ARP dans 4.2 BSD ne prouve pas que toutes les implémentations la possédaient. RFC 1542 consigne des règles ultérieures de relais, sans établir leur application universelle. BOOTP choisissait des paramètres réseau et un nom de fichier ; le transfert du fichier était distinct. DHCP a introduit les baux dynamiques, tout en conservant l’allocation manuelle.