Résumé

  • RFC 5308 sépare trois informations : TLV 236 décrit l’accessibilité IPv6, TLV 232 porte des adresses dont la portée dépend du type de PDU, et NLPID 142 déclare la prise en charge d’IPv6 par IS-IS.
  • Dans une topologie commune, aucun de ces champs ne prouve seul que tous les nœuds de transit choisis par SPF savent transférer IPv6 ; RFC 5120 permet de rendre l’appartenance topologique explicite, sans remplacer la preuve RIB, FIB et paquet.

Une adjacence réelle peut raconter une capacité trop large

Le piège ne ressemble pas à une route corrompue. Le préfixe est bien formé, la métrique reste dans la plage normale, SPF produit un chemin cohérent et le prochain saut est un voisin IS-IS établi. Pourtant, un nœud intermédiaire peut participer au graphe standard sans fournir la capacité IPv6 que le chemin lui attribue implicitement.

RFC 5308 étend le mécanisme LSP existant afin qu’un seul protocole intra-domaine transporte IPv6 avec IPv4 et OSI. Il n’introduit pas, à lui seul, un graphe distinct pour chaque famille d’adresses. L’adjacence prouve donc une relation de contrôle IS-IS ; elle ne certifie pas l’équivalence de tous les plans de données qui utilisent cette relation.

Le scénario est une déduction des mécanismes normatifs, non le récit d’un incident. Une origine peut publier honnêtement un préfixe IPv6. Un récepteur peut calculer honnêtement le meilleur chemin. Un transit peut être un voisin légitime tout en n’ayant pas la capacité applicable à cette famille, à cette interface ou à cette génération de FIB. Les faits restent vrais séparément, mais leur jointure opérationnelle manque.

Trois codes, trois autorités différentes

Le TLV 236 est le TLV d’accessibilité IPv6. Il contient le préfixe, une métrique sur 32 bits, le bit up/down, le bit d’origine externe et, facultativement, des sous-TLV. Le bit U indique qu’une information a descendu la hiérarchie. Le bit X indique une redistribution depuis un autre protocole. Le bit S indique la présence de sous-TLV. Aucun ne dit qu’un paquet a traversé le chemin.

Le TLV 232 contient des adresses d’interface IPv6, mais sa sémantique dépend du PDU. Dans un Hello, il ne doit contenir que les adresses link-local de l’interface émettrice. Dans un LSP, il ne doit contenir que les adresses non link-local attribuées au système intermédiaire. Supprimer le contexte IIH ou LSP transforme une adresse de voisinage en fausse déclaration de portée globale, ou inversement.

NLPID 142 déclare la prise en charge d’IPv6. Un système qui route IPv6 avec IS-IS doit ajouter cet identifiant au TLV Protocols Supported. Cette déclaration est plus proche de la question de capacité, mais elle appartient encore au processus de routage. Elle ne garantit ni la programmation d’une carte de ligne, ni la bonne table virtuelle, ni la génération courante de FIB.

Présent dans la base ne signifie pas éligible au SPF normal

Le TLV 236 peut apparaître zéro, une ou plusieurs fois dans un LSP. Il ne doit jamais annoncer de préfixe link-local. Le préfixe est compacté : seuls les octets nécessaires à la longueur annoncée sont présents. Une preuve doit donc conserver la longueur et les octets significatifs, pas seulement une chaîne normalisée.

La métrique trace une autre frontière. RFC 5308 reprend MAX_V6_PATH_METRIC, soit 0xFE000000. Si une annonce dépasse cette valeur, le préfixe ne doit pas participer au calcul SPF normal. Il peut être présent pour un autre usage. Le standard crée ainsi explicitement une différence entre visibilité dans le LSP et admissibilité dans la table IPv6 normale.

Une télémétrie fidèle conserve annoncé, reçu, parsable, éligible, préféré, résolu, installé en RIB, programmé en FIB, transféré et livré. Les résumer par « appris » efface le point exact où une assertion de contrôle devient, ou ne devient pas, un chemin de données.

La topologie intégrée a besoin d’un invariant de transit

