Résumé

  • La RFC 3307 attribuait aux allocations par serveur et par hôte la même plage dynamique d’identifiants de groupe IPv6, laquelle recouvrait aussi l’espace Solicited-Node. La RFC 10028 remplace ce terrain commun par six plages distinctes.
  • Le registre IANA empêche qu’un mécanisme reçoive officiellement la plage d’un autre. Il ne prouve ni mise à jour d’un ancien logiciel MADCAP, ni prise en charge de SSM, ni livraison du trafic à un destinataire autorisé.
  • Mike McBride est coauteur de la RFC 10028 avec Nate Karstens et Dino Farinacci. Leur contribution montre la valeur d’une coordination minimale : le registre sépare les noms, tandis que le code et l’exploitation doivent prouver l’adoption.

La collision la plus facile à éviter est celle que le plan interdit avant le départ. Encore faut-il que le plan donne des voies différentes.

La RFC 3307 avait prévu deux méthodes d’attribution dynamique d’un identifiant de groupe multicast IPv6. Un serveur pouvait fournir l’adresse, notamment par MADCAP. Un hôte pouvait la choisir lui-même, voie nécessaire à un futur fonctionnement sans configuration. Pourtant, les deux méthodes recevaient exactement la plage 0x80000000-0xFFFFFFFF. Sa partie haute, 0xFF000000-0xFFFFFFFF, était en outre utilisée par les adresses multicast Solicited-Node.

Un serveur et un hôte pouvaient donc suivre la spécification chacun de son côté et aboutir au même identifiant. Ce n’était pas d’abord un défaut de discipline locale. La règle commune avait oublié de rendre les choix disjoints.

Publiée sur la voie des normes de l’IETF en août 2026, la RFC 10028 corrige ce chevauchement. Nate Karstens, Dino Farinacci et Mike McBride en sont les trois auteurs. McBride n’est ni l’inventeur unique ni l’administrateur personnel de l’espace multicast. Il est l’un des ingénieurs qui ont remplacé une promesse générale d’usage dynamique par une table de responsabilités explicites.

La fiche IETF relevée le 31 août 2026 le présente comme président du groupe PIM, délégué auprès de MBONED et d’ANIMA, réviseur du Routing Area Directorate et auteur de neuf RFC. La RFC 10028 indique Futurewei comme affiliation. Un ancien article de l’Open Networking Foundation fournit un contexte professionnel daté. Ces sources identifient une personne et une trajectoire ; elles ne lui donnent aucun pouvoir sur les réseaux qui appliqueront la norme.

L’erreur se trouvait dans la carte

Dans une adresse multicast IPv6, les 32 bits de poids faible forment l’identifiant de groupe décrit par la RFC 3307. Sur Ethernet, ils sont directement projetés dans l’adresse multicast de liaison. Une duplication ne reste donc pas un désaccord abstrait entre deux bases : elle peut conduire l’interface ou le commutateur à traiter ensemble des flux qui devaient être distincts.

MADCAP, défini par la RFC 2730, est un protocole client-serveur. L’hôte demande au serveur un bail d’adresse multicast. Un mécanisme sans configuration poursuit le but inverse : permettre aux participants de choisir sans dépendre d’un service central. Les deux logiques peuvent être raisonnables. Elles cessent de coexister proprement lorsqu’elles tirent dans la même urne sans signe indiquant l’origine du numéro.

La RFC 10019 détaille cette difficulté pour les réseaux zeroconf. Elle exige qu’une solution décentralisée cohabite avec plusieurs applications et autres mécanismes, puis détecte et résolve les collisions aux couches réseau et liaison. Un tirage aléatoire n’apporte pas cette garantie si un serveur peut légitimement choisir dans le même intervalle.

Le chevauchement avec Solicited-Node ajoutait une autre confusion. IPv6 construit ces adresses pour Neighbor Discovery à partir d’adresses unicast ou anycast. Leur usage architectural existait déjà. La vieille plage dynamique l’englobait au lieu de lui réserver une limite visible.

La RFC 10028 n’invente pas un nouveau paquet. Elle corrige la carte avant que plusieurs allocateurs n’y inscrivent des destinations incompatibles.

Une table en six bandes

Le nouveau registre « Dynamic Multicast Group IDs », intégré à l’espace d’adressage multicast IPv6 de l’IANA, contient six bandes initiales :

  • 0x80000000-0x8FFFFFFF pour MADCAP ;
  • 0x90000000-0xEFFFFFFF non attribué ;
  • 0xF0000000-0xFCFFFFFF pour l’attribution par l’hôte d’adresses de groupe SSM ;
  • 0xFD000000-0xFDFFFFFF pour l’usage privé ;
  • 0xFE000000-0xFEFFFFFF pour l’expérimentation ;
  • 0xFF000000-0xFFFFFFFF pour Solicited-Node.

Une nouvelle attribution ordinaire dans l’espace libre exige une Standards Action. Le registre ne conserve que la plage, une description et une référence. Cette sobriété est fonctionnelle. L’IANA n’a pas besoin de connaître le public d’un flux, sa politique commerciale ou le modèle de ses récepteurs pour dire que MADCAP et l’allocation SSM par l’hôte ne possèdent pas les mêmes bits.

