Résumé

  • RFC 9928 confie à un 4o6RA l’encapsulation DHCPv4-over-DHCPv6 qu’un terminal IPv4 ancien ne peut pas exécuter lui-même.
  • Le transport peut être parfaitement valide tout en perdant la provenance de l’interface de couche 2 dont dépend une politique d’allocation; configuration du client et accessibilité restent à prouver.

Dans un dossier de migration, quatre traces semblaient former une chaîne complète : requête DHCPv4 du terminal, création d’un DHCPV4-QUERY, réponse du serveur, puis paquet rendu au client. Le ticket a été clos avec la formule « configuration délivrée ». Or la trace ne disait pas par quel port logique le terminal était entré ni quelle classe topologique le serveur avait appliquée.

Cette lacune est essentielle lorsque l’adresse ou les options dépendent de l’emplacement. Une réponse bien formée peut être celle que le serveur a effectivement choisie à partir d’une information incomplète. Elle ne prouve pas que le choix correspond à l’accès réel. Elle ne prouve pas davantage que le client a installé l’état, qu’aucun serveur DHCPv4 direct n’a répondu par une autre voie ou que le chemin de données fonctionne ensuite.

RFC 9928 part d’une contrainte industrielle ordinaire : certains hôtes ne savent parler que DHCPv4 et ne peuvent raisonnablement être remplacés ou mis à jour. RFC 7341 permet de transporter leurs paramètres IPv4 sur une infrastructure IPv6, mais suppose à l’origine que le client réalise l’encapsulation DHCP 4o6. RFC 9928 déplace cette fonction dans un commutateur ou routeur intermédiaire, le 4o6RA.

Du point de vue du terminal, rien ne change. Il émet et reçoit DHCPv4. Du point de vue de RFC 7341, le relais prend pourtant la place du client : il choisit son interface DHCPv6, découvre un serveur ou un relais convenable, obtient sa configuration IPv6, demande l’option d’adresse du serveur 4o6, puis encapsule la requête reçue. Cette délégation technique est utile, mais elle attribue au relais une capacité de représentation que le terminal ne voit pas.

Le standard maintient volontairement une petite surface commune. Il ne crée ni nouveau format de message ni obligation supplémentaire pour le serveur 4o6. Le 4o6RA doit rejeter une réponse qui ne contient pas l’option DHCPv4 ou qui est mal formée. Il n’extrait et ne retransmet la réponse interne correcte que si elle peut réellement être acheminée vers le demandeur. Ces règles établissent une preuve de transport. Elles ne prétendent pas établir la vérité de toute la décision de configuration.

La topologie révèle la limite. RFC 7969 décrit la personnalisation de DHCP à partir du réseau. En IPv4, le premier relais renseigne normalement giaddr; plusieurs relais ne donnent donc qu’une vue partielle. En DHCPv6, link-address et Interface-ID peuvent constituer une séquence plus riche entre le client et le serveur.

Quand le client effectue lui-même DHCP 4o6, le relais DHCPv6 connaît l’interface où le message encapsulé est arrivé. Quand l’encapsulation est remontée dans un 4o6RA, celui-ci apparaît comme le client DHCPv6 et le segment de couche 2 disparaît de cette observation. RFC 9928 nomme explicitement le problème : une solution 4o6RA seule brise la propagation de topologie parce qu’aucune information d’interface du segment caché n’accompagne le message.

La recommandation consiste à placer un LDRA de RFC 6221 dos à dos avec le 4o6RA. Le LDRA peut fournir l’Interface-ID à la requête sortante. Mais l’échange interne entre les deux fonctions, son format et l’indication éventuelle de la présence du 4o6RA sont hors du périmètre du RFC. La norme coordonne l’interopérabilité; l’opérateur reste responsable de la filiation des données internes.

C’est ici que les principes de Heng Lu apportent une discipline. La spécification initiale doit contenir le minimum commun vérifiable. Les décisions futures et l’implémentation restent locales, chez celui qui exploite le système et subit la panne. Un champ absent ne doit pas être remplacé par une autorité imaginaire du protocole. Il doit devenir une limite déclarée, un test local et un propriétaire nommé.

L’autre exigence est le guidage de tous les messages DHCPv4, diffusion comme unicast, à travers le 4o6RA. Un placement central ou une traduction d’adresse peut l’assurer. Si un serveur DHCPv4 reste joignable directement dans le même domaine de couche 2, le client peut contourner le relais. RFC 9928 reconnaît alors des états erronés chez le client et les serveurs, jusqu’à une mauvaise configuration affectant la joignabilité. Il classe ce cas comme erreur de déploiement, non comme nouvelle faille de sécurité. Pour l’exploitation, la distinction ne dispense ni de surveillance ni de réparation.

Une preuve exploitable doit donc suivre plusieurs reçus : identité et empreinte de la transaction client; port, VLAN ou interface d’entrée; interface choisie par le 4o6RA et découverte du serveur; empreinte des messages encapsulés; suite ordonnée de link-address et Interface-ID; données topologiques reçues par le moteur de politique; offre ou accusé produit; contrôles de forme et décision de retransmission; état réellement accepté par le terminal; détection de conflit; enfin observation de route, de joignabilité et de service.

Ces pièces ne servent pas à gonfler le processus. Elles empêchent qu’un acteur soit tenu responsable d’une information qu’il n’a jamais pu voir. Le responsable d’accès atteste le lieu d’apparition. Le responsable du relais atteste la transformation. L’équipe DHCP atteste la règle d’allocation. Le propriétaire du terminal atteste l’état installé. L’équipe de service atteste l’effet. Même si une seule organisation porte tous les rôles, les faits gardent des durées, des causes de panne et des moyens de retour différents.

La primauté du code en fonctionnement ne consiste pas à croire tout voyant vert. Elle consiste à respecter ce que chaque programme a réellement calculé. Une requête relayée prouve un échange relayé. Une réponse prouve une décision du serveur sur les données qu’il détenait. Un bail local prouve un état du client. Une sonde prouve une observation datée. Le bon rapport relie ces éléments sans les confondre.

Sources