Résumé

  • Les options 60, 61, 55 et 43 distinguent respectivement indice de classe, clé de liaison d'adresse, paramètres demandés et données propres à un fournisseur.
  • Observer ces octets atteste un échange à un point de capture, non l'origine matérielle, une authentification ou l'installation effective des paramètres sur l'hôte.

Un serveur reçoit une requête DHCP. Il peut y trouver un nom de classe qui semble désigner un fabricant, un identifiant client qui paraît stable et une liste ordonnée de services recherchés. Un inventaire pressé en ferait une fiche d'équipement. Or le texte de 1997 distribue ces champs entre plusieurs décisions. La différence n'est pas une subtilité académique : elle détermine ce que le paquet permet réellement de savoir.

Publié en mars 1997 par Steve Alexander et Ralph Droms, le RFC 2132 définit les options DHCP et les extensions fournisseur de BOOTP. La plupart des options commencent par un code, une longueur et les octets correspondants ; Pad et End sont des exceptions. Dans BOOTP, un « magic cookie » de quatre octets indique la grammaire de ce qui suit. Ce cadre permet au parseur de trouver des limites. Il ne garantit pas la véracité de la donnée qu'il délimite. Le RFC 1048 avait fixé une grammaire antérieure de ces extensions ; notre question porte ici sur la sémantique des choix ajoutés dans le paquet DHCP.

L'option 60 est une chaîne facultative fournie par le client. Le serveur l'interprète comme une classe de fournisseur ou une indication de configuration. S'il ne sait pas interpréter cette information, il doit l'ignorer, quitte à la signaler. Un serveur qui répond avec des informations propres au fournisseur devrait utiliser l'option 43. La chaîne peut donc orienter une branche de politique de configuration ; elle ne certifie ni la marque d'une carte, ni la provenance de l'équipement. Une chaîne déclarée par un client n'est pas une preuve indépendante du client.

Dans l'option 43, le contenu est opaque et sa signification appartient au fournisseur. S'il y place plusieurs éléments, le RFC recommande des sous-options code-longueur-valeur. Les codes intérieurs, sauf les cas particuliers, peuvent avoir un sens local différent des codes DHCP extérieurs. Même le marqueur End change de portée : dans la boîte intérieure, il termine les extensions encapsulées, pas toutes les options du message ; en son absence, c'est la longueur de l'enveloppe qui borne la lecture. Une capture peut montrer les octets renvoyés, sans établir que le client les a interprétés ou appliqués.

L'option 61 a un autre rôle. Le serveur l'utilise comme indice de sa base des liaisons d'adresses. Il doit traiter cet identifiant comme opaque. Il peut contenir un type et une adresse matérielle, mais n'y est pas réduit : une autre valeur est possible. Le choix doit être unique parmi les identifiants employés sur le sous-réseau du client, sous la responsabilité du fournisseur ou de l'administrateur. L'unicité utile à une table de baux ne vaut pas authentification. La retrouver dans deux messages ne démontre pas à elle seule qu'une même personne ou une même machine physique les a produits.

L'option 55 désigne les codes de paramètres que le client demande. Leur ordre peut exprimer une préférence. Le serveur n'est pas obligé de renvoyer les options dans cet ordre, même s'il doit essayer d'insérer les paramètres demandés dans l'ordre voulu. Une demande n'est donc ni la preuve d'une réponse complète ni celle d'un réglage installé. Avec l'option 57, le client annonce en outre la taille maximale d'un message DHCP qu'il accepte, au moins 576 octets. Une liste d'attentes et une limite de taille ne constituent pas un état opérationnel observé.

La suite du dialogue compte. Le RFC 2131 distingue découverte, offre, demande, accusé de réception et vérifications du client. Pour savoir si une configuration a fonctionné, il faudrait rapprocher les paquets pertinents, la politique et les liaisons du serveur, l'état retenu par le client et une mesure du service. Aucun de ces documents ne décrit l'installation réelle d'un opérateur nommé. La section consacrée à la sécurité du RFC 2132 précise d'ailleurs qu'elle n'aborde pas les problèmes de sécurité.

L'apport historique est cette pluralité de fonctions dans une syntaxe extensible commune. La classe aide éventuellement le serveur à choisir ; la clé retrouve une liaison ; la liste exprime une préférence ; les données du fournisseur restent dans leur espace d'interprétation. Les confondre produit une autorité imaginaire. L'idée de primauté du code en fonctionnement de Heng Lu sert ici de grille éditoriale : un document de protocole et une installation observée sont deux preuves distinctes, non deux noms du même fait.

Sources : RFC 2132, RFC 2131, RFC 1048 et Running-Code Primacy de Heng Lu (cadre d'analyse, non règle DHCP).