Résumé

  • RFC 1048 place 99.130.83.99 au début du champ fournisseur de BOOTP. Ces quatre octets choisissent une grammaire où chaque option ordinaire annonce son tag, sa longueur et sa valeur, de sorte qu'une option inconnue puisse être sautée.
  • Cette lisibilité n'est pas une preuve d'origine. La limite de 64 octets, les codes Pad et End et l'enregistrement des tags rendent le message interopérable ; l'exactitude, l'actualité et l'autorisation des valeurs restent des décisions distinctes.

Le client BOOTP de RFC 951 commence dans un état d'ignorance organisé. Il peut connaître son adresse matérielle et exécuter un programme minimal, sans connaître sa propre adresse IP, le serveur utile ni le fichier à charger. Le protocole doit d'abord fournir assez d'informations pour que la seconde phase—le transfert du fichier—devienne possible.

Le paquet ménageait un champ vend de 64 octets. L'espace permettait à un constructeur d'ajouter des paramètres, mais son nom révélait la difficulté : deux clients pouvaient recevoir les mêmes bits et leur donner des sens incompatibles. RFC 951 recommandait déjà un nombre magique de quatre octets pour signaler le type de données. Il manquait encore une syntaxe commune à la suite.

RFC 1048 n'a pas demandé un nouveau paquet. Il a discipliné l'ancien espace. Le choix est historique précisément parce qu'il est modeste : rendre l'extension reconnaissable, navigable et limitée, tout en refusant d'attribuer au format une autorité qu'il ne pouvait pas posséder.

Une signature de format, sans signature cryptographique

Le cookie vaut 99.130.83.99, soit 63.82.53.63 en hexadécimal, transmis dans l'ordre réseau. Le texte de RFC 1048 lui confie une tâche : identifier le mode d'interprétation des données suivantes.

Un programme qui le reconnaît sait donc appliquer la grammaire RFC 1048. Il ne sait pas encore quel acteur a composé la réponse. Les quatre octets sont publics et constants. Ils ne prouvent pas l'identité du serveur, ne garantissent pas qu'un relais a conservé le message et ne certifient pas qu'une passerelle annoncée appartient à l'administrateur légitime.

Le numéro de transaction, les adresses et l'adresse matérielle de BOOTP apportent d'autres corrélations. Ils servent à rattacher une réponse à une tentative en cours et à livrer le paquet. Il serait pourtant faux de les additionner pour fabriquer une authentification qui n'existe pas dans la spécification.

RFC 1542 a ensuite formulé le risque sans détour : BOOTP est dépourvu d'un mécanisme d'authentification raisonnable, et un serveur non autorisé peut fournir de fausses adresses de client, de routeur ou de DNS. La grammaire peut être impeccable au moment même où le contenu détourne la machine.

La longueur contient les effets de l'inconnu

Après le cookie, une option ordinaire comporte un octet de tag, un octet de longueur et autant d'octets de valeur que l'annonce cette longueur. Celle-ci ne compte ni le tag ni son propre octet. Les nombres sur plusieurs octets emploient l'ordre réseau.

La longueur transforme l'inconnu en portion bornée. Si le client comprend le tag, il lit la valeur selon la définition correspondante. S'il ne le comprend pas, il avance jusqu'au prochain sous-champ sans devoir interpréter la valeur. Une extension future ne condamne donc pas un ancien programme à perdre le reste du message.

Cette propriété explique la longévité de la forme, mais elle ne doit pas être exagérée. Sauter une option est une capacité de cadrage, non un jugement sur son sens. Un tag local peut rester opaque hors du site qui l'a défini. Un tag connu peut porter une adresse périmée. Une longueur cohérente ne garantit pas que l'implémentation gère correctement tous les cas limites.

RFC 1084 puis RFC 1497 ont fait évoluer le catalogue en conservant cookie, tags et longueurs. Cette continuité montre que la frontière d'extension était utile. Elle ne montre pas que chaque option était comprise ou déployée partout.

Deux codes indiquent comment ne pas continuer

Pad, tag 0, tient sur un seul octet. End, tag 255, également. Aucun des deux n'est suivi d'un octet de longueur. Pad sert à l'alignement ou à l'espace inutilisé ; End ferme la séquence, puis le reste du champ est rempli de zéros.

Ce sont des commandes de lecture. Chercher une longueur après Pad décalerait tout le parseur. Traiter les zéros après End comme de nouvelles options inventerait des paramètres qui n'ont jamais été envoyés. Une syntaxe extensible dépend autant de sa règle d'arrêt que de son mécanisme d'ajout.

