Résumé

  • RFC 3925 a donné à DHCPv4 un format permettant de transporter les données de plusieurs fournisseurs dans un même message.
  • Les numéros d’options externes sont enregistrés, mais chaque fournisseur garde la maîtrise des sous-codes et de leur sens ; un PEN désigne un espace, il n’authentifie pas une déclaration.

Pendant une décennie, le chemin courant des informations propres aux fournisseurs dans DHCPv4 avait une forme étroite. L’option 60 de RFC 2132 permettait au client d’envoyer une chaîne de classe de fournisseur ; l’option 43 transportait un objet opaque, défini par un fournisseur. Le serveur interprétait l’option 43 dans le contexte indiqué par l’option 60. Cette structure convenait lorsque le vocabulaire d’un seul fournisseur suffisait. Elle devenait ambiguë lorsqu’un appareil ou un profil industriel devait inclure des informations indépendamment définies par plusieurs fournisseurs.

RFC 3925 décrit un problème de cadrage, pas une défaillance de l’attribution d’adresses DHCP.

Sa réponse est une nouvelle paire d’options. L’option 124, Vendor-Identifying Vendor Class, et l’option 125, Vendor-Identifying Vendor-Specific Information, placent un numéro d’entreprise privé IANA auprès des données de chaque fournisseur. L’option 125 peut contenir plusieurs entrées : un numéro d’entreprise, une longueur et les octets de ce fournisseur. La longueur délimite chaque charge utile ; le numéro indique quelle interprétation s’applique. RFC 3925 laisse expressément intactes les anciennes options 60 et 43 : une implémentation peut donc rencontrer à la fois les formes historiques et les formes identifiantes.

Cette structure marque une distinction importante. IANA attribue le code d’option DHCP externe. Son registre des numéros d’entreprise attribue le numéro qui désigne l’espace d’un fournisseur. Aucun de ces registres ne définit le sens de la charge utile. À l’intérieur, les sous-options suivent un format code/longueur/valeur, mais RFC 3925 précise que leurs codes sont définis par le fournisseur et ne sont pas gérés par IANA. La norme a créé un moyen de maintenir plusieurs dialectes séparés, pas un dictionnaire commun pour les traduire.

Le paquet a aussi une limite de taille. Comme les données cumulées peuvent dépasser la longueur maximale d’une option, RFC 3925 rend les options 124 et 125 sujettes à la concaténation selon RFC 3396. Le récepteur réunit les fragments répétés en une option logique avant d’en interpréter les entrées. Il ne doit pas prendre chaque fragment pour un nouvel enregistrement fournisseur. La norme recommande qu’un même numéro d’entreprise n’apparaisse qu’une fois ; en cas de répétition, le comportement n’est pas défini. Le cadre accepte la multiplicité, sans donner un sens à toutes les combinaisons mal formées ou répétées.

RFC 3925 reprend le modèle des options de classe et d’informations propres aux fournisseurs de DHCPv6, définies auparavant par RFC 3315. C’est une réutilisation de conception documentée, pas la preuve que les deux familles partagent le sens de leurs charges utiles ou leurs déploiements. L’extension n’authentifie pas non plus le fournisseur. RFC 3925 n’ajoute aucune sécurité ; RFC 3118 décrit un mécanisme d’authentification DHCP distinct, utilisable lorsqu’une telle authenticité est requise. Un numéro présent dans une option sert de sélecteur, pas de signature.

RFC 3925 compte ainsi dans l’histoire : il a rendu les frontières explicites pour permettre la coexistence, tout en laissant le sens local. Le registre externe aide à analyser un conteneur et à désigner son espace. Il ne dit pas au client ce que fera un octet propre à un fournisseur, si l’appareil appartient réellement à ce fournisseur, ni si une implémentation prend en charge l’option. Ces faits exigent d’autres preuves. Les RFC et les registres IANA établissent la conception et les attributions ; ils ne mesurent ni l’adoption, ni l’interopérabilité, ni les résultats opérationnels.

Sources