Résumé

  • Publié sur la voie normative de l’IETF en août 2026, RFC 10038 ajoute à DHCPv6 l’option 149 pour l’association d’identité d’un locator SRv6, l’option 150 pour le locator lui-même et le code d’état 23 lorsqu’aucune ressource n’est disponible.
  • Le serveur décide d’une allocation dans un domaine SR de confiance. La configuration du client, l’installation de route, l’annonce IGP, la sélection RIB, la programmation FIB, le comportement SID, les filtres, le résultat des paquets et le retrait relèvent encore d’actes et de preuves distincts.

Le cas le plus révélateur n’est pas l’activation, mais la réutilisation. Un locator arrive à expiration à 10 h 00 et réapparaît aussitôt comme libre dans le pool. À 10 h 01, un ancien routeur conserve encore une entrée de transfert ; à 10 h 02, une route agrégée conduit toujours le trafic vers le bord délégant ; à 10 h 03, l’ancien équipement reconnaît encore un SID local. La base de baux est cohérente et pourtant la ressource n’est pas encore sûre à réattribuer.

RFC 10038 encadre précisément la première moitié de ce cycle. Il décrit la distribution, par DHCPv6, d’un SRv6 Locator à un nœud de terminaison de segments dans un même domaine SR de confiance. Le texte a été publié en août 2026 et ses nouveaux numéros figurent dans le registre IANA des paramètres DHCPv6.

L’option 149, OPTION_IA_SRV6_LOCATOR, contient un IAID, T1, T2 et des sous-options. Plusieurs associations peuvent figurer dans le message ; leurs IAID sont uniques dans un espace distinct de celui des autres types d’IA. L’option 150, OPTION_IALOCATOR, doit être imbriquée dans la première. Elle transporte les durées préférée et valide, Algorithm, LB-Len, LN-Len, Fun-Len, Arg-Len, puis l’encodage minimal du locator.

LB-Len plus LN-Len donne la longueur du locator. La somme des quatre longueurs ne peut dépasser 128 et la longueur du locator ne peut être nulle. Une option invalide est écartée sans autoriser l’automatisation à inventer les états manquants.

La négociation laisse la politique au serveur

Le client envoie normalement T1, T2 et les durées préférée et valide à zéro. Le serveur ignore les valeurs que le client tenterait d’imposer dans ces champs. Il peut recevoir une préférence de taille — LB-Len et LN-Len non nuls accompagnés de :: — mais cette préférence ne constitue ni une réservation ni un droit sur un préfixe.

L’allocation découle de la politique, de la configuration et du propriétaire du pool. Le serveur peut accorder plusieurs locators, les refuser ou répondre NoSRv6LocatorAvail, code 23. Le client doit rejeter un locator dont la durée préférée dépasse la durée valide. Il ne doit tirer aucune logique de service de l’ordre des locators.

La mécanique générale de RFC 9915 apporte Solicit, Request, Advertise, Reply, Renew, Rebind et Release. Elle prouve qu’un échange et une association d’identité ont eu lieu. Elle ne contient pas l’accusé de réception d’un protocole de routage. La formulation exacte d’un tableau d’exploitation devrait donc être « liaison créée par tel serveur selon telle politique », et non « réseau joignable ».

Un locator n’est d’ailleurs ni une adresse d’hôte ordinaire ni un service complet. RFC 8402 pose l’architecture Segment Routing ; RFC 8986 décrit la structure des SID et les comportements de terminaison. RFC 10038 laisse hors périmètre l’attribution locale des SID, l’usage de plusieurs locators et l’annonce de SID individuels. Le nœud destinataire garde le pouvoir de créer ou non la fonction locale attendue.

Après le bail commence une autre chaîne d’autorité

Le relais ou le serveur DHCPv6 peut installer une route locale vers le locator, avec comme prochain saut le demandeur. Il peut ensuite annoncer cette route par un protocole traditionnel. Le verbe « peut » compte deux fois : ni la route locale ni l’annonce ne sont le prolongement automatique du Reply.

Une annonce émise traverse ensuite les décisions d’authentification, d’importation et de calcul de chaque opérateur. Une RIB peut la sélectionner ; une autre peut la filtrer. Une FIB peut prendre du retard, manquer de ressources ou programmer un prochain saut inattendu. Le plan de contrôle du point d’origine ne certifie pas les plans de données distants.

