Résumé

  • DHCPv6 Reconfigure ne transporte pas la nouvelle configuration. Il invite un client qui a accepté ce mécanisme à lancer un Renew, un Rebind ou une Information-request, puis laisse l’échange DHCPv6 ordinaire produire l’état suivant.
  • Dans RFC 6977, une Reconfigure-Reply peut porter le statut Success alors que le serveur n’enverra de Reconfigure à aucun client de la liste. Il faut donc observer séparément la sélection, l’émission, l’authentification, la transaction, l’installation et le service rendu.

Un voyant vert au mauvais étage

Imaginons un réseau d’accès dont le relais apprend qu’une donnée de provisionnement liée à un lien vient d’être modifiée. Il forme une Reconfigure-Request avec l’adresse du lien et plusieurs DUID. Le serveur répond Success. Le tableau d’exploitation passe au vert, mais les terminaux utilisent toujours leurs anciennes adresses et leurs anciens paramètres.

Cette situation n’a rien de contradictoire. Le serveur peut avoir accepté la demande tout en excluant des clients dont il ne possède plus l’état. Certains n’ont jamais envoyé l’option Reconfigure Accept. D’autres attendent derrière une limite de débit. Un message peut être en transit, rejeté par l’authentification, ou avoir déclenché un Renew dont la Reply n’est pas encore installée. Enfin, un client DHCP peut avoir changé son état sans que l’application ait abandonné l’ancienne adresse.

Le statut n’est pas faux : il décrit le traitement de la demande du relais. L’erreur consiste à lui attribuer une autorité qu’il n’a pas, celle de certifier l’exécution par toute une population de clients.

RFC 6977 rend cette limite explicite. La liste incluse dans une réponse réussie désigne les clients auxquels le serveur ne compte pas envoyer Reconfigure. Tous les clients demandés peuvent y figurer, et Success demeure permis. L’accusé relais-serveur n’est donc délibérément pas un reçu d’exécution côté terminal.

Un déclencheur étroit, pas un colis de configuration

RFC 9915 est désormais la spécification de base de DHCPv6. Le registre IANA lui rattache notamment le type RECONFIGURE, valeur 10. Le message a une fonction réduite : demander à un client unique de commencer un autre échange.

Le message doit être unicast. Il contient l’identifiant du serveur, l’identifiant correspondant du client, une authentification acceptable et une option Reconfigure Message. Cette dernière ne peut demander que trois messages : Renew, Rebind ou Information-request. Les nouvelles adresses, les préfixes et les autres paramètres de service ne sont pas livrés dans ce déclencheur. Ils arrivent, s’ils arrivent, dans la Reply du nouvel échange.

Cette architecture impose plusieurs décisions indépendantes. Le client doit avoir annoncé son accord avec Reconfigure Accept. Le serveur choisit s’il déclenche Renew, Rebind ou Information-request. Le client vérifie l’identité, l’authentification et la protection contre la répétition, puis construit sa propre requête. Le serveur calcule alors une Reply selon son état courant. L’implémentation du client décide enfin ce qu’elle installe et l’exploitation vérifie le résultat utile.

Une capture du seul Reconfigure prouve donc peu de chose : un déclencheur valide a été émis vers une identité. Elle ne prouve ni que l’identité correspond encore au terminal présent, ni qu’un échange a abouti, ni que la configuration a été appliquée.

L’accord du client est une limite opérationnelle

Le serveur ne peut utiliser Reconfigure que si le client a annoncé sa volonté de le recevoir. L’absence de Reconfigure Accept n’est pas une panne protocolaire. Le terminal reste un client DHCPv6 valable et évolue avec les durées de bail, les renouvellements ordinaires ou ses propres Information-request.

Cette propriété empêche une capacité facultative de devenir clandestinement obligatoire. Elle crée aussi une responsabilité de planification. Un opérateur doit mesurer la part des clients éligibles avant de raccourcir une fenêtre de renumérotation. Une flotte à 70 % compatible n’est pas une flotte entièrement pilotable ; les 30 % restants doivent disposer d’un chemin temporel sûr.

