Résumé

  • Le RFC 9947 limite son TLV SRH expérimental d’Alternate Marking à un domaine SR contrôlé, tout en prévoyant que les résultats d’essais sur trafic réel soient transmis à l’Independent Submissions Editor ou au groupe IETF SPRING. Empêcher un paquet de sortir et autoriser la publication d’une preuve relèvent de deux contrôles distincts.
  • Un résultat exploitable devrait porter un reçu de sortie : autorité de publication, versions du texte et de l’implémentation, code expérimental, fonctions testées, référence comparative, cohortes de matériels, échantillonnage, incertitudes, échecs, transformations de confidentialité, empreintes et corrections — sans livrer trafic brut, identités de clients ni topologie exploitable.

La destination publique fait partie de l’expérience

Le RFC 9947 est paru en mars 2026 dans l’Independent Stream, avec le statut Experimental. Son extension n’a pas été élaborée par l’IETF, ne représente pas son consensus et ne vise aucun niveau d’Internet Standard. Elle propose, pour SRv6, de placer les données d’Alternate Marking dans un TLV du Segment Routing Header.

Le point de comparaison est le RFC 9343, document Standards Track qui transporte ces données dans une option IPv6 Hop-by-Hop ou Destination. Le nouveau texte ne l’abroge pas. Il organise une expérience concurrente : le TLV SRH survit-il mieux dans le réseau ? Son traitement accélère-t-il ou ralentit-il les équipements ? L’effet varie-t-il selon l’architecture du plan de transfert ? Les fonctions SID et la programmation SRv6 normale continuent-elles de marcher ? Les champs étendus apportent-ils un avantage opérationnel face aux autres formes de télémétrie sur le chemin ?

Ces questions sont conçues pour recevoir une réponse après publication. Le RFC invite les chercheurs à communiquer leurs évaluations à l’Independent Submissions Editor ou au groupe SPRING sous forme d’Internet-Drafts, et prévoit de premiers résultats dans les deux ans. Cette durée est une attente encore ouverte, non un délai déjà violé.

Une phrase du texte contient toute la difficulté institutionnelle. L’essai devrait tenir dans le réseau d’un seul fournisseur de services, à la fois pour respecter le domaine SR et parce que les données de performance recueillies le long des paquets ne se partagent pas sans limites. Le lieu d’expérimentation protège donc les données mêmes dont le débat public a besoin pour arbitrer.

Le domaine contrôlé est une enceinte technique

La règle de déploiement est ferme. L’Alternate Marking décrit ici doit rester dans un domaine contrôlé correspondant au domaine SR. Un seul opérateur choisit de l’activer et le configure selon ses besoins. Les nœuds sont administrés localement, l’accès est maîtrisé, et les paquets qui portent le TLV AltMark sont empêchés d’entrer ou de sortir.

La valeur du type TLV est prise dans la plage expérimentale 124–126. Tous les participants doivent coordonner cette valeur. Elle devrait rester configurable afin que plusieurs essais puissent coexister sans collision. Le RFC ne sollicite aucune action de l’IANA : le nombre local est un paramètre d’expérience, pas un titre de propriété ni une permission de déployer au-delà du domaine.

Cette enceinte protège les réseaux voisins et l’essai lui-même. Pourtant elle ne décrit pas le passage d’une observation à une affirmation publique. Un pare-feu peut reconnaître un paquet. Il ne sait pas si la ventilation horaire d’un résultat révèle une pointe d’activité, si cinq observations désignent implicitement un client, ou si le nom d’une architecture divulgue une faiblesse confidentielle.

Dire que les paquets n’ont pas franchi la frontière est donc nécessaire, mais insuffisant. Il reste à savoir qui a autorisé la collecte, qui peut autoriser le rapport, quelle transformation protège les données et quelle quantité de contexte doit subsister pour qu’un lecteur extérieur puisse évaluer la conclusion.

Une moyenne n’identifie pas ce qui a été mesuré

Le TLV de base réunit un FlowMonID de 20 bits et les indicateurs de perte et de délai. Le mode amélioré peut ajouter un identifiant étendu, le choix entre mesure segment par segment ou de bout en bout, l’état de fragmentation, le sens du flux, un horodatage, des instructions pour construire une mesure en sens inverse et un numéro de séquence. Ces instructions peuvent tenir compte des masques de préfixe, du protocole, des ports, du DSCP, de la portée du tunnel et de la période.

Le sous-ensemble activé change le travail effectué par le matériel. Le comportement SID change les points qui examinent le TLV. Un nœud non compatible peut l’ignorer conformément aux règles SRH. Ainsi, « implémentation du RFC 9947 » n’est pas une population statistique assez précise.

Il faut aussi décrire le bras RFC 9343 avec la même rigueur. Une comparaison où le Destination Option transporte d’autres champs, traverse d’autres nœuds ou reçoit une charge différente mesure plusieurs variables à la fois. Le chiffre final peut être exact sans répondre à la question du protocole.

Même la valeur expérimentale devient une information de provenance. Si une implémentation attend 124 et l’autre émet 126, une absence de collecte peut provenir de la coordination et non du mécanisme. Si deux expériences partagent par erreur une valeur, leurs observations peuvent se mélanger. Inscrire le code ne lui confère aucune légitimité supplémentaire ; cela permet seulement de rattacher une mesure au bon montage.

La confidentialité concerne aussi les métadonnées

Le RFC 9343 précise que l’Alternate Marking ne libère pas de données utilisateur, mais que ses métadonnées peuvent aider à reconnaître des chemins ou à suivre des flux. Le FlowMonID est particulièrement sensible. Plusieurs points d’écoute coordonnés peuvent reconstruire une information de performance inaccessible depuis un seul point. Les canaux qui remontent les statistiques vers le système de gestion doivent être sécurisés.

