Résumé

  • RFC 10028 remplace l’ancienne plage dynamique commune de RFC 3307 par des blocs distincts pour MADCAP, l’allocation SSM par l’hôte, l’usage privé, l’expérimentation et les adresses Solicited-Node.
  • Cette séparation ne devient opérationnelle que si les allocateurs déployés l’appliquent. La conformité d’un nombre ne prouve ni son origine, ni l’absence de collision, ni l’adhésion d’un récepteur, ni la livraison du bon flux.

Un intégrateur met en service une nouvelle application SSM. L’hôte choisit 0xF0000002, valeur parfaitement située dans la plage que RFC 10028 réserve à l’allocation SSM par l’hôte. Le contrôle automatique devient vert.

Quelques mètres plus loin, un serveur MADCAP oublié dans une baie de secours utilise encore la plage de RFC 3307, de 0x80000000 à 0xFFFFFFFF. Il attribue la même valeur à une autre application. Son propre contrôle devient vert lui aussi.

Ce n’est pas le registre qui s’est contredit. Ce sont deux époques de règles qui se rencontrent sur le même lien. Le nouvel allocateur suit la partition actuelle ; l’ancien exécute fidèlement une partition devenue obsolète. L’incident commence précisément dans l’espace que ni une page IANA ni une annonce de conformité ne peuvent observer : le logiciel réellement exécuté.

RFC 10028, publié sur la voie normative de l’IETF en août 2026, rend ce désaccord évitable. Il faut pourtant résister à deux simplifications. Le registre n’est pas une preuve de déploiement. Et, inversement, le fait que l’exécution soit locale ne rend pas la partition commune facultative.

Le défaut se trouvait dans la géométrie de l’ancienne plage

RFC 3307 appelait « identifiant de groupe » les 32 bits de poids faible d’une adresse multicast IPv6. Pour l’allocation dynamique, serveur et hôte puisaient dans le même espace. La zone supérieure recouvrait en outre les identifiants Solicited-Node.

Deux mécanismes indépendants pouvaient donc choisir le même nombre sans enfreindre leur propre procédure. Un observateur qui ne conservait que l’adresse finale ne pouvait plus dire si elle venait d’un serveur, d’un hôte ou d’une fonction architecturale IPv6.

RFC 10028 déplace la répartition dans le registre IPv6 Multicast Address Space de l’IANA :

  • 0x800000000x8FFFFFFF pour MADCAP ;
  • 0x900000000xEFFFFFFF non attribué ;
  • 0xF00000000xFCFFFFFF pour l’allocation SSM par l’hôte ;
  • 0xFD0000000xFDFFFFFF pour l’usage privé ;
  • 0xFE0000000xFEFFFFFF pour l’expérimentation ;
  • 0xFF0000000xFFFFFFFF pour Solicited-Node.

Une future attribution dans la zone libre demande une Standards Action. RFC 8126 apporte le vocabulaire de politique et de contrôle des changements. La valeur du registre est d’offrir une grammaire minimale commune : chaque classe possède un territoire reconnaissable.

Sa limite est tout aussi importante. IANA n’attribue pas le groupe vivant d’une usine, ne lit pas la configuration d’un serveur et ne vide pas une table de commutation. La ligne du registre établit la règle de coordination ; elle n’atteste pas son exécution.

RFC 10028 impose en pratique un choix : mettre à niveau ou isoler

La nouvelle norme réduit fortement l’espace de MADCAP. Elle demande que les implémentations adoptent la nouvelle plage et que les déploiements existants soient soit mis à jour, soit exploités sans autre protocole d’allocation multicast IPv6 dans le même environnement.

Cette alternative est plus importante qu’une estimation abstraite du risque. Au moment de la rédaction, le RFC ne connaissait qu’une implémentation MADCAP et aucun déploiement à grande échelle. Cette observation datée ne constitue ni un inventaire fournisseur, ni la preuve qu’un vieux service n’est pas caché dans une installation industrielle, audiovisuelle ou maritime.

RFC 2730 définit MADCAP comme un mécanisme client-serveur. Un client découvre, demande et reçoit une offre, un ACK ou un refus ; l’administrateur fixe la politique locale. Un bail peut donc prouver la décision du serveur, mais pas l’actualité de sa plage.

L’inventaire doit descendre au niveau de la version, du binaire, du hachage de configuration, des bornes du pool, du bail et des instances de secours. Une certification du serveur principal ne dit rien du nœud froid qui reprendra le service après une panne.

