Résumé

  • L’option 52 annonce que les champs file ou sname servent à transporter des options DHCP. Leur nom historique ne suffit donc plus à déterminer leur contenu.
  • Le réassemblage suit l’ordre logique options, file, sname, différent de leur disposition physique. Chaque fragment conserve néanmoins son propre code, sa longueur et les limites de son champ.
  • Réutiliser de l’espace et découper une valeur sont deux opérations distinctes. Leur adoption exige des récepteurs capables de reconstruire le sens, pas seulement des émetteurs capables de remplir les cases.

La première case du paquet n’est pas la première à lire

Dans le format hérité de BOOTP, sname vient avant file, et ces deux champs précèdent la zone d’options. Un programme qui parcourt les octets dans leur ordre physique les rencontre donc ainsi. Mais cet ordre devient trompeur lorsqu’il faut reconstruire une option répartie entre plusieurs zones.

La règle commune impose de traiter d’abord les options ordinaires, puis file si son usage a été déclaré, puis sname s’il a lui aussi été sélectionné. Le déplacement est logique : les champs restent exactement à leur place dans le paquet.

RFC 3396, publié en novembre 2002, insiste sur cette différence en définissant un tampon agrégé d’options. Il ne demande pas de déplacer les champs sur le réseau. Il définit l’ordre dans lequel leurs contenus autorisés contribuent à un même objet.

Cette distinction permet de comprendre l’enjeu historique. Trouver quelques octets de plus dans un format ancien était relativement simple. Faire en sorte que des programmes indépendants les interprètent de la même manière exigeait un accord plus précis que « continuer là où il reste de la place ».

Des noms avaient d’abord occupé ces espaces

Le BOOTP de RFC 951, en septembre 1985, aidait une machine à obtenir les informations nécessaires à son démarrage avant de disposer de tout son environnement d’exploitation. Le paquet réservait 64 octets au nom facultatif du serveur, sname, et 128 au nom du fichier de démarrage, file. Les deux étaient des chaînes terminées par zéro.

Une zone vend de 64 octets accueillait des informations propres au fournisseur. Les emplacements fixes correspondaient donc à des besoins réels : trouver un serveur et un fichier n’était pas un détail décoratif du protocole de démarrage.

DHCP a repris cette structure en élargissant le service de configuration. RFC 2131, de mars 1997, conserve les dimensions des champs de noms mais rend la zone options variable. Les clients doivent pouvoir recevoir une zone d’options d’au moins 312 octets ; la négociation d’une taille de message supérieure constitue une autre possibilité.

Il faut donc distinguer la capacité du message, la place restante dans un champ et la longueur représentable par une occurrence d’option. Les 255 octets d’un champ de longueur à un octet ne décrivent pas la taille maximale de tout DHCP.

Une déclaration précède le changement de sens

La réutilisation des champs n’a pas attendu 2002. RFC 1533, d’octobre 1993, définissait déjà Option Overload. Son code est 52 et sa valeur tient dans un octet : 1 pour file, 2 pour sname, 3 pour les deux.

La déclaration concerne les champs indiqués dans le message présent. Elle ne permet pas de requalifier toute zone dont le contenu paraît étrange. Un champ non sélectionné ne rejoint pas automatiquement l’ensemble des options parce que l’autre manque de place.

RFC 2131 exige que l’option de surcharge apparaisse dans la zone options ordinaire. Le destinataire commence par celle-ci pour découvrir la déclaration, puis examine les champs désignés. Il n’a donc pas besoin de deviner la nouvelle fonction d’une case avant d’avoir le droit de la lire comme telle.

Cette position est essentielle à l’accord. L’émetteur choisit l’usage de l’espace, mais il doit l’annoncer dans un endroit que les deux parties savent déjà interpréter. Le choix local ne devient pas une surprise imposée au parseur distant.

Trois zones ne forment pas une seule bande physique

La zone ordinaire commence par un magic cookie de quatre octets, puis par les options. Une option habituelle contient un code, une longueur et les octets de données annoncés ; la longueur n’inclut pas les deux octets qui la précèdent. Pad et End sont des exceptions d’un seul octet.

Dans file ou sname réutilisé, les options commencent au premier octet du champ. On n’y ajoute pas un second cookie. Chaque zone employée doit contenir sa propre terminaison End, puis du remplissage Pad jusqu’à sa limite. Une occurrence encodée doit tenir intégralement dans un champ.

Le réemploi ne supprime donc pas les cloisons. Une option ne peut pas commencer dans une zone et déborder physiquement dans la suivante. Inversement, End dans une zone ne signifie pas que les autres zones déclarées doivent être ignorées. La fin d’un contenant et la fin d’une valeur logique ne sont pas la même frontière.

Les deux champs représentent ensemble 192 octets bruts, pas 192 octets de données supplémentaires garantis. Codes, longueurs, terminaisons, remplissage et éventuelles informations de démarrage déplacées occupent une partie de l’espace. Il s’agit d’une capacité limitée, non d’un agrandissement infini ou d’une variante de la fragmentation IP.

Le fichier peut quitter la case qui porte son nom