Le RFC 9341 ajoute les risques d’intégrité : manipulation du marquage, attaque contre la synchronisation du temps, perturbation de la collecte et possibilité théorique d’un canal caché à faible débit. Un rapport sérieux doit donc expliquer non seulement ce qu’il a observé, mais aussi les hypothèses de compteur, d’horloge et d’intégrité qui soutiennent l’observation.

Le RFC 8799 rappelle qu’une frontière de limited domain protège des paramètres opérationnels que l’opérateur ne souhaite pas révéler. Cette confidentialité est distincte de la vie privée des personnes présentes dans le domaine. Retirer les noms ne suffit pas toujours : heure précise, classe de trafic rare, petite cohorte et forme du chemin peuvent se recouper jusqu’à réidentifier une activité.

L’excès inverse consiste à supprimer les cohortes, dénominateurs, exclusions et résultats négatifs. La publication devient alors sans danger apparent, mais aussi sans pouvoir probant. La bonne unité de sortie n’est ni la capture brute ni le slogan anonymisé. C’est la description vérifiable de la transformation opérée entre les deux.

Un reçu plus fin qu’un jeu de données

Le premier élément du reçu est l’autorité : opérateur ou promoteur de la recherche, rôle ayant approuvé la publication, lieu et date de dépôt, et relation matérielle de financement ou de fourniture d’équipements. La réception par l’ISE ou la discussion par SPRING ne valent ni approbation, ni consensus IETF, ni passage au Standards Track.

Le deuxième élément fixe l’identité de l’expérience : révision du RFC ou de l’Internet-Draft, version de l’implémentation, valeur TLV choisie, champs de base et étendus actifs, fonctions SID et configuration de comparaison RFC 9343. Des empreintes peuvent lier des artefacts protégés à un rapport public sans exposer leur contenu.

Le troisième décrit la population : cohortes d’architectures et de logiciels à un niveau assez précis pour expliquer un écart, assez abstrait pour ne pas dresser un inventaire exploitable ; forme de topologie sans localisation sensible ; intervalle d’observation ; trafic admis et exclu ; traitement de l’échantillon ; définitions de perte, délai, gigue, survivabilité et coût de traitement ; hypothèses d’horloge et de compteur.

Le dernier expose le résultat et ses limites. Réussites, échecs, cas indécis et déclenchements de retour arrière doivent figurer ensemble. Le reçu dit quels attributs de flux, chemin, temps ou fournisseur ont été agrégés, masqués ou supprimés, quelle reproductibilité disparaît avec ces choix, quels éléments protégés pourraient faire l’objet d’un examen restreint, et comment une correction qualifie une version antérieure.

Cette proposition est celle de Daniel Kade, pas une obligation du RFC 9947. Elle ne réclame pas le jeu de données complet. Elle vise une surface publique assez mince pour protéger le réseau, assez structurée pour empêcher une conclusion de voyager sans ses conditions.

Running code n’est pas une décision de normalisation

Le RFC 7942 fournit un précédent partiel. Sa section volontaire Implementation Status permet de préciser l’organisation responsable, le nom d’une implémentation, sa maturité et sa couverture. Elle aide le débat à peser le code existant tout en avertissant qu’une inscription ne constitue pas une approbation de l’IETF et que l’information varie dans le temps.

Mais ce BCP exclut explicitement l’Independent Stream. Il ne peut donc pas être transformé en règle obligatoire pour RFC 9947. L’analogie tient seulement à la discipline de description : une implémentation a une identité, une portée et une date.

Le RFC 7841 fixe l’autre limite. Un RFC Experimental de l’Independent Stream ne devient pas rétrospectivement le produit du consensus IETF parce que son expérience est convaincante. De bons résultats peuvent nourrir un nouveau travail, modifier les priorités ou persuader SPRING. Le reçu doit préserver la différence entre la valeur de la preuve et l’autorité du flux de publication.

Ce que le dossier ne démontre pas

Les sources réunies établissent le statut du document, les champs, la limite de domaine, les objectifs de comparaison et l’intention de partager les résultats. Elles décrivent les risques voisins de confidentialité, d’intégrité et de routage par segments. Elles ne fournissent ni inventaire de déploiement, ni résultat d’opérateur, ni jeu de données public.

Cet article ne tranche donc pas la supériorité du TLV SRH. Il ne prétend pas que les résultats manquent ou sont en retard. Il n’exige aucune publication de paquets bruts, d’identité, de topologie exacte ou de secret fournisseur.

Il demande seulement que le futur résultat conserve une frontière lisible. Les données protégées peuvent rester dedans. Une preuve versionnée, autorisée, agrégée et corrigible peut sortir. C’est cette séparation, et non la quantité de données publiée, qui permet à une expérience privée de contribuer honnêtement à une décision publique.

Sources

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. Notice du RFC Editor pour le RFC 9947
  5. RFC 9947 — Application de l’Alternate-Marking Method au Segment Routing Header
  6. RFC 9341 — Alternate-Marking Method
  7. RFC 9342 — Clustered Alternate-Marking Method
  8. RFC 9343 — Application IPv6 de l’Alternate-Marking Method
  9. RFC 8799 — Limited Domains and Internet Protocols
  10. RFC 8402 — Segment Routing Architecture
  11. RFC 8754 — IPv6 Segment Routing Header
  12. RFC 8986 — SRv6 Network Programming
  13. RFC 7841 — RFC Streams, Headers, and Boilerplates
  14. RFC 7942 — Improving Awareness of Running Code