Résumé

  • Le RFC 906 proposait TFTP sur IP pour charger le premier code d’une machine sans disque, alors que les installations devaient souvent maintenir plusieurs mécanismes et serveurs propres aux constructeurs.
  • Dans l’exemple publié par Ross Finlayson pour une station Motorola 68000 sur Ethernet, une erreur d’un serveur n’arrêtait pas la recherche : la première trame DATA valide fixait le partenaire du transfert. Le code ROM faisait moins de 4 Ko hors pilote Ethernet ; cela décrit une implémentation, pas une adoption générale.

Une station pouvait parler les mêmes protocoles Internet que ses voisines une fois démarrée, tout en ayant besoin d’un chemin particulier pour atteindre cet état. Son système d’exploitation n’était pas encore là pour demander le fichier. Un programme conservé en mémoire morte devait d’abord établir assez de réseau pour récupérer le code suivant.

Le RFC 906, publié en juin 1984 par Ross Finlayson, décrit le coût pratique de cette frontière. Les constructeurs employaient des méthodes différentes pour charger les premiers fichiers. Une organisation qui exploitait plusieurs types de machines pouvait donc devoir faire tourner plusieurs implémentations de serveurs d’amorçage, même si les ordinateurs communiquaient librement après leur lancement. Le RFC proposait un protocole commun pour ce premier transfert : TFTP transporté par IP. Son statut est sans ambiguïté : il s’agit d’une proposition destinée à la communauté ARPA Internet, qui sollicite des remarques et des améliorations.

Le choix de TFTP était volontairement limité. Le programme envoyait une requête de lecture portant un nom de fichier, recevait des paquets DATA, puis retournait des acquittements ou des erreurs. Le RFC jugeait acceptable la lenteur du transfert initial : un deuxième chargeur pouvait employer un protocole plus rapide. Le client devait recevoir des datagrammes IP pouvant atteindre 524 octets, hors en-tête IP : jusqu’à 516 octets pour un paquet TFTP DATA et 8 octets pour l’en-tête UDP. La machine en démarrage n’avait pas à répondre aux requêtes TFTP de lecture ou d’écriture entrantes.

Il s’agissait d’un client de récupération de code, pas d’un serveur de fichiers généraliste.

Le texte ne normalisait pas toute l’expérience de démarrage. Il spécifiait les protocoles réseau, pas la manière dont l’utilisateur lançait la machine ni la commande qu’il saisissait sur la console. Il ne supposait pas non plus Ethernet : le mécanisme de liaison restait libre. Un échange commun pouvait donc coexister avec des procédures locales différentes pour démarrer et choisir un fichier.

L’exemple donne un contour concret à cette idée. Finlayson décrit un programme en ROM pour une station Motorola 68000 reliée par Ethernet. L’utilisateur saisissait un nom de fichier et pouvait fournir l’adresse Internet de la station et celle du serveur. Sans adresse de serveur, plusieurs serveurs TFTP pouvaient recevoir la requête. L’enjeu n’était alors pas seulement qu’un serveur réponde, mais de savoir quelle réponse changeait l’état du client.

La règle est précise. Une erreur TFTP venant d’un serveur ne faisait pas abandonner le client, puisqu’un autre serveur pouvait encore transmettre le fichier demandé. Le premier paquet DATA valide établissait les adresses Internet et Ethernet auxquelles seraient envoyés les acquittements suivants. Si un autre serveur envoyait ensuite des données, le client lui retournait une erreur. Une requête pouvait donc être entendue par plusieurs machines, mais une seule devenait le partenaire du transfert.

Cette règle peut ressembler à une authentification ; elle n’en est pas une. La révision 2 de TFTP dit que le protocole ne prévoit pas d’authentification de l’utilisateur. La règle du RFC 906 sélectionne un répondant, sans prouver qu’il s’agit du serveur souhaité ni que le fichier d’amorçage possède une origine vérifiée indépendamment. Les sources ne rapportent ni attaque ni incident de déploiement. Elles montrent où la proposition plaçait la décision : dans le traitement des réponses par le client et dans l’environnement local qui déterminait quels serveurs pouvaient répondre.

Le chiffre de taille du code est tout aussi circonscrit. L’implémentation décrite occupait moins de 4 Ko, sans compter le pilote du périphérique Ethernet. Cela prouve qu’un auteur avait intégré ce client dans une ROM contrainte ; ce n’est ni une mesure valable pour tous les processeurs, ni un décompte d’installations, ni la preuve que les méthodes des constructeurs avaient disparu.

Des textes ultérieurs éclairent l’architecture sans démontrer une filiation de déploiement. Le RFC 951 de 1985 décrit BOOTP comme une première phase de détermination de l’adresse et de sélection du fichier ; le transfert qui suit emploie généralement TFTP. En 1989, le RFC 1123 décrit deux étapes pour l’amorçage sans disque : configurer IP, puis charger le code système, au moyen d’un programme en ROM. Ces textes précisent la séparation entre préparation et transfert. Ils ne transforment pas l’unique implémentation citée dans le RFC 906 en statistique d’adoption.

L’intérêt historique du RFC 906 tient donc à une frontière, pas à un triomphe. Un petit programme en ROM pouvait demander le fichier suivant au moyen d’IP, tandis que le lancement de la machine et une partie du choix du serveur restaient locaux. La première réponse DATA valide donnait un point net où un répondant devenait le partenaire du transfert. Le protocole restait petit, mais l’exploitant devait encore savoir quelle source de code répondrait la première.

La Note 65 ultérieure de Heng Lu fournit ici une discipline de lecture, non une preuve sur les intentions de Finlayson : un texte publié et une implémentation rapportée sont des éléments différents du déploiement et de l’usage. Les éléments disponibles établissent une proposition et un exemple ; ils ne disent pas combien de sites l’ont adoptée ni si elle a supprimé le coût de support décrit.

Sources