Elle délimite aussi ce que la table ne sait pas. Des adresses IPv6 différentes peuvent encore aboutir à la même destination Ethernet lorsque les différences se trouvent hors des bits projetés. Un commutateur peut manquer de place ou utiliser des tables de hachage qui rapprochent plusieurs groupes. Une partition réseau peut laisser deux hôtes choisir séparément puis révéler le conflit à la reconnexion. Une source malveillante peut employer une adresse valide pour un trafic illégitime.

Le registre élimine la cause « deux mécanismes officiellement installés sur la même plage ». Il ne supprime pas le concept de collision. La RFC 10019 conserve donc toute sa nécessité : détecter, classer et résoudre les autres cas.

SSM ajoute une coordonnée, pas une capacité magique

La bande d’allocation par l’hôte porte un qualificatif précis : elle concerne SSM, Source-Specific Multicast.

Dans le modèle any-source, le récepteur demande le groupe G. Dans SSM, il demande le canal (S,G), composé de la source et du groupe. La RFC 4607 explique que deux sources distinctes peuvent réutiliser le même G sans représenter le même canal. Ce supplément réduit le besoin de coordonner globalement chaque valeur de groupe.

Il ne suffit pas de choisir dans la bonne bande pour faire apparaître la source. L’application doit connaître S. L’hôte doit pouvoir exprimer une adhésion spécifique, généralement au moyen d’IGMPv3 ou MLDv2. Le routeur désigné et le domaine de routage doivent maintenir la sémantique de source. La RFC 8815 recommande SSM pour l’interdomaine tout en reconnaissant que l’application, le système et l’accès réseau restent des dépendances concrètes.

La RFC 10028 le dit sans détour : SSM n’est pas universellement pris en charge. Sa plage est destinée aux environnements qui le prennent en charge. Une adresse correcte dans 0xF0000000-0xFCFFFFFF ne met pas à jour un système ancien, ne configure pas PIM et n’authentifie pas l’émetteur.

La doctrine de Heng Lu sur la spécification initiale minimale et la primauté du code en fonctionnement aide ici à garder les niveaux à leur place. Le commun doit contenir la distinction nécessaire à l’interopérabilité. Les acteurs locaux choisissent et exploitent le mécanisme. L’adoption et l’observation, non la seule déclaration, établissent ensuite le fait opérationnel. Cette analogie ne transforme pas l’IANA en RIR ; elle rappelle seulement qu’une table de protocole ne peut pas exécuter le logiciel qu’elle référence.

Le passé de MADCAP ne disparaît pas avec la page IANA

La nouvelle carte réduit fortement l’espace disponible pour MADCAP. La RFC 10028 rapporte qu’au moment de la rédaction, une seule implémentation était connue et qu’aucun déploiement à grande échelle n’était connu. La formule doit rester intacte. Elle ne signifie pas que personne, nulle part, n’utilisait le protocole ; elle décrit l’horizon documentaire des auteurs.

La réduction semblait ainsi praticable, mais elle exige toujours une migration. Un logiciel MADCAP existant doit appliquer la nouvelle plage ou rester dans un environnement où aucun autre protocole d’attribution IPv6 multicast ne peut entrer en conflit. La publication du registre n’altère pas un binaire ancien. Elle ne change pas une configuration oubliée et ne prouve pas qu’un équipement vendu dix ans plus tôt a reçu un correctif.

L’exploitant doit joindre quatre preuves : quel allocateur a produit l’identifiant, quelle version fonctionnait, quelle règle de plage était chargée et quel résultat a été observé. Un journal qui ne conserve que l’adresse complète ne permet pas toujours de savoir si le numéro venait d’un serveur ancien ou d’un hôte conforme à la nouvelle partition.

La coexistence promise par la norme devient réelle au moment où les allocateurs cessent effectivement de partager la même carte.

Faire parler chaque reçu dans sa juridiction

La norme IETF prouve qu’une décision collective a défini les bandes. La page IANA prouve le contenu public courant du registre. Un test d’implémentation peut prouver qu’un allocateur reste dans sa bande. Un test (S,G) peut prouver une adhésion et un chemin SSM à un instant donné. Une politique d’accès peut établir que le récepteur était autorisé.

Ces preuves ne sont pas interchangeables.

La présence de la ligne IANA ne mesure pas le déploiement. La sélection d’une adresse SSM ne prouve pas le soutien de tous les routeurs. La réception du flux ne légitime pas sa source. L’absence de collision pendant un essai ne couvre pas les autres portées, partitions ou limites matérielles.

Un registre d’exploitation utile peut rester mince : allocateur, version, mécanisme, identifiant de groupe, adresse complète, version de la règle, prérequis SSM, observation des collisions, résultat de livraison, validation de la source, autorisation du récepteur et responsable du retour arrière. Chaque champ doit refuser de parler au-delà de son témoin.

La contribution de McBride, Karstens et Farinacci tient dans cette réduction d’ambiguïté. Ils n’ont pas prétendu qu’une table ferait fonctionner le multicast. Ils ont empêché la spécification d’ordonner à deux mécanismes d’occuper le même terrain.

Le registre rend la coexistence possible. Le réseau doit encore la démontrer.

Sources