Avec Algorithm égal à zéro, la joignabilité suit celle d’un préfixe IPv6 ordinaire. Une valeur non nulle exige les TLV de locator indiqués par RFC 10038. RFC 9350 montre comment les Flexible Algorithms portent des contraintes topologiques. Annoncer seulement les bits du préfixe peut donc conserver l’adresse tout en effaçant l’intention de calcul.

À l’arrivée, RFC 8754 encadre l’en-tête de routage par segments IPv6 et RFC 8986 les comportements. Un paquet peut atteindre le bon nœud sans rencontrer le SID prévu, ou rencontrer une fonction locale différente. Un filtre peut aussi l’écarter à juste titre. Le bail, la route et l’autorisation de service ne sont pas interchangeables.

Libérer exige de fermer plusieurs réalités

Lors d’un Release valide, le relais ou serveur allocateur doit libérer la liaison, supprimer la route locale et retirer l’annonce qu’il avait émise. Ces opérations n’ont pas une horloge transactionnelle commune. La disparition de la ligne de base ne prouve pas la convergence de toutes les RIB et FIB, ni l’effacement de chaque comportement local.

L’IA n’a pas de durée indépendante : elle expire lorsque tous ses locators ont expiré. T1 ramène d’abord le client vers le serveur d’origine ; T2 élargit le renouvellement à un serveur disponible. Les durées préférée et valide sont des secondes restantes ; 0xffffffff signifie l’infini. Ces nombres pilotent l’état du bail, pas la dernière circulation d’un paquet.

Une route agrégée peut maintenir la joignabilité du bord après retrait d’un locator plus spécifique. Le point délégant doit alors éliminer, sur l’interface tournée vers le client, les paquets destinés aux préfixes qui ne sont plus délégués. Sans cette barrière, un ancien flux peut survivre derrière l’agrégat et croiser le prochain titulaire.

La quarantaine avant réutilisation doit donc réunir : liaison close, route locale supprimée, annonce retirée, observations RIB/FIB distantes revenues à l’état prévu, SID local effacé, trafic ancien silencieux et trafic interdit effectivement bloqué.

Le domaine de confiance ne remplace pas la protection

Le périmètre de confiance de RFC 10038 limite le scénario de déploiement ; il ne chiffre pas universellement DHCPv6 et n’authentifie pas magiquement tous les paquets. Le détournement, l’altération et l’écoute restent possibles sans protections complémentaires. Un CPE de bord a besoin de filtres côté interne et externe. L’espace des locators d’infrastructure doit pouvoir être distingué des adresses ordinaires des utilisateurs.

Deux systèmes d’allocation produiront un doublon si leurs pools ne sont pas séparés. Une limite par client ne résiste pas nécessairement à un acteur qui se présente sous de nombreuses identités. Les recommandations de RFC 7227 et RFC 8168 rappellent qu’un nouveau code et une sémantique d’adresse doivent être gérés avec discipline. Les considérations opérationnelles de RFC 8987 replacent la programmabilité SRv6 dans son contexte réel. L’enregistrement IANA rend le vocabulaire commun ; il ne valide ni l’exclusivité du pool ni le filtrage.

La preuve finale est un rapprochement, pas un voyant

Le dossier doit relier DUID, IAID, port ou relais, autorisation, politique, préférence demandée, locator accordé, transaction, durées, T1/T2, propriétaire du pool, SID locaux, route RIB/FIB du point d’origine, annonce IGP, algorithme, versions, observations distantes, filtres, canaris permis et interdits, puis Release ou expiration, retrait, dernier paquet, quarantaine et réattribution.

La primauté du code en fonctionnement défendue par Heng Lu place la décision dans cette trajectoire exécutée. Sa distinction entre souveraineté technique et pratique des données explique pourquoi posséder le registre de baux ne donne pas le contrôle de toutes les copies de route. Son principe de spécification initiale minimale et décisions futures localisées décrit exactement le partage : le protocole fixe une grammaire commune ; chaque opérateur répond de ses choix et de leurs effets.

RFC 10038 rend l’allocation vérifiable. La joignabilité, elle, doit encore être gagnée.