L'ordre peut aussi porter une nécessité. Quand le masque de sous-réseau et une passerelle sont présents, RFC 1048 impose que le masque vienne d'abord. Le client en a besoin pour raisonner correctement sur les destinations locales. La liste n'est donc pas toujours un ensemble commutatif ; la possibilité de localiser chaque champ ne supprime pas les dépendances entre eux.

Le plafond fixe oblige à établir des priorités

Le cookie utilise déjà quatre octets sur 64. Une option ordinaire dépense deux octets de structure avant sa valeur. Une adresse IPv4 en demande quatre de plus ; une liste en multiplie le coût. RFC 1048 interdit de dépasser la taille de vend et conseille d'écarter les informations non essentielles pour les chercher par un autre service.

Cette économie de place produit une économie de codes. Les champs génériques devaient être enregistrés afin que deux usages publics ne revendiquent pas le même numéro. Les valeurs 128 à 254 restaient propres au site. Elles autorisaient l'expérimentation locale, mais leur signification dépendait de l'accord local. Le format commun n'universalisait pas le contenu privé.

Il fallait encore décider quelles données méritaient le premier échange. Le registre ne choisissait pas la politique du serveur. L'administrateur alimentait la base BOOTP ; le client décidait des options qu'il utilisait ; d'autres services prenaient en charge ce qui ne rentrait pas. Le plafond rendait les responsabilités visibles, sans les centraliser toutes.

La contrainte a aussi créé une inertie. Une fois des programmes de démarrage et des serveurs construits autour de la même enveloppe, ajouter une définition coûtait moins cher que changer de syntaxe. L'extensibilité facilite l'évolution interne, mais peut rendre la frontière externe durablement coûteuse à remplacer.

Une table centrale n'est pas une racine de confiance

RFC 1048 compare la base administrée de BOOTP à des méthodes de découverte plus distribuées. Une réponse unique contenant tous les paramètres utiles est efficace. Le client évite plusieurs échanges et peut passer rapidement au chargement. Le document reconnaît en même temps que la table centrale peut être incomplète ou périmée.

Contrôler cette table donne le pouvoir de publier la configuration BOOTP locale. Ce pouvoir ne prouve pas l'identité du serveur de fichiers indiqué. RFC 1048 explique que la base BOOTP ne suffit pas à une authentification forte du service de fichiers : celle-ci appartient au protocole et au service concernés.

La chaîne comporte donc plusieurs faits : le message suit une grammaire reconnue ; il ressemble à la réponse d'une transaction ; un chemin serveur a fourni les valeurs ; le service ultérieur authentifie ou refuse l'opération. Le cookie ne peut absorber aucune de ces étapes. Il ne connaît que la première.

RFC 1542 recommande même qu'un client sans option à envoyer place quand même le cookie, puis End et le remplissage nul. Le serveur apprend ainsi le format de réponse attendu. C'est une négociation de représentation à contenu presque vide—la preuve la plus claire que le cookie n'est pas un secret d'autorisation.

DHCP a reçu la forme, pas une garantie

RFC 1533 emploie pour les options DHCP le même format issu des extensions BOOTP : tag, longueur, valeur, sauf Pad et End. Le cookie et la plage locale sont conservés. RFC 2132 documente ensuite un catalogue DHCP plus mûr dans cette lignée.

Cette filiation est explicite au niveau du format. Elle ne signifie pas que toutes les pratiques DHCP existaient en 1988, que toutes les options avaient gardé leur sens, ni que le passage à DHCP avait authentifié le canal. RFC 1533 dit d'ailleurs que les questions de sécurité n'y sont pas traitées.

L'apport de RFC 1048 reste plus précis et plus solide. Des machines différentes ont reçu une règle commune pour identifier une langue, parcourir les champs connus, ignorer proprement une nouveauté et terminer la lecture dans une enveloppe minuscule. L'identité du locuteur, la fraîcheur de sa base et le droit d'exécuter la configuration sont restés hors de cette règle.

Sources et limites de preuve

RFC 951 décrit le paquet original, le champ fournisseur et le premier usage d'un nombre magique. RFC 1048 fournit le cookie, la grammaire, les règles d'ordre, d'allocation et de taille. RFC 1084 et RFC 1497 attestent les révisions BOOTP. RFC 1533, RFC 1542 et RFC 2132 documentent le passage du format aux options DHCP et la limite de sécurité.

Ces textes prouvent des règles publiées et une succession documentaire. Ils ne mesurent pas la part de déploiement, ne décrivent pas la configuration d'un réseau particulier et ne prouvent pas que toute implémentation historique sautait correctement les tags inconnus.