Résumé

  • RFC 9778 soumet les Types et Codes IGMP, ainsi que les registres de drapeaux d’extension, à Standards Action : la décision gagne en visibilité, mais aucun équipement déployé n’est certifié.
  • Le texte décrit deux échecs opposés : refuser une valeur inconnue et couper la connectivité, ou la laisser passer sans inspection effective et perdre en sécurité.
  • Une mise en service défendable conserve des reçus distincts pour l’autorité, la publication IANA, l’implémentation, le verdict des analyseurs, l’interopérabilité, l’impact sur le trafic et le repli.

Dans les opérations réseau, une ligne propre dans un registre exerce un pouvoir psychologique considérable. Le numéro existe, le nom est stable, la référence normative est publique : la tentation est forte d’en déduire que l’écosystème est prêt. RFC 9778 empêche précisément ce raccourci.

Publié en mars 2025 comme BCP 57 et remplaçant RFC 3228, le document modifie les règles d’attribution d’IGMP et clarifie leur relation avec MLD. Le registre des Types IGMP passe à Standards Action. Les champs Code IGMP suivent la même voie, et le document qui définit un nouveau Type doit définir la politique de son Code. Deux registres accompagnent en outre le mécanisme d’extension : pour les requêtes, le bit 0 est le drapeau E et les bits 1 à 3 restent non attribués ; pour les rapports, le bit 0 est E et les bits 1 à 15 restent libres. Leur politique est Standards Action.

MLD conserve une autre frontière. Ses Types et Codes relèvent du registre ICMPv6 et de la procédure IETF Review. Le texte ne transforme donc pas des champs voisins en un seul espace administratif. Il attribue à chaque espace son autorité exacte.

Une procédure forte, une conclusion limitée

Selon RFC 8126, Standards Action requiert un RFC de la voie des normes ou un BCP approuvé par l’IESG. Ce filtre élève le niveau d’examen, rend les nouvelles sémantiques visibles et donne aux implémenteurs une référence durable. Il répond à la question : cette valeur a-t-elle été attribuée par la procédure compétente ?

Il ne répond pas aux questions suivantes : le micrologiciel d’un boîtier la reconnaît-il ? Le moteur d’inspection possède-t-il une branche sémantique pour elle ? Un décodeur l’affiche-t-il correctement ? La règle de production la refuse-t-elle par défaut ? Le retour à l’état précédent est-il réellement exécutable ?

RFC 9778 expose le danger sans citer de produit. Les pare-feu et systèmes de détection dépendent de champs non ambigus. Face à une nouvelle valeur inconnue, un analyseur peut la refuser et provoquer une perte de connectivité. Il peut aussi la transmettre dans le cadre d’une attaque, faute de comprendre ce que la nouvelle sémantique permet. Le premier échec est bruyant ; le second peut conserver un trafic apparemment sain tout en ouvrant un angle mort.

RFC 6709 élargit ce constat : extensions inconnues, bits autrefois « doivent être zéro », implémentations partielles et abandons silencieux peuvent dégrader interopérabilité et sécurité. RFC 9279 fournit un voisin technique utile : une extension bien formée mais non prise en charge doit être distinguée d’une construction mal formée. Une déclaration de conformité au message de base ne prouve pas que le chemin d’extension respecte cette distinction.

Un dossier de preuves en sept pièces

Le reçu d’autorité nomme le document et la procédure. Le reçu de publication fige l’état du registre IANA à une date donnée. Le reçu d’implémentation identifie version logicielle, micrologiciel, bibliothèque ou jeu de règles. Le reçu d’analyse montre le verdict réellement observé sur des vecteurs connus, inconnus et mal formés. Le reçu d’interopérabilité couvre les combinaisons d’anciens et de nouveaux pairs. Le reçu d’impact mesure adhésions, départs, pertes, alertes, latence et charge. Enfin, le reçu de repli démontre qu’on peut retirer le changement sans arrêter des flux sans rapport.

Aucune de ces pièces ne doit hériter de l’autorité d’une autre. Une valeur publiée peut rester absente des parseurs. Un parseur peut accepter la syntaxe alors que la politique de sécurité choisit encore un comportement générique. Un paquet observé après le pare-feu prouve son passage, pas une inspection sémantique. Un plan de repli non chronométré n’est pas une capacité de récupération.

Cette séparation rejoint les travaux de Heng Lu sur la primauté du code en fonctionnement et les couches de réalité. Le registre n’est pas « moins réel » que le trafic ; il est réel dans la couche de coordination. Le verdict de l’équipement appartient à la couche d’exécution. Le risque apparaît lorsqu’une preuve change de couche sans nouvel observateur.

Échouer d’abord dans un périmètre maîtrisé

Voici un modèle hypothétique, et non le compte rendu d’un déploiement. Inventorier chaque composant qui lit IGMP ou MLD : pile hôte, silicium de commutation, routeur, pare-feu, sonde, courtier de paquets, collecteur et outil de diagnostic. Conserver versions et empreintes des configurations. Rejouer le trafic historique, puis ajouter la valeur proposée, une valeur non attribuée, une extension inconnue mais bien formée, des longueurs et sommes de contrôle invalides, et des pairs de générations mixtes.

À chaque étape, consigner le geste exact : reconnu, nommé, ignoré par une règle explicite, refusé, signalé, ou transmis sans verdict sémantique. Relier ce geste à l’état des abonnements multicast et au résultat dans le plan de données. Un canari limité doit disposer de seuils d’arrêt préalables : hausse des refus, rapports manquants, mode de secours de l’analyseur, pression sur les ressources, divergence d’état ou pertes inexpliquées. Le comportement d’émission précédent et l’ancienne politique doivent rester deux leviers de repli indépendants.

Sources

  1. RFC 9778
  2. RFC 3228
  3. RFC 8126
  4. RFC 6709
  5. RFC 9279
  6. RFC 9776
  7. RFC 9777
  8. RFC 4443
  9. IANA — IGMP Type Numbers
  10. IANA — ICMPv6 Parameters
  11. Heng Lu — Running-code primacy
  12. Heng Lu — Minimum initial specification
  13. Heng Lu — Reality layers