Résumé

  • RFC 9762 ajoute au PIO un signal positif et propre à un préfixe : un client compatible devrait essayer DHCPv6-PD avant de créer de nouvelles adresses individuelles à partir d’un préfixe partagé qui autorise aussi SLAAC.
  • Le bit P ne contient aucune délégation. Il faut des reçus distincts pour l’annonce, la décision du client, la réponse DHCP, l’acceptation du préfixe, la liaison et la route du relais, le choix de source et de premier saut, puis le trafic utile.
  • L’absence du bit n’affirme pas l’indisponibilité de DHCPv6-PD. Sa présence hérite par ailleurs du modèle de confiance des annonces de routeur et peut être détournée pour retarder la configuration ou provoquer des REBIND répétés.

À l’expiration d’un PIO, le terminal a retiré le préfixe de sa liste P. L’équipe d’exploitation en a conclu que la délégation devait s’arrêter. Pourtant, le bail obtenu plus tôt restait valide, la route du relais existait encore et le trafic continuait.

Cette apparente incohérence révèle la précision de RFC 9762. Le document ne confie pas au routeur annonceur l’autorité d’annuler un bail. Il lui permet d’exprimer, avec une durée limitée et pour un préfixe précis, une préférence quant au mécanisme que le client devrait tenter. La décision DHCPv6 qui suit possède sa propre autorité et son propre temps.

Le piège opérationnel consiste à transformer « préférence observée » en « délégation disponible », puis à utiliser cette étiquette comme preuve de toutes les étapes suivantes. L’observation réelle est plus étroite : une interface a reçu une RA, un PIO portait P=1, et un client qui sait faire de la délégation a acquis une raison d’engager son automate DHCPv6.

Un signal placé avant la création d’adresse

La position du bit répond à un problème d’ordre. Si le terminal forme d’abord des adresses SLAAC à partir du préfixe partagé, des applications peuvent commencer à les utiliser. Lorsqu’un préfixe propre au client arrive ensuite, conserver les deux ensembles réduit les gains d’échelle ; supprimer le premier ensemble rompt potentiellement les flux déjà ouverts.

Le PIO est donc le bon endroit pour annoncer la préférence avant cette décision. Pour un client compatible, P=1 demande de privilégier le modèle par terminal décrit dans RFC 9663. Il ne s’agit pas d’un mode global de l’interface. Un PIO mondial peut porter P tandis qu’un PIO ULA reste destiné à SLAAC. Dans un environnement multihomé, deux réseaux amont peuvent annoncer des choix différents.

Le bit P est indépendant des indicateurs M et O de la RA. Des équipements plus anciens peuvent ne lancer DHCPv6-PD que si M ou O est positionné ; un réseau qui veut les servir peut devoir conserver ce signal historique. Le routeur doit également rendre P et le bit autonome A configurables séparément. Activer P ne doit pas modifier A automatiquement.

Cette indépendance conserve une issue de secours. P et A peuvent tous deux valoir 1. Le client qui respecte la préférence traite alors A comme non positionné pour les nouvelles adresses. Si aucun préfixe approprié n’est obtenu, il peut cesser de traiter P sur cette interface et revenir à SLAAC ou à IA_NA selon sa politique. RFC 4862 fournit les règles d’autoconfiguration modifiées ; RFC 4861 fournit le cadre des annonces et de la découverte de voisins. RFC 9762 change une bifurcation, pas l’ensemble de ces protocoles.

La liste P est un état, pas un reflet instantané

Le client maintient, pour chaque interface, la liste des préfixes reçus dans des PIO dont P vaut 1 et dont la durée préférée est encore positive. Quand la longueur de cette liste passe de zéro à un, il devrait commencer à demander une délégation, sauf si la procédure est déjà active. Une durée arrivée à zéro, naturellement ou par une nouvelle annonce, retire le préfixe.

