Résumé

  • La RFC 10038 crée pour les locators SRv6 une association d’identité DHCPv6 avec IAID, structure du locator, durées préférée et valide, échéances T1/T2, liaison côté serveur et état explicite d’indisponibilité.
  • Le Reply valide permet au client de configurer un locator. L’installation de la route locale et son annonce sont des opérations distinctes et facultatives ; la création des SID locaux et leur annonce restent hors du périmètre du document.
  • Weiqiang Cheng et Changwang Lin sont les éditeurs de cette œuvre collective, avec Ruibo Han, Daniel Voyer et Geng Zhang comme coauteurs et Yuanxiang Qiu comme contributeur. Son intérêt opérationnel tient à la séparation des preuves, pas à une attribution individuelle de l’invention ou du déploiement.

Le cas le plus révélateur commence à la fin du bail. Un client libère son locator, le serveur efface la liaison, mais l’agrégat qui couvre le préfixe reste visible dans le réseau. Un observateur pressé conclut que le retrait a échoué. Un autre conclut que le locator est encore joignable. Les deux conclusions dépassent ce que montre l’agrégat.

La RFC 10038 prévoit justement que certains opérateurs annoncent un agrégat plutôt que chaque locator, afin de maîtriser la taille de la RIB. Lorsqu’un locator particulier n’est plus délégué, le routeur délégant peut rejeter les paquets correspondants tout en continuant d’annoncer l’ensemble. La présence de l’agrégat décrit une portée de routage ; elle ne ressuscite pas le bail individuel.

Cette distinction résume la portée de la norme publiée en août 2026 sur la voie Standards Track de l’IETF. Le document ne transforme pas DHCPv6 en protocole de routage. Il définit une façon structurée d’attribuer un locator SRv6 à un nœud d’extrémité, puis décrit les obligations et les choix qui relient cette attribution aux autres plans d’exploitation.

L’attribution personnelle doit rester aussi précise que l’attribution technique. Weiqiang Cheng et Changwang Lin ont édité la RFC ; Ruibo Han, Daniel Voyer et Geng Zhang en sont également auteurs, et Yuanxiang Qiu est contributeur. Le profil IETF de Cheng, saisi le 31 août 2026, le présentait comme Chief Architect of IP Networks au China Mobile Research Institute, président du groupe SRv6 Operations et auteur de neuf RFC. Ce dossier public justifie de suivre sa contribution. Il ne prouve aucun déploiement chez China Mobile ni chez un autre opérateur.

Une association, pas seulement un préfixe

L’option IA_SRV6_LOCATOR donne une identité à la relation entre client et locator. L’IAID distingue plusieurs associations d’un même client. T1 fixe le moment où celui-ci doit revenir vers le serveur d’origine ; T2 marque le recours possible à tout serveur disponible. Le locator encapsulé porte ses durées préférée et valide, la longueur des parties locator-block, locator-node, fonction et argument, ainsi qu’une valeur Algorithm.

Ce niveau de détail évite qu’un simple préfixe copié dans un inventaire perde son histoire. Pour comprendre son état, il faut connaître le client, le relais, le serveur, l’IAID, la réponse, les valeurs temporelles et la politique qui a autorisé la liaison. La valeur NoSRv6LocatorAvail distingue l’absence de ressource attribuable d’un silence réseau. Une opération peut donc échouer proprement au lieu d’être reconstruite par supposition.

Le temps modifie le sens de l’objet. Avant T1, le client utilise normalement le bail. Entre T1 et T2, il tente de le prolonger auprès du serveur d’origine. Après T2, il peut solliciter un autre serveur. La durée préférée peut se terminer avant la durée valide. À l’expiration, le serveur récupère la ressource et supprime sa liaison. Un tableau qui n’affiche que « présent » ou « absent » efface cette progression.

Après un Reply valide, le client configure automatiquement le locator. Pourtant, la RFC ferme immédiatement plusieurs inférences. Elle ne spécifie pas comment fabriquer les SID locaux à partir du locator, comment exploiter plusieurs locators ni comment annoncer ces SID au reste du réseau. Elle interdit aussi de déduire une logique de service de l’ordre des locators. L’identité de l’association permet la coordination ; elle ne décide pas toute la politique locale.

L’installation de route est un acte séparé

La section 5.5 décrit le passage éventuel au routage. Le relais ou le serveur DHCPv6 peut installer localement une route correspondant au locator, avec le client demandeur comme prochain saut. Il peut ensuite l’annoncer par un protocole de routage traditionnel afin que d’autres routeurs l’apprennent.

