Summary

  • En 1985, BOOTP permettait à un client sans disque de demander une adresse et les instructions de chargement d’un fichier avant de pouvoir envoyer une requête IP ordinaire à un serveur. Un relais pouvait transporter l’échange au-delà du réseau local.
  • giaddr décrivait le chemin de relais propre à BOOTP. RFC 1542 a précisé qu’il ne désignait pas le routeur IP général ni la route par défaut du client.

La machine a besoin d’aide avant de pouvoir la demander

Un poste sans disque, à sa mise sous tension, devait résoudre un problème circulaire : il lui fallait une adresse Internet pour utiliser IP, mais il avait besoin du réseau pour apprendre quelle adresse employer. Il devait aussi trouver le serveur et le fichier qui poursuivraient son démarrage. Si le serveur se trouvait sur un autre réseau, une diffusion locale ne pouvait pas traverser seule les routeurs ordinaires.

RFC 951, publié en septembre 1985, décrit BOOTP comme la première phase de cette procédure : déterminer l’adresse et choisir le fichier d’amorçage. Le client envoyait une requête avec son adresse matérielle et son adresse IP, s’il la connaissait. Si ciaddr valait zéro, le serveur pouvait rechercher l’adresse matérielle dans sa base et inscrire l’adresse du client dans yiaddr. D’autres champs indiquaient le serveur et le fichier. La requête et la réponse passaient par UDP, sur les ports 67 et 68.

Cette réponse ne chargeait pas le système. RFC 951 séparait explicitement le choix de l’adresse et du fichier de leur transfert, généralement par TFTP. RFC 906 avait déjà décrit ce chargement réseau en 1984. Une réponse BOOTP pouvait nommer un fichier sans prouver que le client avait joint le serveur, reçu tout le contenu ou achevé son démarrage.

Diffusion locale, relais vers un service distant

Le client non configuré n’avait pas à connaître un nom de serveur par DNS ni à posséder déjà une route distante. Il pouvait diffuser sa requête sur le câble local. Si le serveur se trouvait ailleurs, une passerelle ou un agent de transfert pouvait acheminer la requête BOOTP vers lui, puis rapporter la réponse. RFC 951 rendait cette fonction interréseau facultative : elle exigeait du code supplémentaire dans les passerelles et les serveurs, mais pas d’action particulière du client.

Le paquet comprenait giaddr, décrit en 1985 comme une adresse IP de passerelle. Dans la procédure de transfert, la première passerelle pouvait remplir ce champ s’il était vide et incrémenter hops. Si giaddr n’était pas nul, le serveur pouvait adresser sa réponse BOOTP à cette valeur, sur le port serveur, afin qu’un relais la remette sur le réseau du client. Ce champ reliait donc une machine en cours de démarrage à un service situé ailleurs.

Cela ne définissait pas la route que le poste utiliserait ensuite. La rédaction de RFC 951 laissait une ambiguïté : un passage indiquait que les paquets pouvaient être transférés par giaddr « pour atteindre le serveur ». Or le transfert du fichier et le routage IP ordinaire du client étaient deux fonctions distinctes. Le mot « passerelle » ne suffisait pas à les confondre.

La clarification de 1993

RFC 1542 a traité directement cette ambiguïté. La spécification précédente ne définissait pas clairement le comportement des agents de transfert. Le terme « agent relais » a été retenu pour distinguer cette fonction du transfert IP ordinaire : le relais reçoit un message BOOTP comme destinataire et en produit un autre. Il ne se contente pas de laisser passer un datagramme intact. La fonction pouvait être placée dans un routeur, mais aussi sur un hôte relié au réseau du client.

RFC 1542 précise que giaddr sert à transporter les BOOTREQUEST vers des serveurs situés sur d’autres réseaux, puis les BOOTREPLY en sens inverse par les relais. Il ne représente pas un routeur IP général pour le client, qui ne doit pas l’interpréter ainsi. Pour joindre un serveur TFTP distant, l’hôte a toujours besoin d’une adresse de premier routeur obtenue séparément, par une autre option de configuration ou un mécanisme de découverte.

La clarification n’a pas supprimé la conception de 1985 ; elle en a rendu la limite plus nette. Le relais résolvait un problème propre au service d’amorçage, avant que la configuration IP du client soit complète. Il ne configurait pas tout le trafic ultérieur.

Ce que permettait le démarrage centralisé

Un relais pouvait laisser le serveur d’amorçage, ses correspondances entre adresses matérielles et IP, ainsi que ses fichiers, hors du câble local. Cela pouvait éviter d’installer un serveur sur chaque segment et offrir un point central de gestion. C’est une conséquence architecturale des RFC, pas une mesure de l’adoption ou des coûts réels.

La chaîne gardait plusieurs dépendances : le lien local, le relais, sa destination configurée, l’enregistrement du client sur le serveur, le fichier, puis la route du client et le transfert TFTP. La réception d’une réponse BOOTP ne prouve aucune des étapes suivantes. L’adresse du relais n’identifie pas non plus une personne, une autorisation ou la route par défaut du client.

DHCP a ensuite repris le comportement des relais tout en ajoutant des modes d’allocation, dont les baux à durée limitée. Cela ne doit pas confondre l’échange d’amorçage BOOTP, le cycle de bail DHCP, le transfert TFTP et le routage IP ordinaire. Un même démarrage peut dépendre des quatre, chacun avec son état et ses propres preuves.

L’histoire tient dans un champ de quatre lettres. giaddr permettait à un message de franchir une frontière alors que l’hôte apprenait encore à participer à IP. Son nom ne faisait pas de lui la passerelle de l’hôte. Dans l’infrastructure Internet, le chemin de retour d’un message de contrôle, le prochain saut du client, l’adresse du serveur de fichiers et la réussite du service sont des faits liés, mais distincts.

Sources