Résumé

  • Le RFC 9673 actualise le RFC 8200 afin que les routeurs puissent traiter sélectivement les options Hop-by-Hop sans sacrifier leur capacité globale de transfert.
  • Un équipement peut transmettre normalement un paquet tout en ignorant une option non activée ou trop coûteuse ; l’arrivée à destination n’atteste donc pas l’exécution à chaque saut.
  • La preuve utile relie plateforme, build, table d’options autorisées, ordre et taille du paquet, route et heure, observation par nœud, effet sur le forwarding et résultat du service.

Le tableau de bord n’avait signalé ni perte ni surcharge. L’équipe en avait déduit que l’option Hop-by-Hop avait été prise en charge. L’explication du routeur était moins spectaculaire : il avait maintenu le trafic au vert en transférant le paquet sans exécuter l’option attendue.

Ce comportement peut être conforme au modèle du RFC 9673. Le texte met à jour le RFC 8200 pour rendre le traitement Hop-by-Hop compatible avec les contraintes de routeurs modernes. Il ne rétablit pas une obligation irréaliste selon laquelle chaque nœud ferait le même travail. Il organise au contraire une coexistence entre transfert, traitement sélectif et protection des ressources.

La norme commune ne promet pas une action uniforme

Les premières versions d’IPv6 demandaient à tous les nœuds d’examiner l’en-tête Hop-by-Hop. À haut débit, un traitement spécial peut quitter le chemin rapide, consommer des ressources générales ou concurrencer le plan de contrôle. Le RFC 7045 a décrit cette réalité opérationnelle. Le RFC 7872 a mesuré des pertes importantes pour plusieurs chaînes d’en-têtes d’extension ; les RFC 9098 et RFC 9288 encadrent les conséquences opérationnelles et le filtrage. Ces travaux signalent un risque ; ils ne donnent pas l’état d’un chemin actuel sans mesure.

Le RFC 9673 précise qu’un routeur qui ne traite pas l’en-tête doit normalement poursuivre l’acheminement selon les en-têtes suivants. Il ne doit pas supprimer le paquet pour la seule présence de Hop-by-Hop, sous réserve d’une exception configurée destinée à protéger un équipement aval incapable de se comporter correctement.

La conséquence probatoire est directe. Le paquet peut arriver parce que l’option a été exécutée, parce qu’elle a été ignorée, ou parce que seuls certains nœuds l’ont traitée. L’état vert du forwarding décrit le forwarding. Il n’est pas un journal d’exécution distribué.

Le budget appartient au routeur, pas au slogan

Le RFC définit le « débit de transfert maximal » comme un traitement qui n’affecte pas négativement la capacité agrégée. Il refuse pourtant de fixer un nombre universel d’options ou d’octets. Ce choix évite de faire passer une limite propre à une architecture pour une constante d’Internet.

La plateforme, le parser, le logiciel, l’ordre des options, leur sémantique, le débit et la charge concurrente influencent le coût. Le texte recommande de ne pas activer le traitement de la première option s’il dégrade le débit agrégé ; les options suivantes ne devraient être traitées que si elles respectent la même contrainte. Une table locale des types traitables au plein débit constitue une approche possible.

Cette table est un bon artefact à condition de la nommer correctement. Elle prouve une déclaration de capacité ou de politique pour un modèle, un build et une génération de configuration. Elle ne prouve ni son déploiement partout, ni le passage du flux par ces équipements, ni l’exécution de l’option dans le paquet observé.

Il faut donc enregistrer le « budget » avec ses dimensions : matériel, version, interface, type d’option, position, longueur totale, débit d’essai, chemin rapide ou lent, limiteur et période. Transformer ces variables en un badge « compatible RFC 9673 » détruirait précisément la clarté que la norme cherche à restaurer.

L’ordre des options devient un choix de priorité

La source peut n’émettre qu’une option ou limiter la taille totale. Lorsqu’elle en place plusieurs, le RFC l’incite à les ordonner par importance décroissante, car un routeur peut n’en traiter qu’une ou un nombre restreint.

Une équipe peut donc déployer deux fonctions toutes deux enregistrées et obtenir une réalité différente selon leur ordre. Si une option diagnostique vient avant celle dont dépend le service, un routeur limité à la première peut satisfaire sa politique locale sans produire la valeur attendue. Le registre IANA des paramètres IPv6 attribue les types ; il n’atteste ni l’implémentation, ni l’activation, ni l’exécution.

Le RFC 9673 assouplit aussi, pour les routeurs, certaines conséquences des bits d’action lorsqu’une option n’est pas traitée : le rejet et l’envoi d’ICMP deviennent dépendants de la configuration dans les cas prévus. Le sujet distinct des bits d’une option inconnue existe déjà ailleurs. Ici, le point de contrôle est la dépense de travail locale.

Le silence ICMP ne signe rien

Le RFC 4443 définit les erreurs ICMPv6. Un message Parameter Problem reçu peut révéler qu’au moins un nœud n’a pas reconnu l’option. Mais aucun message ne signifie pas « tous les nœuds ont traité ». La génération peut être désactivée, limitée ou coûteuse ; le retour peut être filtré ou perdu ; le routeur peut simplement avoir transféré sans agir.

Le Router Alert illustre le risque de confondre demande et exécution. Le RFC 6398 analyse l’exposition du chemin lent. RFC 9673 conserve Router Alert comme exception vers le plan de contrôle, avec protection, filtrage de confiance et limitation de débit. Il ne faut pas en faire le protagoniste de toutes les options : son cas montre seulement qu’une instruction dans un paquet ne peut pas disposer librement des ressources du routeur.

Une preuve plus forte associe un compteur par nœud, le type exact, le build, la politique chargée, l’interface et l’horodatage. Elle peut encore nécessiter un test de résultat : un compteur d’analyse ne prouve pas que le service a bénéficié de l’action.

Une course mesure une route et une date

Le RFC propose une adoption incrémentale robuste : envoyer un paquet d’essai avec l’option, comparer avec un paquet sans option, attendre l’accusé avant d’étendre l’usage et renoncer à la fonction si le chemin échoue. Dans un domaine limité au sens du RFC 8799, les nœuds peuvent être administrés ensemble ; sur Internet, cette maîtrise disparaît.

La course remplace une hypothèse par une observation. Elle ne transforme pas cette observation en propriété éternelle. Un changement de route, d’ECMP, de logiciel ou de politique change les sujets. Le dossier doit conserver les octets exacts, l’ordre, la taille, les extrémités, les identifiants de flux, les temps, la route connue, les réponses, les ICMP et la télémétrie par saut.

Le mérite du RFC 9673 est d’accepter cette pluralité sans renoncer à un socle commun. Les nouvelles options devraient être simples, rapides, courtes, aisément ignorables et utiles même lorsque tous les nœuds ne les traitent pas. La norme rend le refus compatible avec le transit ; l’exploitation doit rendre ce refus observable.

Sources