Ces verbes facultatifs sont le cœur de la frontière. Le serveur peut avoir créé une liaison exacte sans qu’une route ait été installée. La route peut exister localement sans franchir une politique d’export. Une annonce peut être émise sans que tous les routeurs aient convergé. Une convergence complète ne dit toujours pas si les SID et la politique SR sont programmés sur le CPE. Enfin, ces états de contrôle ne livrent pas eux-mêmes un paquet.

La valeur Algorithm détermine aussi la forme de l’annonce. Zéro autorise une reachability IP ordinaire. Une valeur non nulle exige les Locator TLV définis pour IS-IS ou OSPFv3. Traiter toute allocation comme un simple préfixe IPv6 détruirait donc un élément de sens nécessaire au calcul.

Une preuve exploitable doit conserver chaque étape : liaison serveur, configuration client, route dans la RIB, programmation de la FIB, type d’annonce, état de convergence, SID et politique locaux, puis observation du trafic. La corrélation relie ces éléments ; elle ne les fusionne pas. Lorsqu’ils divergent, la divergence indique où enquêter.

Libérer signifie défaire les conséquences

La RFC impose une séquence nette lors d’une Release : libérer le locator, retirer la route locale et retirer l’annonce précédente. L’expiration provoque également la récupération de la ressource et la suppression de la liaison. Sur le papier, la relation est concise. Dans un réseau, elle traverse plusieurs propriétaires et plusieurs mémoires.

Le serveur possède la liaison. Le relais ou l’équipement d’accès possède le prochain saut. L’équipe routage possède l’export et la convergence. Le CPE possède les SID et les politiques. Des contrôleurs peuvent avoir mis en cache le locator. Une preuve de retrait doit donc montrer quel IAID a pris fin, quelles routes en dépendaient, quelle annonce a changé et quels consommateurs ont invalidé leur état.

L’agrégation empêche de prendre le retrait d’un préfixe spécifique comme seul critère. Si l’agrégat reste volontairement actif, le contrôle pertinent devient la liste des délégations encore valides et le rejet des autres. Un test de paquet vers un locator expiré peut aboutir au routeur délégant puis être rejeté comme prévu. Pour juger ce résultat, il faut connaître à la fois la route agrégée et l’état individuel du bail.

La confiance déclarée a besoin de filtres

Le scénario suppose un seul domaine SR de confiance. Le CPE doit être géré par l’opérateur ou par un partenaire de confiance ; s’il se trouve chez le client, l’appareil et ses ports restent sous le domaine administratif de l’opérateur. Cette hypothèse réduit le périmètre, mais ne chiffre pas automatiquement DHCPv6 et ne neutralise pas un client malveillant.

La RFC reprend les risques de détournement, d’altération et d’écoute liés à l’absence de chiffrement de bout en bout par défaut. Elle recommande de séparer les pools lorsque plusieurs mécanismes d’allocation coexistent, faute de quoi deux appareils peuvent recevoir le même locator. Une limite par client n’empêche pas un acteur hostile d’imiter plusieurs clients et d’épuiser le pool.

Le CPE frontal doit donc filtrer ses interfaces internes et externes conformément au modèle de sécurité SRH. « Dans le domaine de confiance » n’est pas une preuve suffisante. La gestion du port, la séparation des espaces, la politique du serveur et les filtres sont des contrôles vérifiables, chacun susceptible de dériver.

Du bail au fait observable

La primauté du code en fonctionnement formulée par Heng Lu invite à tester les déclarations contre l’état exécutable. Sa règle de spécification initiale minimale ajoute une contrainte saine : rendre strict ce qui doit être commun, sans transformer la couche commune en autorité sur les choix futurs de chaque opérateur.

La RFC 10038 fournit précisément un contrat commun limité : codes, formats, temps, comportements client-serveur-relais, libération et frontière de routage. Elle ne prétend pas choisir le plan de SID, la politique de service, l’agrégation ou le protocole de chaque réseau. Cette retenue ne rend pas l’exploitation aveugle. Elle exige au contraire que les systèmes locaux produisent leurs propres preuves.

Le reçu complet associe client et IAID, serveur et relais, locator et structure, Algorithm, T1/T2, durées, liaison, configuration client, route, type d’annonce, convergence, SID, politique, filtres et test contrôlé. La formule finale peut alors rester honnête : un bail a été accordé ; une route distincte a été installée ; son état a été diffusé ; un résultat de transfert a été observé sous des conditions identifiées.

Le travail collectif auquel Cheng a contribué donne une durée et une identité au premier maillon. Il ne lui confère pas le pouvoir de garantir les suivants — et c’est précisément pourquoi il aide à les auditer.

Sources