Résumé

  • Confirm est envoyé après un changement d’information réseau afin de savoir si les adresses déjà détenues conviennent encore au lien actuel. La requête ne désigne volontairement aucun serveur.
  • Un Success signifie que toutes les adresses présentées passent ce test topologique. Le serveur ignore T1, T2 ainsi que les durées préférée et valide ; aucune nouvelle durée n’est accordée.
  • La RFC 9915, signée par Tomek Mrugalski avec Bernie Volz, Michael C. Richardson, Sheng Jiang et Timothy Winters, sépare ainsi verdict de lien, autorité sur le bail et état d’exécution.

Trois fins qui peuvent se ressembler à l’écran

Un poste change de point d’accès. Quelques secondes plus tard, son adresse IPv6 est toujours affichée et les applications continuent de fonctionner. Un tableau de bord pressé inscrit : « confirmation réussie ».

Trois histoires différentes peuvent pourtant produire cette même image.

Dans la première, un serveur a répondu Success. Dans la deuxième, plusieurs serveurs ont répondu et tous ont dit NotOnLink, mais l’interface n’a pas encore terminé sa reconfiguration. Dans la troisième, personne n’a répondu ; le client a simplement conservé ses baux selon les dernières durées connues, comme la RFC 9915 le lui recommande.

Le maintien visible de l’adresse n’identifie donc pas le chemin de décision. Il faut le reçu de l’échange.

La RFC 9915 réserve Confirm au client qui possède des adresses, sans préfixe délégué, et qui détecte une modification des informations de réseau. Il veut savoir s’il se trouve encore sur un lien où ces adresses ont un sens. Le message contient son identifiant, ses associations d’identité et toutes les adresses concernées. Il ne doit pas contenir de Server Identifier ; un serveur doit écarter un Confirm qui en contient un.

Cette absence distribue la question. Le client ne demande pas à l’ancien bailleur : « me reconnaissez-vous ? » Il demande à tout serveur compétent sur le lien : « cet ensemble d’adresses appartient-il à la topologie d’ici ? »

Le serveur répond sur le préfixe, pas sur le contrat

Le traitement côté serveur est bref. Toutes les adresses conviennent au lien : Success. Une seule ne convient pas : NotOnLink. Le serveur ne sait pas effectuer le test, ou aucune adresse n’a été fournie : aucun Reply ne doit partir.

Le silence possède donc une signification négative très précise : aucun verdict exploitable n’a été produit. Il ne vaut ni accord tacite ni refus.

Le contraste le plus net se trouve dans les champs de durée. Le client devrait mettre à zéro T1 et T2 dans IA_NA, ainsi que preferred-lifetime et valid-lifetime dans les options d’adresse, car le serveur les ignore. Le message transporte une adresse à tester, non un compteur à renégocier.

Renew fait le travail différent. À T1, le client vise le serveur qui a fourni les baux et lui demande de prolonger les durées. Ce serveur cherche le binding, vérifie l’association et renvoie, s’il l’accepte, de nouvelles valeurs. Si cette voie ne répond pas avant T2, Rebind permet à tout serveur disponible de prendre en charge la prolongation.

La distribution des pouvoirs devient lisible :

  • Confirm distribue le jugement topologique ;
  • Renew réserve d’abord la durée au serveur d’origine ;
  • Rebind ouvre la durée à un autre serveur après l’échec du premier chemin.

L’IANA attribue des codes distincts à ces messages. Le registre garantit que tous nomment les opérations de la même façon. Il ne dit pas quelle opération a réellement eu lieu, ni si un serveur possédait les données nécessaires.

L’adresse reste ; le sable continue de tomber

Après Success, le client peut employer les adresses. Il les emploie sous les anciennes durées. Après un échange sans réponse, il peut également les conserver sous les anciennes durées. Même action immédiate, preuve différente ; même horloge dans les deux cas.

Supposons qu’il reste vingt minutes de valid lifetime au départ. Success ne remet pas le compteur à vingt minutes. Dix minutes après, il en reste environ dix, sauf Reply ultérieur de Renew ou Rebind. Présenter le résultat comme un renouvellement crée du temps qui n’a été accordé par personne.

La RFC 4862 explique pourquoi ces minutes ne sont pas décoratives. Une adresse est d’abord preferred. Une fois cette durée expirée, elle devient deprecated : les communications existantes peuvent continuer, mais les nouvelles devraient préférer une autre source. Lorsque valid lifetime expire, elle devient invalid et ne doit plus être utilisée comme source ni acceptée comme destination.

Un voyant « adresse active » efface ces transitions. Le reçu utile conserve la valeur initiale, l’instant d’acquisition, le temps restant avant Confirm, puis toute nouvelle durée reçue plus tard. Sans ce point de départ, impossible de distinguer prolongation et simple continuité.