RFC 8947 illustre pourquoi l’universalité ne peut être supposée. Les équipements très contraints peuvent omettre des fonctions dont l’authentification et l’état persistant coûtent trop cher. Leur absence de Reconfigure change la vitesse de réaction, pas leur légitimité sur le réseau.

Authentifier l’émetteur sans inventer le résultat

Le protocole Reconfigure Key Authentication Protocol distribue au client une clé de 128 bits dans une Reply initiale, puis utilise cette clé avec HMAC-MD5 pour les Reconfigure ultérieurs. La première remise de clé se fait en clair sur le chemin DHCPv6 ; elle constitue une frontière de menace qu’il faut nommer, pas masquer derrière le mot « authentifié ».

La valeur de détection de rejeu doit croître de façon monotone. Le serveur doit préserver cette continuité après un redémarrage. Une bascule qui restaure les baux mais perd les clés ou les compteurs peut posséder une excellente vue des clients tout en étant incapable de produire un déclencheur qu’ils accepteront.

L’authentification répond à une question précise : ce client peut-il attribuer ce message à l’autorité serveur munie de la clé et considérer sa valeur de rejeu comme nouvelle ? Elle ne répond pas à trois autres questions : le bon client a-t-il été sélectionné, la Reply suivante contient-elle la bonne configuration, et l’application fonctionne-t-elle avec celle-ci ?

Les preuves doivent rester alignées sur ces frontières. Une vérification cryptographique ne doit pas devenir un raccourci sémantique vers « changement accompli ».

Le relais propose une population, le serveur décide

RFC 6977 ajoute Reconfigure-Request et Reconfigure-Reply entre relais et serveur. Le relais peut fournir une adresse de lien et des identifiants de clients touchés par une modification de données. Le serveur conserve toutefois la décision : reconnaître ou non le relais, croire son indication de lien, retrouver les clients, vérifier leur éligibilité et répartir la charge.

Le comportement par défaut est le refus. Une demande provenant d’un relais inconnu doit être écartée. La protection IPsec décrite par RFC 8213 peut sécuriser le canal entre relais et serveur, mais la sécurité du canal ne décide pas si la population indiquée est juste. Un relais compromis ou mal classé peut soumettre une demande parfaitement protégée concernant les mauvais abonnés.

Pendant les retransmissions, le relais peut retirer des clients, pas en ajouter. Cette asymétrie limite l’expansion silencieuse d’une opération déjà engagée. Elle ne remplace pas la validation du lien, du DUID et de l’état du serveur.

Dans un déploiement multiserveur, plusieurs serveurs peuvent recevoir la même demande et posséder des vues différentes. Le relais doit alors comprendre que plusieurs réponses Success ne constituent pas un consensus sur l’état final. Il faut relier chaque décision à l’autorité serveur, au client et à l’échange qui suit.

Six vérités partielles au lieu d’une seule réussite

Un registre d’exploitation utile sépare au moins six événements :

  1. le relais a observé une modification de la donnée source et formé une population candidate ;
  2. le serveur a accepté la demande du relais et répondu ;
  3. le serveur a choisi un client éligible et émis un Reconfigure authentifié ;
  4. le client a validé le déclencheur et envoyé le message demandé ;
  5. le nouvel échange DHCPv6 a produit une Reply acceptée ;
  6. l’état installé et le chemin applicatif ont été observés.

Chacun dispose d’une preuve différente : journal de relais, réponse signée du serveur, compteur d’émission, validation d’authentification, identifiant de transaction, état local et test de service. Les fusionner détruit la capacité de diagnostiquer un écart.

La même discipline vaut pour les échecs. Une réponse qui énumère tous les clients comme exclus est une réussite du traitement de requête et un échec de couverture. Un Renew sans Reply est une réussite du déclenchement et un échec de transaction. Une Reply acceptée suivie d’une application attachée à l’ancienne adresse est une réussite DHCP et un échec de migration de service.

