Résumé

  • La RFC 9805 interdit tout nouvel usage normalisé de l’option IPv6 Router Alert et ferme le registre IANA de ses valeurs, mais elle autorise explicitement la liste exhaustive des protocoles historiques à continuer de l’utiliser.
  • La fermeture du registre prouve une limite imposée au futur travail de normalisation. Seuls la configuration des routeurs, les compteurs, les captures, la télémétrie du plan de contrôle et la migration des protocoles peuvent prouver ce qui arrive encore dans un réseau réel.

Un registre fermé est une vérité administrative. Un processeur qui reçoit encore un paquet marqué appartient à une autre couche de réalité.

La RFC 9805, publiée en juin 2025 sur la voie des normes de l’IETF, organise précisément cette séparation. Elle met à jour la RFC 2711 et énonce une règle à deux branches. Les protocoles déjà autorisés à utiliser l’option IPv6 Router Alert peuvent continuer, y compris dans leurs versions futures. En revanche, aucun protocole nouvellement normalisé ne doit choisir cette option. L’annexe A fixe la liste exhaustive des exceptions historiques.

L’IANA a exécuté la partie qui relève de son autorité. Dans le registre des paramètres IPv6, le type d’option 0x05 porte désormais la mention « Router Alert (DEPRECATED for New Protocols) ». Le registre des valeurs Router Alert indique « Registry closed ». Les anciens codes expérimentaux 65503 à 65534 sont réservés et la valeur 69, consacrée à MPLS OAM, est signalée comme obsolète.

Cette opération ne réécrit aucun micrologiciel, n’efface aucune configuration et ne bloque aucun paquet. Le type 0x05 existe toujours. Les dépendances listées restent permises. Un opérateur doit toujours décider, selon son équipement et ses services, s’il inspecte, limite, ignore ou rejette le trafic portant l’en-tête Hop-by-Hop et l’option Router Alert.

Pour comprendre pourquoi une fermeture sans suppression peut être rationnelle, il faut revenir à l’intention originale. La RFC 2711, publiée en 1999, cherchait à éviter que chaque routeur analyse profondément chaque paquet. Certains datagrammes transportent pourtant une information qu’un routeur de transit doit examiner alors même que l’adresse de destination désigne une autre machine. Router Alert plaçait dans l’en-tête d’options Hop-by-Hop une invitation compacte : ce paquet mérite un regard plus attentif.

L’optimisation déplaçait le coût. Le trafic ordinaire pouvait rester sur le chemin rapide, mais l’émetteur du paquet recevait un moyen de demander une ressource plus rare : l’attention du routeur. La RFC 2711 signalait déjà qu’un usage gratuit pouvait dégrader les performances et que des datagrammes falsifiés pouvaient inonder un équipement. Elle permettait aux routeurs de transit de limiter ces paquets par débit ou par d’autres moyens.

La difficulté n’est donc pas seulement l’existence d’un paquet malveillant. C’est l’absence d’un test universel, peu coûteux et préalable qui séparerait tout trafic Router Alert légitime de tout trafic indésirable. La RFC 6398 décrit ce problème : les adresses source et destination ne suffisent pas à identifier une relation de confiance, et le paquet marqué peut solliciter des routeurs situés au cœur du réseau, pas seulement une frontière administrative.

L’asymétrie matérielle rend cette sollicitation politiquement importante. La RFC 6192 distingue le plan de transfert, souvent construit pour traiter un volume massif de paquets dans du matériel spécialisé, du plan de contrôle, qui exécute des fonctions de routage et de gestion sur des ressources plus générales. Une petite fraction de trafic envoyée au mauvais endroit peut donc consommer une part disproportionnée d’une ressource qui doit rester disponible pour maintenir le réseau lui-même.

Une protection du plan de contrôle est d’autant plus efficace que le classement et la limitation s’effectuent près du matériel de transfert. Router Alert complique ce classement. Comme l’explique la RFC 9805, une liste de contrôle est économique lorsqu’elle peut comparer des champs placés à des positions fixes. Chercher une option dans une chaîne d’en-têtes Hop-by-Hop réclame davantage de travail. Le signal censé économiser l’analyse globale crée ainsi son propre coût d’analyse lorsqu’un opérateur veut se protéger.

Les choix locaux restent imparfaits. Une politique peut reconnaître finement les usages attendus et imposer des plafonds adaptés, au prix d’une configuration plus complexe. Elle peut demander au routeur d’ignorer Router Alert, au risque de rompre une fonction historique qui en dépend. Elle peut rejeter ou limiter sévèrement les paquets contenant des options Hop-by-Hop à l’entrée du réseau, avec un effet de bord plus large. Aucun de ces choix ne devient correct pour tous les réseaux simplement parce que le registre a fermé.