Le passage inverse est volontairement prudent. Lorsque la liste devient vide, le client ne devrait arrêter demandes et renouvellements que s’il ne possède aucune autre raison d’exécuter DHCPv6-PD. Les durées des préfixes déjà délégués ne sont pas raccourcies. L’annonce retire une invitation ; elle ne révoque pas le contrat temporel établi avec le serveur.

Si la liste change alors que des préfixes ont déjà été obtenus, le client doit normalement considérer qu’il s’agit d’une nouvelle configuration et lancer REBIND, sauf lorsque la liste est désormais vide. L’automate et les messages correspondants sont définis par RFC 8415. Une capture de Rebind ou de Reply constitue donc un reçu nouveau, avec une identité de transaction, un serveur, un statut et des options IA_PD propres.

Le journal utile distingue au minimum la RA — source, interface, PIO, bits, durées et génération de liste — de la réaction du client. Une plateforme qui ne garde que la valeur courante P perd le moment de la transition, la raison du REBIND et la possibilité de savoir si une expiration normale a été confondue avec une panne.

Une réponse n’est utile que si le préfixe l’est

Lors de la demande, le client doit fournir une indication de longueur permettant de former des adresses selon SLAAC. Une réponse positive au sens du transport ne suffit pas. Un préfixe trop long pour cet usage doit être ignoré ; un préfixe plus court peut être accepté et subdivisé en préfixes adaptés.

Le routeur annonceur ne sait pas, par son bit, garantir cette issue. Le serveur peut être injoignable, le pool épuisé, la politique défavorable ou la réponse porteuse d’un statut d’échec. La longueur et les durées proposées peuvent être inutilisables. Après une tentative bornée sans préfixe convenable, le client est autorisé à désactiver le traitement de P sur l’interface et à employer un autre mode d’attribution.

Une preuve de délégation doit ainsi relier la requête et son indice de longueur au serveur ou relais effectivement choisi, au Reply, à l’IAPREFIX retourné, aux durées préférée et valide, puis à la décision locale d’accepter. Aucun de ces champs n’est présent dans le PIO initial.

L’erreur symétrique serait de lire P=0 comme une interdiction. Le RFC qualifie P d’indicateur purement positif. L’absence de PIO avec P ne permet pas de conclure que le service de délégation n’existe pas. Un routeur de bord décrit par RFC 7084, ou un client configuré explicitement, peut continuer sans invitation. L’absence d’un signal est seulement l’absence de ce signal.

Le relais doit transformer le bail en chemin

Le modèle de RFC 9663 apporte ses bénéfices lorsque le préfixe délégué est installé dans la table du premier routeur comme une route vers l’adresse link-local du client. Le préfixe est off-link pour l’infrastructure : le routeur n’a plus à maintenir une entrée de voisin pour chaque adresse mondiale créée par la machine. Plusieurs adresses, conteneurs ou réseaux internes peuvent partager une seule unité de routage côté infrastructure.

Cette projection n’est pas effectuée par le drapeau P, ni nécessairement par le serveur DHCP distant. RFC 8987 attribue au relais délégant des obligations distinctes : suivre les liaisons et les durées, installer les routes vers les prochains sauts, adapter les filtres d’entrée, préserver ou retirer l’état selon des événements définis et exposer cet état à l’opérateur. Un Reply réussi au terminal ne prouve pas qu’une route existe. Une route sur un routeur ne prouve pas que son homologue redondant possède le même état. Une ligne dans la RIB ne prouve pas le passage dans le plan de données.

Le client doit lui aussi traiter le préfixe comme off-link sur l’interface par laquelle il l’a reçu. Il ne doit pas renvoyer vers cette interface un paquet dont la destination appartient au préfixe, sous peine de boucle. Une route de rejet à métrique élevée est une défense possible. Les adresses créées doivent être associées à l’interface pour la sélection de source selon RFC 6724.

En multihoming, il faut encore conserver le lien avec l’adresse link-local du serveur ou du relais ayant fourni le Reply. Plusieurs réponses redondantes pour le même préfixe peuvent produire plusieurs associations. RFC 8028 montre pourquoi une source et un premier saut compatibles comptent dans un réseau à préfixes multiples. Posséder le bon préfixe et remettre le paquet au mauvais amont reste un échec.