La limitation de débit fait partie de la vérité

Reconfigure peut créer une pointe importante : une demande du relais, de nombreux messages individuels, puis autant d’échanges DHCPv6. RFC 6977 exige que le serveur puisse limiter ce travail. Une politique sûre budgète séparément les déclencheurs et la capacité nécessaire aux opérations DHCP ordinaires.

La file d’attente transforme aussi la signification du temps. Le serveur peut avoir accepté une intention maintenant tout en n’émettant les derniers messages que plus tard. L’objectif de service doit donc couvrir le délai entre observation source, sélection, émission, transaction et installation, plutôt que la seule latence de Reconfigure-Reply.

Des tentatives illimitées sont dangereuses. Elles peuvent aggraver une panne, monopoliser le serveur et masquer une population injoignable. Les budgets doivent préciser le maximum par événement source, par demande, par intervalle serveur et par fenêtre de changement, ainsi que la condition d’arrêt.

L’état récupéré reste une hypothèse

Leasequery, Bulk Leasequery et Active Leasequery améliorent la reconstruction de l’état serveur. Ils réduisent l’ignorance après bascule et peuvent aider à retrouver les clients susceptibles d’être affectés. Ils ne changent cependant pas une ancienne observation en état présent.

Un bail récupéré peut appartenir à un client qui a quitté le lien. Une mise à jour active peut être en retard ou arriver hors ordre. Une réplication peut restaurer l’adresse mais pas la clé Reconfigure ni la valeur de rejeu. La bonne pratique est d’étiqueter la provenance et la fraîcheur de chaque état, puis de confirmer le client vivant avant une action de grande portée.

Le modèle YANG de RFC 9243 rend certaines configurations du service plus observables. Là encore, la représentation de contrôle n’est pas l’état effectif d’un terminal. Elle aide à expliquer l’intention et les paramètres du serveur ; elle ne remplace pas l’observation du client.

La renumérotation révèle le risque

RFC 6879 décrit des scénarios où un réseau IPv6 d’entreprise doit faire évoluer ses préfixes. Reconfigure peut accélérer le retour des clients vers le serveur. Il ne supprime ni la coexistence nécessaire entre ancien et nouvel état, ni les clients non participants, ni les applications qui conservent des adresses.

Une stratégie robuste garde l’ancien chemin pendant une période définie, mesure les terminaux retardataires et retire progressivement l’ancien état seulement après preuve. Si la période de chevauchement est réduite sur la foi d’un Success relais-serveur, le délai normal, la limitation de débit ou l’absence d’option côté client devient une population en panne.

Le mécanisme est donc un accélérateur facultatif à l’intérieur d’un plan de transition réversible, non une permission d’effectuer une coupure instantanée.

Ce que le protocole ne doit pas prétendre savoir

La spécification commune peut définir les formats, les identifiants, l’opt-in, l’authentification, la protection contre le rejeu et les trois échanges autorisés. Elle ne connaît pas la politique commerciale qui a motivé le changement, le risque d’une application, la qualité d’un inventaire ni la fenêtre sûre d’un opérateur.

Ces décisions restent locales. Le relais détermine quel événement mérite une demande. Le serveur décide quelle source il accepte, quels clients il retrouve et combien il peut en traiter. Le terminal applique sa logique. L’opérateur fixe les garde-fous, conserve les preuves et décide du retrait de l’ancien état.

Le principe de Heng Lu est ici concret : le code en fonctionnement prime sur la déclaration. Une recommandation, un accusé ou un paquet valide décrit une étape ; seule l’exécution observée établit la réalité suivante. La spécification initiale minimale porte le déclencheur interopérable. Les décisions futures localisées laissent l’évolution à ceux qui exploitent les composants. L’adoption volontaire reste visible jusque dans l’option que le client peut ne pas envoyer.

Sources