Résumé

  • RFC 3396 faisait des occurrences répétées d’un même code DHCPv4 les fragments successifs d’une valeur logique, qu’ils aient été imposés par la limite de 255 octets ou par le manque de place dans un champ.
  • La reconstitution suivait l’ordre logique options, file, sname, différent de la disposition physique. La coupure n’avait aucun sens propre et un envoi conforme ne prouvait pas qu’un pair déployé savait recoller les pièces.

Une option DHCP semblait posséder une adresse dans le paquet. En réalité, elle pouvait en avoir trois. Son premier morceau pouvait apparaître dans la zone habituelle, le deuxième dans file, le troisième dans sname. Pour retrouver la valeur, lire les octets selon leur simple position physique ne suffisait pas.

RFC 3396 fut publié en novembre 2002 sur la voie de normalisation. La difficulté venait d’un octet : la longueur d’une option variable ne pouvait annoncer que zéro à 255 octets de valeur. Or certains objets de configuration dépassaient cette capacité. Le protocole savait répéter un code ; il lui manquait une règle complète pour ordonner les répétitions.

RFC 2131 indiquait déjà qu’il fallait les concaténer, tout en conservant une phrase générale selon laquelle une option ne pouvait apparaître qu’une fois sauf indication contraire. RFC 3396 supprima cette phrase. Deux occurrences du même code n’étaient plus, par défaut, deux objets autonomes : elles devenaient des morceaux à réunir avant traitement.

La longueur n’était pas le seul motif. Une option inférieure à 255 octets pouvait ne plus tenir dans l’espace restant d’une zone, alors qu’une autre zone du paquet disposait encore de place. L’agent encodeur devait alors appliquer l’algorithme de découpage ou ne pas transmettre l’option. Une occurrence encodée ne pouvait pas traverser une frontière de champ.

Cette pluralité venait de l’héritage BOOTP. DHCP utilisait naturellement la zone des paramètres optionnels, mais l’option de surcharge autorisait aussi les champs fixes file et sname à recevoir des options. Le RFC les rassembla dans un tampon agrégé conceptuel, ordonné ainsi : paramètres optionnels, puis file, puis sname.

Le texte ajoutait un avertissement essentiel : cet ordre n’était pas l’ordre physique des champs dans le paquet. Le tampon agrégé ne modifiait pas le format sur le fil. Il décrivait la séquence que l’encodeur devait respecter et que le décodeur devait reconstruire. Parcourir naïvement la mémoire produisait potentiellement une autre valeur.

Chaque fragment restait une option variable normale, avec le même code et au plus 255 octets de données. Les longueurs de tous les fragments devaient donner la longueur totale. Dans le tampon logique, le premier précédait le deuxième, puis le troisième, même lorsque leurs champs physiques semblaient raconter autre chose.

La coupure pouvait tomber entre deux octets quelconques. Cette liberté interdisait d’y attacher une signification. Elle ne marquait ni fin de nom, ni route, ni sous-option, ni enregistrement. Elle signalait seulement la limite d’un conteneur ou d’un espace disponible.

Le décodeur devait donc attendre. Lorsqu’il trouvait plusieurs occurrences d’un code, il les ordonnait selon le tampon agrégé, concaténait leurs valeurs et obtenait une seule option. Interpréter ou valider chaque pièce séparément revenait à inventer une grammaire que l’émetteur n’avait jamais exprimée.

L’alignement mémoire relevait également du récepteur. L’encodeur n’était pas obligé de couper selon les préférences du processeur distant. Après reconstitution, l’implémentation devait copier ou lire la valeur sans faire d’hypothèse d’alignement dangereuse.

L’exemple du nom de fichier de démarrage rendait la règle tangible. La chaîne /diskless/foo, pourtant courte, pouvait être divisée en deux occurrences du code 67 pour s’adapter au tampon. Aucun fragment n’était un nom de fichier valable par lui-même ; seul leur raccord dans l’ordre donnait l’objet.

Le point historique le plus révélateur était l’aveu de compatibilité. Beaucoup d’agents DHCP déjà déployés n’implémentaient pas la concaténation. Un émetteur conforme pouvait donc rencontrer un récepteur qui ignorait une pièce, la traitait comme une option indépendante ou rejetait l’ensemble. La correction de l’écriture ne démontrait pas la correction de la lecture.

Le RFC distingua alors les options qui exigeaient la concaténation de celles qui ne l’exigeaient pas. Pour appartenir à la première catégorie, la spécification de l’option devait citer explicitement RFC 3396 et imposer le mécanisme. L’émetteur devait éviter de découper sauf nécessité, capacité connue du pair ou configuration administrative explicite.

Demander ou fournir au moins une option de la catégorie obligatoire permettait de présumer que le pair savait concaténer. Cette présomption restait étroite : elle n’attestait ni tous les chemins du parseur, ni toutes les tailles, ni la consommation finale. Une implémentation pouvait ne jamais découper les options ordinaires ; si elle prenait en charge une option obligatoire, elle devait néanmoins savoir réunir à la réception les répétitions des deux catégories.

La note sur l’authentification montrait que l’objet logique précédait même certains calculs de sécurité. L’option de RFC 3118 pouvait elle aussi être fragmentée. Pour générer ou vérifier le MAC, le code devait mettre à zéro le champ d’authentification même s’il traversait plusieurs occurrences. Hacher les conteneurs au lieu de l’objet reconstitué changeait la preuve.

RFC 3397 pour la recherche de domaines, RFC 3361 pour les mandataires SIP, RFC 3442 pour les routes sans classe et RFC 3925 pour l’identification fournisseur ont ensuite utilisé ce socle selon leurs propres grammaires. Leurs contenus différaient ; l’acte préalable demeurait identique : retrouver une valeur unique avant de la lire.

Une capture complète a donc une portée limitée. Elle peut montrer tous les fragments au point observé. Elle ne montre pas que le client a reconnu la surcharge, appliqué l’ordre agrégé, conservé les répétitions, géré l’alignement, vérifié l’authentification et installé la configuration. Ces reçus appartiennent à des couches successives.

La recherche actuelle d’errata du RFC Editor ne retourne aucun erratum pour RFC 3396. Cette donnée décrit le document publié, non la qualité des parseurs. Le RFC lui-même existait précisément parce qu’une phrase ancienne et des logiciels déjà diffusés ne produisaient pas une réalité uniforme.

Le principe de spécification initiale minimale de Lu Heng éclaire la solution : fixer l’identité par le code, l’ordre logique, la continuité et l’absence de sens des coupures, sans imposer la structure mémoire interne de chaque agent. La primauté du code en fonctionnement exige ensuite des essais où les coupures sont gênantes et les trois champs réellement utilisés.

RFC 3396 apprit au protocole à ne pas confondre emplacement et identité. Les pièces pouvaient être éloignées et inégales ; le paquet pouvait les présenter dans un autre ordre physique. Avant de leur demander ce qu’elles signifiaient, il fallait leur rendre leur unité.

Sources