La chaîne complète comporte donc davantage de maillons que le signal : RA reçue ; génération de la liste P ; requête DHCP ; Reply accepté ; bail ; liaison du relais ; route et filtre actifs ; adresse formée ; source et premier saut choisis ; paquet livré ; transaction applicative achevée. Une couleur verte ne traverse pas automatiquement ces frontières.

La communication locale devient elle aussi routée

Avec un préfixe unique par terminal, l’adresse d’un autre client est off-link. Un échange entre deux machines du même domaine de diffusion passe d’abord par le routeur par défaut. Un Redirect ICMPv6 peut ensuite fournir un chemin plus direct. RFC 9762 recommande aux hôtes concernés de traiter les Redirects sauf décision locale contraire ; sinon, une latence supplémentaire est possible.

Un test vers Internet ne couvre pas ce comportement. Une délégation et une route amont peuvent fonctionner alors qu’une communication locale, une découverte de service ou un flux latéral soumis à des ACL suit un chemin inattendu. Les scénarios de recette doivent séparer trafic hors lien, trafic entre clients et retour.

Le choix déplace aussi les coûts. Le modèle par préfixe consomme davantage d’espace et crée une route par terminal, mais réduit les états ND par adresse et regroupe le destin opérationnel des adresses d’une machine. Un grand réseau Wi-Fi peut y gagner. Un petit site qui n’a reçu qu’un espace limité peut manquer de /64. Le bit signale que l’opérateur préfère ce compromis ; il n’atteste pas que le dimensionnement du pool le supporte.

Une valeur enregistrée n’authentifie pas son émetteur

Le registre IANA des drapeaux du Prefix Information Option attribue le bit 3 à cette fonction. Il rend l’encodage commun. Il ne prouve pas que le routeur qui a émis une RA sur un port donné était autorisé.

Le mécanisme conserve le modèle de sécurité des RA. Sans la protection de RFC 6105, un attaquant local peut envoyer un PIO ressemblant à celui du réseau, lever P et conduire les clients compatibles à ignorer A. Sans service PD convenable, l’obtention d’adresse échoue ou tarde. RFC 7113 explique en outre pourquoi la simple présence d’une fonction RA-Guard ne prouve pas que les chemins de contournement par extensions ou fragmentation sont correctement fermés.

La réponse DHCP ouvre une autre frontière de confiance. Sans les mesures de RFC 7610, un faux serveur peut fournir des préfixes ou paramètres invalides. Même si une seule organisation administre routeurs et serveurs, les deux messages ne sont pas un même acte cryptographique. La confiance accordée à l’annonce ne se transmet pas par proximité au Reply.

Des annonces alternant rapidement P=1 et P=0 peuvent enfin provoquer des changements de liste et des REBIND. Le contrôle de débit de RFC 8415 borne les émissions d’un client, mais ne garantit ni une charge nulle ni l’absence de perturbation. Il faut compter séparément les changements reçus, les transitions locales et le travail imposé aux serveurs et relais.

La modestie du bit est son architecture

Il serait injuste de demander au bit P de prouver toute la chaîne. Son rôle réduit est justement ce qui autorise une évolution locale. Il règle l’ordre du premier choix sans centraliser le pool, la durée, le routage, le filtrage, le repli ou le résultat applicatif.

Le principe de Heng Lu sur la spécification initiale minimale, la décision future localisée et l’adoption volontaire éclaire cette construction : un langage commun suffit à coordonner une bifurcation, tandis que chaque propriétaire reste responsable de son exécution. La primauté du code qui tourne impose ensuite de vérifier l’état réellement appliqué. Enfin, ses couches de réalité interdisent de confondre sens normatif, paquet reçu, bail, route et expérience utilisateur.

Le drapeau garde sa valeur lorsque la revendication reste à sa taille.