Résumé

  • La RFC 9915 est une norme Internet IETF, STD 102, publiée en janvier 2026 ; elle rend obsolète la RFC 8415.
  • Son changement opérationnel central est un cycle de vie plus explicite pour les échanges client/serveur, les DUID, les identifiants de serveur, les associations d’identité, les durées, le renouvellement, le rebinding, les relais, Reconfigure et la délégation de préfixes.
  • La RFC 9915 supprime l’attribution temporaire IA_TA et la capacité Server Unicast, avec son option et le code d’état UseMulticast.
  • Cette suppression ne fait pas disparaître les adresses de confidentialité IPv6 : SLAAC et ses adresses temporaires restent encadrées par les RFC 4862 et 8981.

Lire DHCPv6 comme une autorité d’état

La RFC 9915 décrit DHCPv6 pour la configuration sans état et l’attribution avec état d’adresses et de préfixes IPv6, seul ou en parallèle de SLAAC. Le client et le serveur échangent directement ou par l’intermédiaire de relais. Le DUID identifie le client ; l’identifiant de serveur permet de reconnaître l’autorité dont les réponses appartiennent à l’échange en cours. Les associations d’identité, ou IA, regroupent les ressources et leur état, notamment les associations d’adresses et les préfixes délégués.

Un bail n’est donc pas seulement une adresse. Les durées préférée et valide indiquent pendant combien de temps une adresse ou un préfixe peut être utilisé et quand il doit être renouvelé ou abandonné. Le client tente normalement un Renew auprès du serveur choisi avant l’expiration. Si ce serveur ne répond plus, Rebind élargit la recherche aux serveurs disponibles. Une Reply initiale réussie démontre seulement qu’un échange a fonctionné ; elle ne démontre ni le prochain Renew, ni le Rebind, ni le chemin de relais, ni l’usage continu d’un préfixe délégué.

Les relais font partie de cette frontière d’état. Ils transportent le trafic DHCPv6 dans une topologie où la multidiffusion, le choix du relais, l’interface et la continuité du serveur peuvent différer du chemin initial. Reconfigure peut demander au client de revoir sa configuration, mais son fonctionnement doit être vérifié sur le vrai chemin de relais et dans la vraie politique de filtrage. Un remplacement ou un basculement de serveur doit préserver les hypothèses d’identité, d’IA et de temporisation ; la norme ne rend pas automatiquement toute coexistence d’implémentations sûre.

La délégation de préfixe applique la même logique au routeur de bordure client. Le préfixe délégué possède ses durées et son contexte IA ; le routeur doit donc maintenir son usage en aval conformément à ces durées. La RFC 7084 apporte le contexte des exigences du routeur de bordure, mais ne prouve pas qu’une implémentation ou une topologie donnée conservera la délégation lors d’un basculement. Il faut tester séparément la frontière serveur, la frontière relais et le renumérotage en aval.

Capacités retirées et limites de la confidentialité

La RFC 9915 retire IA_TA, mécanisme DHCPv6 d’attribution d’adresses temporaires. Elle retire aussi Server Unicast, son option et le code d’état UseMulticast. Ces changements réduisent la surface de comportement attendue d’une machine à états conforme. Ils ne signifient pas que les adresses de confidentialité ont disparu. La RFC 4862 définit SLAAC et la RFC 8981 les adresses temporaires de SLAAC ; ces mécanismes peuvent donc rester employés selon la politique du réseau. La RFC 9915 ne signifie pas davantage que DHCPv6 remplace toujours SLAAC.

Les options avec état multiples et les IA multiples exigent une matrice de tests dédiée. La RFC 7550 décrit des problèmes opérationnels associés aux options DHCPv6 avec état multiples : la réussite d’une IA ne prouve pas celle des autres. Corrélez DUID, identifiant de serveur et IA ; mesurez séparément les durées d’adresse et de préfixe ; journalisez le serveur et le relais de chaque transition.

Parcours de décision pour l’acceptation opérateur

  1. Inventorier. Recenser serveurs DHCPv6, chemins de relais, dépendances multicast, DUID, identifiants de serveur, chaque IA, les consommateurs de préfixes délégués et toute attente historique envers IA_TA ou Server Unicast.
  2. Établir le socle. Capturer l’allocation initiale, les durées préférée et valide, les temporisations de Renew et Rebind, l’autorité de la Reply, les métadonnées de relais et l’état d’adresses et de routes obtenu.
  3. Provoquer les transitions. Tester perte et remplacement de serveur, perte et changement de relais, multicast inaccessible, Reconfigure, IA multiples et coexistence RFC 8415/RFC 9915. Cette coexistence reste inconnue tant qu’elle n’est pas mesurée.
  4. Tester la délégation. Faire renouveler et rebind le préfixe par un routeur de bordure, puis vérifier l’usage en aval, l’expiration et la récupération après changement de serveur ou de relais.
  5. Vérifier la confidentialité. Confirmer le comportement SLAAC et RFC 8981. La suppression d’IA_TA ne prouve ni la disparition des adresses temporaires, ni le remplacement de SLAAC par DHCPv6.
  6. Observer et revenir en arrière. Exiger des indicateurs pour DUID, identifiant de serveur, IA, durées, Renew, Rebind, Reconfigure, chemin de relais et continuité du préfixe. Déclencher le retour arrière si une transition perd son autorité ou bloque un préfixe aval.

La décision est go seulement lorsque les preuves couvrent tout le cycle, pas lorsque l’allocation initiale réussit. Sinon, conserver un pilote borné, l’ancienne configuration et des critères explicites de retour arrière. Cette conclusion relève de l’analyse de Theo March : la norme fournit la machine à états ; l’opérateur doit démontrer que le système environnant en transporte effectivement l’état.

Sources

Registre des affirmations et des preuves RFC

Affirmation Preuve
État DHCPv6 actuel, échanges, identifiants, IA, durées, Renew, Rebind, Reconfigure, retraits et délégation RFC 9915
Ancienne base DHCPv6 et frontière de révision RFC 8415
Coexistence SLAAC et autoconfiguration d’adresse RFC 4862
Contexte du routeur de bordure et de la délégation RFC 7084
Options avec état multiples et frontière opérationnelle des IA multiples RFC 7550
Confidentialité par adresses temporaires SLAAC RFC 8981

Ce briefing ne prétend ni à un support fournisseur, ni à un déploiement universel ou achevé. Il ne traite pas non plus de l’état de routes projetées RPL de la RFC 9914, de la normalisation des capacités radio de la RFC 9913, ni du graphe de récupération RAW de la RFC 9912 : ces sujets sont distincts.