Summary

  • draft-ietf-rtgwg-dst-src-routing-revive-06 fait du préfixe source une partie de l’identité et de la recherche de route ; ce n’est pas une simple annotation.
  • Dans un réseau mixte, la présence de la route ne prouve pas que le prochain saut comprend cette contrainte. Il faut conserver un îlot capable, démontrer la progression ou abandonner explicitement le paquet.

Deux routeurs peuvent être d’accord sur la destination D et néanmoins parler de deux routes différentes. Le premier choisit B parce que le paquet vient de S. Le second ne connaît que D et le renvoie vers le premier. Chaque table paraît cohérente dans son propre référentiel ; ensemble, elles fabriquent une boucle persistante.

Le projet RTGWG, daté du 16 septembre 2026, reste un Internet-Draft. Il définit une recherche IPv6 où chaque entrée se comporte comme si elle portait un préfixe source, ::/0 servant de valeur générale. On cherche d’abord la destination la plus spécifique, puis la source la plus spécifique pour cette destination. Si aucune source ne correspond, la recherche reprend à une destination moins spécifique. Inverser l’ordre changerait la politique de transfert.

La conséquence opérationnelle est nette : l’objet à vérifier n’est plus « D est présent », mais le couple destination-source, sa résolution, son prochain saut et la continuité de cette sémantique.

La frontière de capacité est une décision de transfert

Un routeur non compatible ne rejette pas forcément la nouveauté. Il peut traiter le paquet selon une règle plus grossière et masquer la perte de sens. Le projet impose donc aux extensions de protocole de préserver l’absence de boucle. Trois issues existent : rester dans une topologie capable ; utiliser un voisin ancien seulement si la métrique prouve une progression sûre ; ou déclarer la route inaccessible et jeter le paquet.

Le trou noir explicite peut sembler être un échec, mais il borne l’échec. La boucle consomme des ressources et transforme une incompatibilité connue en panne variable.

Dans un protocole à vecteur de distance, le voisin qui propage l’information est aussi celui qui transfère normalement le trafic ; une négociation de capacité peut donc aider, à condition que chemins de contrôle et de données coïncident. Dans un protocole à état de liens, recevoir et diffuser une information ne prouve pas qu’un nœud sait l’utiliser. Le calcul SPF doit soit exclure les nœuds incapables dans une topologie séparée, soit convertir le chemin dangereux en trou noir.

Installer le logiciel avant d’activer les routes

La révision 06 distingue deux opérations : déployer la capacité, puis introduire les routes qualifiées par la source. Tant qu’aucune de ces routes n’existe, un routeur capable se comporte comme un routeur classique. Le projet recommande donc fortement de mettre à niveau tout le domaine avant l’activation.

Un inventaire de versions ne clôt pas cette étape. Il faut conserver la version réellement exécutée, l’état de la fonction, les limites de table, la capacité des voisins et un essai de transfert. Le retour arrière doit suivre l’ordre inverse : retirer les routes nouvelles avant de retirer le code qui les comprend.

L’annexe d’implémentation cite CONFIG_IPV6_SUBTREES sous Linux, FRRouting, babeld, un réseau expérimental et vingt routeurs CERNET mis à niveau. Ce sont des déclarations des auteurs du projet, non une mesure indépendante de production.

Une ligne de table n’est que le premier reçu

La table de routage doit afficher les routes destination/source près de leurs parentes destination-seule. Mais cette ligne ne prouve ni la résolution récursive, ni la programmation du FIB, ni la capacité des sauts suivants, ni la livraison.

Le dossier probant doit séparer : identité de la spécification ; logiciel en cours d’exécution ; capacité du voisinage ; route installée et époque de politique ; résultat récursif et action FIB ; chemin capable ou abandon intentionnel ; observation de paquets S–D ; résultat du service. Aucun maillon ne prouve le suivant. Même un test vers D est hors sujet s’il n’enregistre pas la source utilisée.

Le cadre de Heng Lu éclaire bien cette séparation. La couche commune doit fixer le minimum déterministe — identité de route, ordre de recherche, absence de boucle — sans transformer la publication en obligation d’activation. L’adoption est locale ; la compatibilité d’un chemin, elle, doit être démontrée par le code en fonctionnement.

Sources