Résumé

  • La RFC 9631 définit à titre expérimental les en-têtes CRH-16 et CRH-32 : chaque SID court désigne une entrée locale contenant une adresse IPv6, une fonction topologique et, éventuellement, ses arguments.
  • Le même nombre peut recevoir des significations différentes selon le routeur ou l’époque de sa CRH-FIB. Le paquet ne prouve ni la version consultée, ni l’identité de l’auteur de la règle, ni le trajet réellement exécuté.
  • Un reçu défendable relie le CRH à l’état installé de chaque nœud, au contrôle ACL/uRPF, à la réécriture de destination, à la sortie observée et à la réception par l’application.

Le nombre était identique sur les deux routeurs. Sur le premier, il désignait un acheminement au moindre coût. Sur le second, il réveillait une fonction qui imposait une interface précise. Les deux équipements avaient correctement lu le même SID.

Ils n’avaient pas reçu le même ordre.

La RFC 9631 installe cette différence au cœur de son expérience. CRH-16 et CRH-32 rendent plus courte la liste qui guide un paquet IPv6. Ils ne rendent pas cette liste autonome. La compression retire du paquet une partie de son sens et la confie à l’état local.

La brièveté déplace la charge de preuve

Les SID sont inscrits dans l’ordre inverse. Après avoir décrémenté Segments Left, le nœud sélectionne le SID courant et le cherche dans sa CRH-FIB. Le résultat n’est pas une simple adresse. Il réunit une adresse IPv6, une fonction topologique et parfois des paramètres. La fonction peut demander un chemin au moindre coût ou imposer une interface de sortie.

Le SID est donc une clé de lecture, non une instruction complète. La RFC permet en outre une portée locale au nœud : chaque identifiant n’est interprété que par un routeur CRH dont une adresse correspond à la destination du paquet. Rien n’oblige le SID 2 à signifier la même chose ailleurs. Rien ne garantit non plus qu’il conserve son sens après une intervention CLI, une transaction de contrôleur ou une mise à jour de routage.

Il faut conserver l’identité du nœud, l’instant de la recherche, la version installée de la table, l’entrée exacte, sa fonction et ses arguments. Sans cette chaîne, une capture montre le nombre choisi par la source, pas l’autorité qui lui a donné un effet.

La validation s’arrête avant le chemin

Les règles de traitement ferment plusieurs ambiguïtés. Un nœud rejette un en-tête trop grand pour son implémentation. Il calcule sa longueur minimale, refuse une combinaison impossible, rejette un SID absent de la table et interdit une adresse multicast avant le dernier segment. Les erreurs prescrites produisent un message ICMPv6 Parameter Problem.

Ces contrôles prouvent qu’un en-tête appartient au domaine syntaxique accepté. Après eux, le routeur copie l’adresse issue de la table dans la destination IPv6 puis remet le paquet, la fonction et ses arguments au module IPv6. Le choix du prochain saut, de l’interface et le transfert physique surviennent donc après la validation CRH.

L’absence de message ICMPv6 est une preuve encore plus étroite. Le message peut être perdu, filtré ou limité. Une entrée locale peut être valide mais obsolète. L’interface choisie peut tomber après la réécriture. Le destinataire peut recevoir le paquet tandis que l’application le refuse.

L’enquête doit séparer acceptation, recherche, réécriture, décision IPv6, sortie et réception. Un compteur vert placé au début ne peut pas certifier les étapes suivantes.

Qui garde la signification de la table ?

La CRH-FIB peut être remplie par un opérateur en CLI, par un contrôleur utilisant PCEP ou NETCONF, ou par un protocole de routage distribué. La RFC ne normalise pas ces mécanismes. Ce choix maintient le contrat partagé à une taille raisonnable, mais laisse à chaque opérateur la responsabilité de la cohérence.

Une intention de contrôleur n’est pas encore une entrée installée. Une réponse NETCONF réussie peut précéder la programmation du matériel. Une mise à jour distribuée peut atteindre les routeurs à des instants différents. Une restauration manuelle peut remettre le même SID sans restaurer ses paramètres.

Le CRH ne contient aucun numéro de version de table. Pour reconstruire un trajet, il faut joindre la demande de configuration, l’état candidat, l’état installé, la réalisation dans le plan de transfert et la capture. Des horloges imprécises suffisent à attribuer à un paquet l’entrée qui l’a précédé ou celle qui l’a suivi.

L’interopérabilité ne se réduit donc pas à décoder 16 ou 32 bits. La RFC demande justement aux expérimentateurs si deux implémentations proposent les mêmes fonctions et arguments, et si leurs sémantiques sont identiques. Un format commun avec deux effets différents reste une incompatibilité opérationnelle.

Une adresse de confiance ressemble aussi à une adresse usurpée

Dans le modèle de la RFC, deux nœuds se font confiance lorsqu’ils sont exploités par la même partie. Le nœud récepteur déduit cette relation de l’adresse source. Il doit refuser par ACL un CRH venu d’une source non fiable et destiné à une adresse locale.

Cette déduction rencontre immédiatement l’usurpation. EFP-uRPF peut écarter une partie des paquets forgés, jamais tous. Chaque bordure doit en plus bloquer les paquets CRH entrants dont la source imite l’interface d’un nœud réputé fiable.

La confiance n’est donc pas une propriété visible dans le paquet. Elle résulte d’une interface d’entrée, d’une liste de préfixes, d’une version d’ACL, d’une topologie uRPF et d’une décision observée. Il faut prouver que la règle existait sur chaque bord pertinent au moment du passage.

La compatibilité avec Authentication Header ne signe pas l’histoire externe de la CRH-FIB. AH peut protéger le paquet dans son contexte cryptographique ; il ne certifie ni l’installation d’un filtre au bon endroit, ni le chemin réellement parcouru.

Une économie d’octets n’est pas encore un gain mesuré

L’expérience répond à deux contraintes plausibles. Certains ASIC copient les en-têtes de la mémoire tampon vers une mémoire sur puce coûteuse. Et l’imperfection de la découverte de MTU conduit des hôtes à rester sous les 1 280 octets minimaux d’IPv6, où un grand en-tête pèse davantage.

Ces raisons justifient le test, pas sa conclusion. Le bénéfice dépend du silicium, de la profondeur analysée, du nombre de segments, de la taille des charges, des MTU, du traitement ICMPv6 et du trafic. Un format plus court peut encore emprunter un chemin logiciel lent ou rencontrer un nœud qui ne le traite pas.

Comparer exige une base, les mêmes paquets, les versions du matériel et du logiciel, la définition des compteurs, la perte et la latence. « Seize bits » est un fait d’encodage. « Moins coûteux » est un résultat expérimental.

Le statut expérimental protège contre l’autorité empruntée

La RFC 9631 n’est pas une norme Internet. Elle invite à publier les efforts de déploiement, le besoin de synchronisation, les mises à niveau matérielles, la portée des SID, le coût de la sécurité, les performances, l’efficacité des ACL, la méthode de peuplement, l’échelle, l’interopérabilité et l’utilité de l’OAM.

Cette liste définit la dette de preuve. Le fait que ping, traceroute, tcpdump ou Wireshark reconnaissent le CRH aide à observer ; il ne prouve pas que deux fonctions ont le même sens ou que l’application a reçu le résultat attendu.

Un rapport honnête attribue chaque assertion à son témoin. Le parseur atteste la lecture. Le relevé FIB atteste un état local à un instant. La capture de sortie atteste un transfert. Le destinataire atteste une arrivée. Seule leur jointure peut soutenir le récit d’un chemin.

Sources