Résumé

  • La RFC 9928 autorise un relais 4o6 à encapsuler et décapsuler les messages pour un client IPv4 ancien, qui continue à parler DHCPv4 et ignore ce transport.
  • Installée dans un nœud intermédiaire, cette fonction peut masquer le segment de couche 2 au chemin DHCPv6. La combinaison dos à dos d’un 4o6RA et d’un LDRA rétablit l’Interface-ID, mais leur échange interne n’est pas normalisé.
  • Un bail réussi atteste une allocation et un retour jusqu’au client. Il n’atteste ni le port observé, ni la correspondance locale de l’Interface-ID, ni la règle serveur appliquée, ni l’absence d’un chemin DHCPv4 direct.
  • Le contrôle utile relie l’observation d’entrée, l’encapsulation, l’ordre des relais, la décision d’allocation, la livraison et la détection des contournements.

Le bon résultat peut venir d’une preuve incomplète

Dans un réseau d’accès, deux unités radio identiques peuvent être raccordées à des ports différents et servir des cellules différentes. Leur logiciel IPv4 est ancien, mais le réseau de collecte est IPv6. La première unité reçoit une adresse du pool attendu. La seconde reçoit également une adresse et passe son test élémentaire de connectivité. L’égalité des résultats visibles ne dit pas si les deux demandes ont conservé leur origine physique.

La RFC 7341 avait défini DHCPv4 sur DHCPv6 avec un client capable de construire les messages DHCPv6. Cette condition exclut précisément les équipements qui ne peuvent plus être mis à jour. La RFC 9928 confie donc l’opération à un DHCPv4-over-DHCPv6 Relay Agent, ou 4o6RA.

Le relais reçoit la requête DHCPv4, crée un DHCPV4-QUERY, transporte le message vers le service DHCP 4o6, puis extrait la réponse DHCPv4 d’un DHCPV4-RESPONSE valable. Pour l’équipement ancien, rien n’a changé : il émet et reçoit du DHCPv4. Cette transparence est l’objectif fonctionnel. Elle interdit toutefois d’utiliser le client comme témoin du chemin intermédiaire.

La topologie participe au choix du serveur

Une allocation DHCP n’est pas toujours tirée d’un réservoir uniforme. La localisation réseau peut déterminer le pool, la passerelle, les serveurs DNS ou d’autres paramètres. La RFC 7969 décrit cette personnalisation et rappelle que le relais fournit au serveur l’information sur le point d’arrivée de la demande.

DHCPv4 et DHCPv6 ne transportent pas cette connaissance de la même façon. En IPv4, le premier relais renseigne normalement giaddr. En IPv6, plusieurs enveloppes Relay-forward peuvent conserver une suite de link-address et d’Interface-ID. Le serveur peut ainsi voir non seulement une extrémité, mais l’ordre des relais qui sépare le client du service.

Lorsque le 4o6RA est placé à la bordure du réseau IPv6, il encapsule la requête après le segment de couche 2. La RFC 9928 constate qu’une solution limitée au 4o6RA ne fournit pas l’information d’interface dans le message encapsulé et rompt cette propagation topologique. Le paquet reste conforme ; c’est la prémisse de la politique d’allocation qui manque.

Une politique de repli peut masquer l’anomalie. Le serveur choisit un pool général, le client reçoit une adresse et l’indicateur de disponibilité reste vert. Rien dans ce succès ne révèle si le serveur a appliqué la règle propre au port, à la cellule ou au segment attendu.

L’Interface-ID est une garde, pas une étiquette universelle

La solution recommandée associe le 4o6RA à un Lightweight DHCPv6 Relay Agent. Le LDRA se trouve au contact logique de l’accès de couche 2. Il obtient l’information de l’interface et insère un Interface-ID dans le DHCPV4-QUERY envoyé vers l’amont.

La RFC 6221 impose cet option dans les Relay-forward du LDRA. La valeur devrait rester stable pour l’interface, y compris après un redémarrage, car un serveur peut fonder sa politique sur une correspondance exacte. La RFC 9915 exige ensuite que le serveur recopie l’option dans Relay-reply ; le relais s’en sert pour renvoyer le message sur l’interface cliente.

