Résumé

  • DHCPv6-PD confie l’usage d’un préfixe à un routeur demandeur sans décrire la topologie qui se trouve derrière lui.
  • Le routeur demandeur doit transformer ce bail en sous-préfixes stables et en durées de vie cohérentes ; le routeur de bordure doit maintenir les routes reliant chaque bail au bon prochain saut.
  • Un reçu délégation-vers-route doit rapprocher l’état du protocole de preuves de paquets dans les deux sens.

Le bail est vert, mais le LAN reste noir

Imaginons une console d’assistance qui affiche un échange IA_PD réussi. Le routeur aval a reçu un préfixe, les durées de vie préférée et valide diminuent normalement et aucune erreur DHCPv6 n’apparaît. Pourtant, les paquets destinés à un serveur derrière ce routeur s’arrêtent au CE. La route vers le préfixe délégué n’a jamais été installée avec le routeur aval comme prochain saut, ou elle a été retirée trop tôt.

Les deux écrans peuvent dire vrai. DHCPv6 peut attester un bail encore valable tandis que le chemin de transfert est incomplet. L’erreur consiste à faire du succès du bail une preuve d’allocation, d’annonce sur le lien, de programmation du transfert et d’accessibilité.

La RFC 8415 fixe précisément cette frontière. La délégation de préfixe convient aux situations où le routeur délégant ne connaît pas la topologie située derrière le routeur demandeur. Le serveur choisit un préfixe et le transmet ; le client en devient responsable. Il peut le découper, affecter des sous-réseaux à ses interfaces et les annoncer. Ces actes viennent après la délégation et ne sont pas contenus dans l’état « succès » de l’IA_PD.

Une responsabilité bornée par le temps

L’unité utile n’est donc pas « préfixe présent », mais un tuple : identité du client, IAID, préfixe et longueur, serveur, T1, T2, durées de vie préférée et valide, heure d’observation. Un renouvellement peut les prolonger ; la RFC 8415 autorise aussi le serveur à modifier la liste des préfixes ou à renvoyer un préfixe devenu inadéquat avec des durées nulles. Il faut conserver le contenu exact de la réponse, pas seulement son voyant vert.

Les durées de vie forment une hiérarchie. Les adresses et sous-préfixes dérivés ne peuvent être annoncés avec une durée restante supérieure à celle de la délégation mère. Sinon, le LAN continue de croire des adresses utilisables après la fin de l’autorité amont. Pour l’utilisateur, la panne ressemble à un défaut de routage ; en réalité, la frontière temporelle a été rompue.

La RFC 9818 ajoute des exigences pour les CE qui délèguent vers le LAN. Ils doivent prendre en charge IA_PD sur leurs interfaces internes, affecter les préfixes depuis le pool disponible et journaliser une erreur si ce pool est insuffisant. Le préfixe d’un lien ne doit pas changer sans modification de politique ou de topologie. Surtout, la table de routage locale doit suivre dynamiquement les baux et leurs prochains sauts, puis supprimer la route à la libération ou à l’expiration.

Plusieurs défaillances restent possibles : bloc amont trop petit, sous-préfixe mal réservé, annonce aval absente, bail sans route correspondante, durées enfants supérieures à la durée mère, ou chemins aller et retour soumis à des politiques différentes. Relire uniquement le DHCP Reply ne corrige aucune d’entre elles.

Construire le reçu des deux côtés

Côté délégant, le reçu conserve l’identité du serveur, le DUID, l’IAID, le préfixe exact, l’instant de transaction, T1/T2, les deux durées de vie et la nature de l’événement : attribution, Renew, Rebind, Release ou expiration. Côté demandeur, il indique les sous-préfixes réellement affectés, les interfaces ou routeurs destinataires, les durées héritées et la génération de configuration qui a pris la décision.

Il faut ensuite joindre la preuve de transfert : route du CE, prochain saut, interface, heure d’installation, filtre éventuel et événement de retrait. En aval, on capture la route locale, les annonces de routeur et l’état de sélection d’adresse attendu. Des tests de paquets sont menés dans les deux sens depuis la limite du service. Un simple ping émis par le CE ne couvre ni le DNS, ni le filtrage à états, ni la sélection de l’adresse source, ni un retour asymétrique.

Le contrôle se répète à quatre instants : délégation initiale, renouvellement, changement de politique ou de topologie, retrait ou expiration. Le même préfixe observé deux fois ne représente pas nécessairement le même état opérationnel.

Respecter le périmètre des RFC

Ce reçu ne transforme pas DHCPv6 en protocole de topologie. Il rapproche des preuves détenues par plusieurs systèmes tout en respectant la division des responsabilités. Il ne résout pas non plus la sélection de source ou la politique d’un réseau multi-opérateur. La RFC 9818 écarte explicitement ce cas en raison de sa complexité ; l’opérateur doit y ajouter ses propres preuves d’entrée, de sortie et de domaine de panne.

Sources