Résumé

  • La RFC 10038 permet à un point terminal SRv6 d’obtenir par DHCPv6 un localisateur structuré, avec durées de vie, algorithme et découpage interne.
  • Puisque l’attribution peut provoquer l’installation et l’annonce d’une route, renouvellement, libération et expiration deviennent des événements de routage.

Le bail qui fonde les SID

Le localisateur SRv6 n’est pas une simple adresse d’interface. Il définit l’espace dans lequel le nœud attribue ses Segment Identifiers. La RFC 10038 transporte cette structure dans deux nouvelles options DHCPv6. L’IA Locator contient les durées de vie préférée et valide, un identifiant d’algorithme IGP, les longueurs du bloc et de la partie nœud, celles de la fonction et de l’argument, puis les octets du localisateur.

Le client peut indiquer une préférence, mais le serveur cherche dans son pool configuré et crée l’association selon sa politique. La somme des longueurs ne doit pas dépasser 128 bits, tandis que la somme du bloc et de la partie nœud doit être supérieure à zéro. Le client doit rejeter un localisateur dont la durée de vie préférée dépasse la durée de vie valide. Ces règles ne prouvent pas qu’un produit donné les applique correctement.

L’IANA a attribué les codes d’option 149 et 150 ainsi que le code d’état 23 NoSRv6LocatorAvail. L’épuisement du pool est donc un résultat explicite, pas une autorisation d’inventer localement un préfixe.

Quand le bail modifie la route

Le cycle reprend DHCPv6 : Solicit, Advertise, Request et Reply établissent l’association ; Renew et Rebind cherchent à la prolonger ; Release y met fin. Si aucune réponse n’arrive avant l’expiration prévue, le client considère le bail terminé et recommence l’acquisition. Le serveur récupère le locator après une libération valide ou l’expiration.

La RFC 10038 relie ensuite ce cycle au routage. Un serveur ou un relais peut installer une route locale vers le locator attribué, avec le client comme prochain saut, puis l’annoncer dans un IGP. Une libération impose de supprimer la route locale et de retirer l’annonce. Un locator associé à l’algorithme zéro peut être annoncé comme joignabilité IP ordinaire ; une valeur non nulle doit utiliser les TLV de locator définis pour IS-IS ou OSPFv3.

Il en découle une inférence opérationnelle : bail, entrée RIB et annonce IGP représentent une même décision d’autorité. Ils peuvent néanmoins diverger dans une mise en œuvre. Une réponse DHCP réussie ne prouve ni l’installation, ni la propagation, ni la programmation du plan de données, ni l’accessibilité de bout en bout. Aucun incident n’est attribué à un réseau réel.

L’agrégation déplace la panne

La RFC décrit un arbitrage de stabilité. Une route agrégée peut limiter les variations de la RIB lorsque les baux individuels changent. Elle peut toutefois continuer à couvrir un locator particulier après sa libération ; les paquets visant ce préfixe non délégué peuvent alors être abandonnés à l’interface tournée vers le client.

Le résumé de routage ne prouve donc pas l’autorité de chaque bail situé dessous. La supervision doit conserver deux vues : la politique d’agrégation qui protège la RIB et l’état de l’association qui explique si un locator précis doit encore aboutir sur un endpoint précis.

La sécurité commence par le droit d’attribuer

La RFC 10038 reprend les risques DHCP et rappelle l’absence de chiffrement de bout en bout entre client et serveur, avec possibilité de détournement, d’altération ou d’écoute lorsque d’autres protections manquent. Elle avertit aussi que plusieurs mécanismes d’attribution peuvent donner le même locator à deux appareils. Séparer les pools constitue une mesure possible.

Un échange valide ne prouve pas l’autorisation organisationnelle. Il faut encore savoir quel serveur et quel relais étaient approuvés, quelle identité client a été admise, quel pool et quel algorithme ont été autorisés et quel changement explique l’association.

Sources