Les quatre derniers octets deviennent un fait de couche 2

RFC 4291 définit la forme et la portée des adresses multicast IPv6. Un groupe transitoire a un sens dans sa portée ; il ne flotte pas comme une propriété universelle.

Sur Ethernet, RFC 2464 construit l’adresse de destination à partir de 33:33 et des quatre derniers octets de l’adresse IPv6. La plage numérique se prolonge ainsi dans les filtres d’interface et les tables de commutation.

RFC 10019 décrit les dégâts possibles dans les réseaux sans configuration centrale : traitement logiciel de trafic indésirable, perte du bénéfice du snooping, saturation d’un équipement lent ou conflit dans des tables matérielles limitées. Le problème apparaît dans les réseaux maritimes, mais aussi dans l’automatisation, l’audiovisuel et les ensembles de capteurs.

Le temps compte autant que l’espace. Deux segments isolés peuvent attribuer le même groupe sans symptôme, puis entrer en collision lors de leur reconnexion. RFC 10019 exige qu’une future solution décentralisée détecte et résolve ce cas. RFC 10028 ne fournit pas cette solution ; il lui réserve une plage qui permet la coexistence.

(S,G) réduit une coordination, pas le nombre de preuves

RFC 4607 définit un canal SSM par la paire source-groupe (S,G). Deux sources différentes peuvent partager G tout en restant deux canaux distincts. RFC 8815 en tire un avantage de gestion : G n’a pas à être mondialement unique dans l’espace SSM.

Il faut néanmoins conserver S, vérifier l’adhésion du récepteur et connaître les capacités de la chaîne. RFC 10028 rappelle que SSM n’est pas universellement pris en charge. Certains équipements économiques ne filtrent qu’une adresse MAC de destination. RFC 4541 montre comment une différence de version ou de capacité de snooping peut supprimer un flux attendu ou, au contraire, inonder des ports.

Une adresse située dans la bonne plage SSM ne prouve donc pas que le réseau a appliqué le filtre source. Il faut rapprocher la paire (S,G), le rapport MLD ou IGMP, l’entrée de snooping, l’état de routage et un témoin de paquet propre à l’application.

Privé et expérimental ne veulent pas dire sans conséquence

La plage Private Use convient à une allocation manuelle dans un environnement isolé. Mais deux administrations peuvent y choisir la même valeur. Une fusion, une liaison temporaire ou un rétablissement de redondance transforme alors une décision locale en conflit partagé.

La plage Experimental Use autorise des expériences et RFC 10028 ne les limite pas à un réseau fermé. Le mot « expérimental » n’apporte ni sécurité, ni isolation, ni autorisation, ni date de fin. La zone non attribuée n’est pas davantage un stock local : elle attend une décision normative future. La plage Solicited-Node, enfin, remplit une fonction IPv6 précise.

Les étiquettes du registre protègent la coordination seulement si les opérateurs refusent de les convertir en permissions implicites.

Le journal doit identifier l’époque de la règle

Pour chaque groupe, enregistrer la révision normative, la classe d’allocateur, sa version et son hachage de configuration. Conserver l’événement de sélection ou le bail, l’adresse IPv6 complète, la portée, l’identifiant de groupe, le mappage Ethernet, l’application, le flux, les dates de début, de renouvellement et d’expiration. En SSM, S appartient à l’identité du canal.

Poursuivre le journal dans le réseau : autres systèmes d’allocation présents, sondes de conflit, adhésions MLD/IGMP, tables de snooping et de routage, premier et dernier paquet, trafic inattendu, événement de renumérotation et retrait de l’ancien état.

Ne jamais fondre en un seul indicateur les affirmations suivantes : la valeur appartient à une plage actuelle ; un allocateur identifié l’a choisie ; aucun concurrent ne l’a reprise ; le récepteur a adhéré ; le chemin a transmis ; l’application a reçu le bon flux.

La primauté du code en fonctionnement de Heng Lu place la preuve dans cette chaîne exécutée. Son principe de spécification initiale minimale et de décision future localisée éclaire la bonne portée du registre : assez de règle commune pour séparer les mécanismes, sans centraliser leurs choix opérationnels. Sa distinction entre contrôle formel et contrôle pratique des données explique enfin pourquoi l’IETF et l’IANA décrivent l’espace sans commander le serveur, le commutateur ou le récepteur.

RFC 10028 corrige la carte. La preuve de migration appartient toujours au terrain.