Cette stabilité ne transforme pas la valeur en nom public. L’Interface-ID est opaque. Le serveur ne devrait pas en analyser les octets pour inventer un châssis, un port ou un client. Il faut donc conserver séparément la valeur transmise et la table locale qui reliait cette valeur au port observé à cet instant.

La nuance est décisive pour l’audit. Un journal serveur peut prouver qu’il a comparé une chaîne opaque. Il ne peut pas prouver seul que la chaîne désignait encore le port physique voulu. Un journal du commutateur peut prouver l’arrivée sur un port. Il ne peut pas prouver seul quelle règle d’allocation a finalement gagné.

La couture interne reste à la charge du déploiement

La RFC 9928 recommande une structure dos à dos 4o6RA–LDRA, mais ne définit ni le mécanisme interne d’échange de l’information d’interface, ni son format, ni même l’indication explicite de la présence du 4o6RA. Ce choix permet des mises en œuvre très différentes : deux fonctions dans le même processus, une chaîne matérielle et logicielle, ou un agent qui alimente un autre composant.

La conformité sur le réseau ne fournit donc pas automatiquement la provenance interne. Il faut enregistrer la version de la correspondance, le point où l’observation est devenue Interface-ID et la conduite prévue si cette conversion manque ou devient périmée.

Il existe aussi un cas plus simple. Lorsque le même nœud héberge le 4o6RA et le serveur DHCP 4o6, le 4o6RA seul peut suffire. Le critère n’est pas la présence obligatoire d’une boîte LDRA sur chaque schéma. Le critère est la disponibilité, auprès de la politique, de l’information topologique dont elle dépend.

Le contournement fabrique un second état plausible

Puisque le client ne connaît pas DHCP 4o6, le réseau doit diriger vers le 4o6RA ses messages DHCPv4 diffusés et unicast. La RFC 9928 souligne qu’un serveur DHCPv4 présent sur le même domaine de couche 2 pourrait être joint directement si le déploiement est incorrect. Le texte classe ce cas comme erreur de déploiement, susceptible de produire des états erronés et une mauvaise connectivité, plutôt que comme nouveau problème de sécurité.

Pour l’exploitation, deux chemins possibles exigent deux observations. Le serveur direct peut rendre un bail plausible. Le service 4o6 peut en rendre un autre. Le client ne sait pas raconter lequel a décidé. La preuve doit donc comprendre le test négatif : aucune diffusion ni aucun renouvellement unicast n’a contourné le relais prévu.

Construire le reçu de garde

Le reçu proposé n’est pas une extension DHCP. C’est un dossier de décision local qui réunit des preuves sans leur donner un sens excessif.

Il commence par la requête DHCPv4 observée, l’heure, le nœud d’accès et l’interface cliente. Il conserve ensuite la génération de la table locale, l’identité du 4o6RA, l’interface amont choisie et l’événement d’encapsulation. La couture vers le LDRA possède sa propre entrée : version, donnée transmise et indication locale éventuelle de 4o6.

La partie protocolaire garde l’Interface-ID opaque, son niveau exact dans les Relay-forward imbriqués, les autres link-address utiles et l’ordre des sauts. La partie serveur nomme le service, la règle topologique qui a correspondu, le pool retenu et la configuration renvoyée. La partie retour relie Relay-reply, décapsulation et livraison sur le port d’origine.

Enfin, le reçu note la recherche d’un chemin DHCPv4 direct, le résultat, le renouvellement, le déplacement éventuel du client, la correction ou l’expiration. Un déplacement de port sans transition de politique attendue devient ainsi une alerte vérifiable, pas une intuition.

La responsabilité reste distribuée. L’IETF définit le comportement commun. L’opérateur d’accès possède la correspondance des ports ; l’exploitant du relais possède l’interception et l’encapsulation ; le service DHCP possède la règle et le pool. Le client ancien ne doit pas recevoir fictivement une autorité sur un mécanisme qu’il ne voit pas.

Sources