La réforme de la RFC 9805 porte ailleurs : elle empêche le système de normalisation d’agrandir encore cet ensemble de compromis. Une nouvelle spécification ne pourra plus transférer aux futurs opérateurs le coût d’une nouvelle dépendance à Router Alert. Elle devra choisir une autre architecture. Le texte réduit donc l’exposition future à la source, là où une règle commune peut agir sans administrer chaque routeur du monde.

La relation avec la RFC 9673 éclaire ce point. Cette RFC a modernisé le traitement des options IPv6 Hop-by-Hop et pose en général qu’un nœud ne transmet pas par défaut ces options au plan de contrôle. Router Alert demeure une exception parce que demander un examen particulier est sa raison d’être. La RFC 9805 ne nie pas l’exception ; elle en ferme la croissance.

L’annexe A empêche que « historique » devienne une catégorie extensible par interprétation. Elle énumère les usages qui peuvent continuer et décrit leur état. Selon la RFC 9805, seuls Multicast Listener Discovery Version 2, ou MLDv2, et Multicast Router Discovery, ou MRD, connaissent un déploiement étendu. D’autres usages sont limités, expérimentaux, dépourvus d’implémentation IPv6 connue ou déjà abandonnés, comme l’emploi de Router Alert par MPLS Ping.

Il faut lire cette observation avec discipline. Elle n’autorise pas à affirmer qu’un opérateur nommé utilise MLDv2 ou MRD, qu’un modèle de routeur particulier expose son processeur, ou qu’un réseau a supprimé tous les autres usages. Le document caractérise son exception normative ; il ne livre pas un inventaire mondial des configurations en service.

La RFC 9805 laisse également hors de son périmètre la conception de successeurs à MLDv2 et MRD. C’est une limite importante. Interdire une nouvelle dépendance est une décision immédiatement applicable au processus de normalisation. Remplacer une dépendance largement installée exige une spécification, des implémentations, une période de coexistence, des tests, une adoption et des preuves de retrait. Confondre les deux opérations créerait soit une promesse impossible, soit une rupture de service.

La chaîne de preuves utile comporte au moins sept maillons distincts :

  1. la RFC prouve ce que les futurs protocoles normalisés peuvent ou ne peuvent pas faire ;
  2. le registre IANA prouve l’état des noms et des allocations ;
  3. la spécification d’un protocole historique prouve la sémantique qu’il attribue à Router Alert ;
  4. la configuration d’un équipement prouve une politique locale d’inspection, d’ignorance, de limitation ou de rejet ;
  5. les captures et les compteurs prouvent quels paquets marqués ont effectivement circulé ;
  6. la télémétrie des files, des abandons et du processeur prouve la pression ou la protection du plan de contrôle ;
  7. les essais fonctionnels et de migration prouvent qu’un service attendu continue ou qu’un remplacement ne dépend plus de l’option.

Un maillon ne peut pas se faire passer pour le suivant. « Registry closed » n’est pas un compteur à zéro. Une configuration de filtrage n’est pas la preuve que tous les équipements du chemin la possèdent. L’absence de panne visible n’est pas la preuve que le plan de contrôle n’a jamais été sollicité. Une proposition de remplacement n’est pas une migration achevée.

La notice du RFC Editor fournit le statut, la date et la relation avec la RFC 2711. La page des errata permet de vérifier si des corrections officielles modifient ultérieurement une lecture. Ces deux sources ont une autorité documentaire ; aucune n’observe le trafic d’un réseau.

Les références historiques renforcent encore la nécessité de ne pas simplifier. La RFC 4286 décrit MRD. La RFC 9777 fait partie du contexte multicast récent. Elles permettent d’étudier des dépendances précises, mais leur existence ne prouve ni activation locale ni exposition mesurée.

Le modèle de spécification initiale minimale, décision future localisée et adoption volontaire de Heng Lu fournit une lecture cohérente de cette architecture. La règle commune est mince : aucun nouvel usage normalisé, une liste d’exceptions fermée. Les décisions futures restent localisées chez les concepteurs qui doivent inventer des remplacements et chez les opérateurs qui assument les effets de leurs politiques de paquet.

La primauté du code en fonctionnement ajoute le test que le symbole administratif ne peut passer. Une politique n’existe opérationnellement que si les configurations chargées, les chemins matériels, les compteurs et les essais montrent qu’elle s’exécute. Une migration n’existe que si les deux extrémités et les équipements intermédiaires produisent le comportement attendu sans l’ancienne dépendance.

Enfin, les couches de réalité empêchent de transformer une fermeture de registre en certificat de sûreté. La RFC crée une contrainte normative. L’IANA enregistre une clôture administrative. Les routeurs appliquent des décisions techniques. Les services produisent des résultats. Ces réalités se répondent, mais elles ne sont pas interchangeables.

La bonne métaphore n’est donc pas celle d’un interrupteur. La RFC 9805 installe un cliquet : le mécanisme peut encore porter le poids du passé, mais le processus de normalisation ne doit plus ajouter de nouvelles dents dans cette direction. Le reste de la réduction dépend d’un travail plus lent, distribué et vérifiable.

Sources