Résumé

  • Une réponse valide contenant IA_PD et IAPREFIX établit une attribution et ses durées de vie; elle n’observe ni la route amont, ni l’état de transfert, ni l’annonce sur le réseau local.
  • La recette d’exploitation doit relier la transaction DHCPv6, le RIB/FIB d’accès, l’état du routeur client, l’annonce du /64 et des essais de trafic propres au préfixe.

Le contraste est fréquent: l’interface d’administration est verte, un /56 apparaît avec T1 et T2, mais les machines du foyer restent injoignables en IPv6. Un test extérieur ne retrouve aucune route fonctionnelle vers une adresse du sous-réseau annoncé. Le mot « Reply » ne désigne pas l’étape manquante.

RFC 8415 donne à cette réponse un sens limité. Le serveur y transporte les baux et paramètres attribués. Dans une association IA_PD figurent un ou plusieurs préfixes ainsi que T1 et T2; chaque option IA Prefix précise une durée préférée et une durée de validité. C’est la preuve d’un droit d’usage borné dans le temps.

Ce n’est pas une mesure du plan de transfert.

Le bail précède la mise en service

La norme indique que la délégation de préfixe n’exige pas, à elle seule, que le client transfère des paquets qui ne lui sont pas destinés. Une fois le bloc reçu, le client peut le découper, affecter des /64 à ses liens et envoyer des Router Advertisements. Ces opérations sont postérieures à la réponse du serveur.

Le réseau d’accès suit sa propre chaîne. Avec un relais DHCPv6, RFC 8415 prévoit qu’un autre protocole ou un mécanisme hors bande puisse être nécessaire pour installer les informations de routage sur les routeurs traversés par le trafic du client. Une transaction irréprochable peut donc coexister avec une route absente, périmée ou associée au mauvais next hop.

RFC 7084 sépare encore les responsabilités: le routeur CE accepte le préfixe, maintient son routage WAN, choisit les sous-réseaux LAN et les annonce. La validation d’une de ces tâches ne valide pas les autres. La règle qui envoie vers une destination nulle les parties non affectées du bloc rappelle aussi qu’un /56 délégué ne rend pas joignable chaque adresse qu’il contient.

Une preuve liée à la génération courante

La première partie du reçu conserve les identifiants client et serveur, la transaction, l’IAID, le préfixe, sa longueur, le statut, T1, T2 et les deux durées de vie. La deuxième partie nomme le routeur d’accès, le next hop, les générations RIB et FIB et la session abonné. La troisième décrit la route par défaut du CE, le /64 affecté au LAN et les durées annoncées dans les RA.

Viennent ensuite les observations de trafic: une adresse réellement située dans le /64 affecté, plusieurs points de mesure et des résultats distincts pour l’aller et le retour. Un ping isolé sans préfixe, sens ni génération ne suffit pas.

RFC 9096 traite précisément les risques de redémarrage et de renumérotation éclair. L’IAID doit rester stable par défaut, les durées annoncées en aval ne peuvent dépasser la durée restante du préfixe, et les données périmées doivent être signalées. Tout Renew, Rebind, redémarrage, changement de préfixe ou remplacement de route rend le reçu précédent caduc.

Sources