Dans le graphe standard, l’adjacence et la diffusion des LSP décrivent la connectivité IS-IS. La présence obligatoire de NLPID 142 sur un système compatible donne un signal exploitable, mais RFC 5308 ne retire pas automatiquement du calcul IPv6 tous les systèmes qui ne le déclarent pas. L’exploitation doit donc imposer une règle : tout nœud susceptible de devenir transit dans un chemin IPv6 possède la capacité de contrôle et de transfert correspondante.

Cette règle doit être prouvée sur le chemin choisi. Une case d’inventaire « IPv6 activé » n’est pas assez précise. Le reçu relie le prédécesseur SPF et le prochain saut à l’interface, au contexte de routage, à la version logicielle, à la génération FIB et à une observation de paquet. Avec ECMP, chaque membre éligible appartient au périmètre, pas seulement celui qu’un test chanceux a emprunté.

L’authentification ne complète pas cette preuve. Un LSP intègre et authentique peut décrire exactement un voisin et un préfixe alors que la chaîne de transfert n’est pas prête. L’intégrité de la déclaration et la réalisation de la capacité restent deux propriétés.

La multi-topologie déplace le contrôle vers l’appartenance

RFC 5120 ajoute dans les IIH la liste des topologies auxquelles participe une interface. Sur un lien point à point, si le voisin n’annonce pas un identifiant MT, le routeur local ne doit pas l’inclure dans son LSP pour cette topologie. En l’absence de toute topologie commune, il ne devrait pas former l’adjacence. MT ID 2 est réservé à la topologie de routage IPv6, et TLV 237 ajoute l’identifiant de topologie devant le format d’accessibilité IPv6 du TLV 236.

Le cas du LAN montre pourquoi l’adjacence seule reste insuffisante. Deux routeurs doivent quand même établir une adjacence, même sans MT commune, afin de préserver une élection DIS cohérente. L’accessibilité propre à une topologie doit ensuite être limitée par l’appartenance commune. L’adjacence existe, mais elle ne donne pas le droit d’utiliser le voisin dans chaque graphe.

Séparer IPv4 et IPv6 peut empêcher un équipement mono-famille de devenir transit pour l’autre. Cela ajoute aussi des états : participation MT, overload par topologie, TLV 237, SPF séparé et parfois RIB séparées. Lorsque plusieurs topologies d’une même famille partagent une interface et des adresses qui se recouvrent, RFC 5120 exige un mécanisme local supplémentaire pour choisir la bonne RIB. Le protocole n’effectue pas ce choix à la place de l’opérateur.

La correction de préférence interdit de figer le texte de 2008

RFC 5308 classait initialement les chemins IPv6 en Level 1 up, Level 2 up, Level 2 down puis Level 1 down. RFC 7775 explique ensuite que le modèle sous-jacent ne définit pas de type inter-area Level 2 et que la classe « Level 2 down » n’aurait pas dû être créée ainsi. Il fournit les règles corrigées pour TLV 236 et TLV 237.

Une revue actuelle doit donc utiliser RFC 7775 pour la préférence, tout en conservant les octets et le contexte du LSP original. TLV, topologie, niveau, bits U et X, protocole source, métrique, classe de préférence et génération SPF doivent rester séparés. Une correction normative peut modifier l’interprétation sans modifier le paquet capturé.

Le reçu doit suivre la famille d’adresses jusqu’au dernier saut

Un reçu non secret peut relier identité du nœud, adjacence et type de PDU, identifiant de topologie, TLV Protocols Supported et NLPID IPv6, adresse TLV 232 avec son contexte Hello ou LSP, préfixe TLV 236 ou 237, bits U/X/S, métrique et sous-TLV, génération SPF, prédécesseur et prochain saut, membres ECMP, capacité IPv6 de chaque transit, RIB, génération et résultat de programmation FIB, voisin link-local, chemin de sonde, livraison et décision de repli.

Ce reçu ne rend pas le réseau infaillible. Il empêche simplement un graphe valide d’être présenté comme une preuve de transfert. Le processus de routage a autorité pour décrire une possibilité ; le plan de données doit encore montrer qu’il l’a réalisée dans la bonne famille.

Sources