Le changement d’usage n’oblige pas à supprimer l’information ancienne. RFC 2132, en mars 1997, définit l’option 66 pour le nom du serveur TFTP lorsque sname sert aux options, et l’option 67 pour le nom du fichier de démarrage lorsque file est réutilisé.

La donnée peut ainsi passer d’un emplacement dédié à une représentation étiquetée. Un outil qui ne cherche qu’une chaîne lisible dans file risque de conclure à une absence alors que le nom se trouve ailleurs. Le champ historique n’est plus l’unique emplacement de la signification qu’il portait.

Le registre BOOTP/DHCP de l’IANA conserve ces codes et celui de l’option Domain Search, 119. Il s’agit de codes d’options, non de ports. Le fait que 67 soit aussi un numéro de port UDP utilisé par DHCP ne transforme pas l’option 67 en indication de transport.

Le registre fournit un vocabulaire commun. Il ne prouve ni l’activation d’une fonction dans une machine donnée, ni l’existence du fichier nommé, ni la réussite d’un téléchargement. Déplacer un nom n’exécute pas le démarrage qu’il doit aider à préparer.

Le manque de place a deux formes

Une valeur peut dépasser 255 octets, au-delà de ce qu’une longueur sur un octet peut annoncer. Elle peut aussi être beaucoup plus courte et ne pas tenir dans le reste d’un champ pourtant presque plein. L’existence d’un autre champ disponible ne suffit pas à expliquer comment la couper.

RFC 3396, de Ted Lemon et Stuart Cheshire, traite les deux cas. Il clarifie aussi un texte antérieur qui limitait par défaut les occurrences d’une option tout en évoquant leur concaténation : la phrase restrictive de RFC 2131 est explicitement supprimée.

Chaque portion reçoit le même code d’option et sa propre longueur. Les longueurs des données s’additionnent pour former la valeur complète. Le destinataire assemble les données, sans y inclure les codes et les longueurs, et ne doit pas traiter les morceaux comme des objets distincts.

L’exemple du fichier /diskless/foo est instructif. Ses treize octets peuvent être répartis en sept et six, avec une coupure au milieu de diskless. Aucun sens particulier n’est attaché à cette coupure. Elle n’annonce ni deux fichiers ni deux composantes de chemin. Le texte complet n’existe comme paramètre qu’après réunion des morceaux.

La surcharge et la concaténation restent indépendantes : un champ emprunté peut accueillir des options entières, tandis que plusieurs portions d’une longue valeur peuvent tenir dans la zone ordinaire sans emprunter file ou sname. Confondre les mécanismes masque leurs contraintes respectives.

L’ancien programme ne change pas à la publication du RFC

La spécification de 2002 signalait que de nombreux agents DHCP déjà déployés ne savaient pas concaténer les options. Elle recommandait donc de ne pas les découper sans nécessité ou sans savoir que le destinataire pouvait les réunir correctement.

Cette connaissance pouvait venir d’une option fournie ou demandée dont la définition exigeait la concaténation, ou d’une hypothèse explicitement configurée par l’administrateur. Ce n’était pas un nouveau bit universel de négociation. Ce constat historique ne constitue pas non plus une mesure de l’équipement actuel.

Un émetteur pouvait choisir de ne découper que les options qui l’exigeaient. Mais une implémentation prenant en charge une telle option devait aussi pouvoir réunir les portions reçues pour les autres options. La simplicité de ce que l’on produit ne réduit pas automatiquement le langage que l’on doit comprendre.

Cette asymétrie est une responsabilité concrète de compatibilité. L’émetteur maîtrise son choix de rangement ; il ne maîtrise pas les anciennes habitudes de tous les destinataires. Le décodeur doit appliquer la règle commune plutôt que décider que la première ou la dernière occurrence suffit.

Un exemple où l’assemblage crée le repère

RFC 3397, également publié en novembre 2002, définit l’option 119 pour la liste de recherche de domaines DNS. La liste peut occuper plusieurs occurrences et emploie une compression des noms pour économiser les suffixes répétés.

Les pointeurs se rapportent aux données complètes une fois concaténées. Ils ne partent ni du début du paquet DHCP ni du début de chaque portion, et les octets de code et de longueur ne font pas partie de ce repère.

Il faut donc reconstruire avant d’interpréter. Une portion peut s’arrêter à l’intérieur d’une étiquette ; ce n’est pas encore un nom complet auquel on pourrait appliquer isolément les règles de terminaison. La frontière pertinente se trouve dans l’objet logique reconstitué.

Ce cas suffit ici sans reprendre toute l’histoire de la compression DNS. Il montre qu’un niveau de syntaxe dépend du travail accompli par le niveau inférieur. Une concaténation dans le mauvais ordre peut modifier le sens même si chaque longueur locale paraît plausible.

La reconstruction correcte ne donne pas non plus une autorité de configuration. RFC 3397 rappelle qu’une liste de recherche peut conduire un nom court vers un autre domaine complet, même si les données de cet autre domaine sont signées validement. Le protocole de rangement ne décide pas à la place de l’hôte qui peut influencer ce choix.

DHCP a ainsi agrandi ses possibilités sans abolir ses anciennes frontières. Une déclaration connue et un ordre déterministe ont permis aux mêmes positions de porter autre chose, sans obliger le lecteur à deviner ce que l’émetteur avait voulu faire.