Un oui suffit, mais il faut savoir qui l’a prononcé

Puisque le message ne cible aucun serveur, plusieurs Replies peuvent revenir. La RFC 9915 ne fait pas la moyenne. Si un seul Reply valide dit Success, le client peut continuer et ignorer les NotOnLink. Il ne relance la découverte que s’il reçoit une ou plusieurs réponses et qu’elles sont toutes négatives.

Cette règle protège le service contre un serveur qui manquerait d’information à jour. Elle révèle aussi un désaccord potentiellement précieux. Si S1 et S2 disent NotOnLink tandis que S3 dit Success, le résultat opérationnel est positif, mais l’état de contrôle est hétérogène.

Un compteur agrégé détruit ce signal. Il faut conserver le DUID de chaque répondant, le relais, l’interface, la liste exacte d’adresses et la version de la configuration de préfixes. Le serveur décisif n’est pas nécessairement celui qui avait attribué le bail.

Le test porte en outre sur l’ensemble. Une adresse inadaptée suffit à produire NotOnLink. Le code ne désigne pas forcément l’élément fautif. Pour diagnostiquer, l’opérateur doit garder l’entrée complète et, s’il en dispose, l’évaluation détaillée côté serveur.

Ce que l’adéquation au lien laisse intact

Une adresse peut correspondre au préfixe du lien et être déjà employée par un autre nœud. Duplicate Address Detection reste un autre témoin.

Elle peut convenir au lien et ne joindre aucun voisin. Neighbor Unreachability Detection possède ses propres états et sondes.

Elle peut être valide localement sans route utilisable en amont. La connaissance des préfixes par DHCP n’est pas une preuve de livraison.

Elle peut garder un bail valide alors que la session applicative a disparu. Configuration et continuité de service ne sont pas synonymes.

Enfin, le serveur d’origine peut avoir perdu le binding tandis qu’un autre serveur connaît encore la topologie. Success n’atteste aucune continuité entre leurs bases.

La force de Confirm vient justement de cette modestie. Le mécanisme peut être déployé comme une petite convention interopérable sans absorber l’unicité, le routage, la joignabilité et la gestion des baux.

Le parcours de Tomek Mrugalski rend la frontière concrète

La RFC 9915, devenue Internet Standard STD 102 en janvier 2026, porte cinq noms : Tomek Mrugalski, Bernie Volz, Michael C. Richardson, Sheng Jiang et Timothy Winters. Les remerciements montrent un travail encore plus collectif. Être auteur ne donne aucun pouvoir sur les choix d’un constructeur ou d’un réseau.

Le Datatracker de l’IETF retrace chez Mrugalski une longue participation aux RFC DHCP. Un portrait professionnel publié par ISC en 2024 décrit son travail sur Dibbler puis Kea, et relie études, code ouvert et normalisation. Ce document situe l’ingénieur ; il ne mesure pas la conformité mondiale des clients DHCPv6.

Son intérêt pour cet article tient à la jonction entre texte et exécution. La norme permet à un serveur local de donner le minimum d’information nécessaire après un mouvement, sans lui prêter l’autorité de prolonger un bail inconnu. Une implémentation doit ensuite révéler quel chemin elle a suivi.

La Minimum Initial Specification de Heng Lu éclaire ce choix : partager le fait indispensable à l’interopérabilité, laisser les décisions ultérieures aux acteurs qui détiennent le contexte. Running-Code Primacy impose de regarder le client en fonctionnement, car Success, NotOnLink et timeout peuvent laisser la même adresse à l’écran pendant quelques instants.

Le problème d’agence apparaît lorsqu’un fournisseur publie facilement un taux de « Confirm réussi », tandis que l’opérateur doit financer la conservation du contexte de relais et des versions de préfixes, le service de bail celle des bindings, et le client supporte l’expiration. Le producteur du chiffre le moins coûteux ne devrait pas définir seul la promesse la plus large.

Le reçu minimal d’une continuité honnête

Avant l’échange : raison du changement de réseau, interface, adresse, serveur attributaire, IAID, T1, T2, échéances preferred et valid, temps restant.

Pour la requête : DUID client, transaction ID, ensemble complet des adresses, relais et absence volontaire de Server Identifier.

Pour les réponses : DUID de chaque serveur, contexte de lien, configuration utilisée et statut exact. L’expiration sans réponse doit rester un timeout, jamais un Success synthétique.

Pour la décision : au moins un oui, tous les reçus négatifs, ou aucun reçu ; continuation ou nouvelle découverte.

Après : toute opération Renew ou Rebind, nouvelles durées, passage à deprecated puis invalid, résultat de détection de doublon, route et joignabilité.

La phrase publique peut alors rester courte et vraie : « adresses jugées adaptées au lien par S à T ; durées du bail inchangées ». Elle rend au mot Success sa juridiction exacte.

Sources