Résumé

  • RFC 10019 demande à une future allocation multicast zeroconf de garantir une adresse distincte à la couche réseau comme à la couche liaison, sans serveur central ni accès extérieur obligatoire.
  • L’encodage Ethernet peut faire converger plusieurs groupes IP vers une même destination, tandis qu’une coupure peut produire deux historiques d’allocation localement valides qui deviennent incompatibles après reconnexion.
  • Une résolution n’est achevée qu’après choix explicite du survivant, migration de l’autre flux, convergence des écouteurs et des équipements, extinction de l’ancien groupe et validation du contenu applicatif.

Le premier symptôme peut être un processeur qui sature sur un équipement n’ayant demandé qu’un flux modeste. L’allocateur affirme pourtant que son groupe multicast était libre. Le commutateur présente une entrée de diffusion. L’application reçoit bien des paquets, mais aussi le flux vidéo d’un autre service.

Ces observations peuvent toutes être exactes. Elles décrivent simplement des couches différentes. L’allocateur a vérifié une identité IP ; la carte réseau et le commutateur filtrent une projection Ethernet ; l’application doit encore distinguer le producteur et le contenu. RFC 10019, publié en juillet 2026 comme RFC IETF de catégorie Informational, fait de cette différence le point de départ d’une future solution décentralisée.

Le document est un énoncé de problème et de besoins. Il ne normalise ni protocole complet, ni format de message, ni règle de priorité. Il n’atteste aucun déploiement. Son exigence la plus structurante est plus étroite : une allocation doit produire de l’unicité à la fois au niveau réseau et au niveau liaison, puis savoir détecter et résoudre la perte de cette unicité.

L’adresse que l’IP distingue et qu’Ethernet confond

Dans IPv4, RFC 1112 place seulement les 23 bits faibles de l’adresse multicast dans la destination Ethernet. Les groupes IPv4 disposent de 28 bits variables ; trente-deux adresses IP différentes peuvent donc donner la même adresse MAC. L’algorithme est correct et la collision demeure réelle.

Pour IPv6, RFC 2464 construit une destination 33:33 complétée par les 32 bits faibles de l’adresse multicast. L’espace IP est beaucoup plus vaste, mais la projection vers Ethernet continue d’abandonner de l’information. Deux groupes IPv6 qui diffèrent ailleurs peuvent être indiscernables pour un filtre limité à la destination MAC.

La conséquence dépend du matériel. Une interface réseau peut programmer un filtre multicast pour éviter de livrer les trames inutiles au système. Si deux groupes partagent la même destination Ethernet, ce filtre ne suffit plus. RFC 1112 autorise même, lorsque les ressources de filtrage sont insuffisantes, l’acceptation large des paquets multicast suivie d’un tri logiciel. La fonction peut rester correcte, mais la charge CPU, l’exposition aux paquets et la capacité utile ont changé.

RFC 4541 montre que les commutateurs IGMP/MLD snooping ne se comportent pas tous selon le même modèle. Certains construisent leur décision à partir de l’adresse de liaison plutôt que du groupe IP complet. Un flux rapide peut alors être envoyé vers le port d’un récepteur lent abonné à un autre groupe qui partage la même MAC. Des tables matérielles à capacité ou compartiments limités peuvent en outre refuser des entrées ou provoquer de la diffusion.

REQ-1 de RFC 10019 interdit de considérer la seule table IP de l’allocateur comme verdict final. La proposition d’adresse est une étape. La dérivation MAC, l’état du commutateur, le filtre de l’interface et la réception applicative constituent d’autres verdicts, avec des autorités d’observation différentes.

La reconnexion fabrique un nouveau présent

REQ-8 exige détection et résolution des collisions aux deux couches. Le cas de la partition temporaire révèle pourquoi une allocation n’est jamais un titre intemporel. Deux parties d’un réseau cessent de communiquer. Chacune choisit le même groupe, n’entend aucune objection et commence à l’utiliser. Lorsque le lien revient, les deux journaux restent sincères : au moment de chaque choix, aucun conflit n’était visible dans le domaine local.

Le conflit naît de la réunion des domaines d’observation. Une heure locale antérieure ne suffit pas forcément à désigner un propriétaire ; les horloges peuvent diverger, et « premier » n’avait aucun sens entre segments séparés. Une criticité applicative peut compter davantage qu’un ordre temporel. RFC 10019 ne choisit pas entre ces politiques et ne doit pas être cité comme s’il le faisait.

Une preuve d’allocation exploitable doit donc conserver la famille d’adresses, le groupe complet, sa portée, la MAC dérivée, la source en SSM, l’implémentation et la version des règles, l’instance locale, l’application ou le flux, l’époque de revendication, le domaine d’observation et l’empreinte de la transcription. Sans domaine ni époque, un journal ne peut pas expliquer pourquoi deux succès se contredisent maintenant.

La restauration d’un lien, la fusion de VLAN, l’ajout d’un pont ou un changement d’adjacence déclenche la comparaison. Il faut chercher le doublon IP exact, mais aussi les groupes IP différents qui donnent la même MAC. L’absence d’annonce de conflit n’est pas une preuve : certains participants peuvent être endormis, l’état de snooping peut être incomplet et un filtre peut déjà recevoir trop largement.

La résolution doit nommer le survivant et le flux migré. Elle doit réserver au second une adresse distincte aux deux couches, publier la nouvelle association, déplacer les écouteurs, faire converger commutateurs et interfaces, vérifier le contenu, arrêter l’ancien producteur puis laisser expirer l’état obsolète. Une période de double annonce peut réduire la coupure, mais c’est un choix d’exploitation, pas une procédure normative de RFC 10019.

Décentraliser la décision sans la rendre anonyme

Le futur mécanisme doit minimiser les points uniques de défaillance, fonctionner sans configuration humaine, sur un sous-réseau sans Internet, et accepter plusieurs applications sur un même hôte. Il doit coexister avec l’allocation manuelle ou d’autres mécanismes lorsqu’une telle coexistence est possible. Faible trafic de contrôle, découverte, portabilité et tolérance à la topologie sont recommandés.

RFC 2730 définit MADCAP autour d’un client et d’un serveur de baux. Ce contraste est utile : un serveur peut convenir à certains réseaux, mais il ne répond pas seul à une cible sans infrastructure. Donner à un contrôleur local indispensable le dernier mot déplacerait le point unique au lieu de satisfaire le besoin de résilience.

Décentralisation ne signifie pourtant pas absence de politique. Quelqu’un doit déterminer la force d’une preuve de collision, le délai de corroboration et la règle qui choisit le flux à déplacer. Ancienneté observable, priorité applicative ou identifiant déterministe sont des options locales ; aucune n’est imposée par le RFC. Elles doivent être publiées et rejouables.

La sécurité rend cette attribution nécessaire. RFC 10019 avertit qu’une collision accidentelle ou malveillante peut provoquer déni de service ou détournement de trafic. Il exige détection et résolution et recommande d’empêcher l’usage non autorisé, sans définir le mécanisme. Une annonce de conflit n’est donc pas authentique par nature. Sans identité locale, limitation de fréquence et conservation de la preuve, un attaquant peut transformer la résolution en droit de renuméroter autrui.

IPv6 sépare davantage, mais ne constate rien à votre place

Le document recommande IPv6 pour les nouvelles conceptions dynamiques. La contrainte des 23 bits Ethernet et la rareté de l’espace multicast IPv4 compliquent l’évitement. Si IPv4 reste nécessaire, l’usage prudent du bloc administrativement délimité régi par RFC 5771 est conseillé. La coexistence peut rester impossible, auquel cas limiter les mécanismes ou configurer manuellement est plus honnête qu’affirmer une sécurité inexistante.

RFC 4291 apporte à IPv6 une structure et des portées précises. Une portée limite l’intention de propagation ; elle ne crée ni bail, ni identité, ni autorisation. La MAC 33:33 demeure une projection compressée.

RFC 3307 organisait les identifiants de groupes IPv6. RFC 10028 sépare ensuite les plages dynamiques de MADCAP, du SSM alloué par l’hôte, des usages privés et expérimentaux et des adresses Solicited-Node. Cette correction réduit un chevauchement de règles. Elle ne fournit pas le protocole décentralisé qui découvre deux historiques après partition ni la preuve que le matériel les distingue.

Le SSM encode le canal comme source et groupe. RFC 8815 expose sa préférence opérationnelle et les usages restants de l’ASM. Conserver la source améliore l’attribution, mais n’augmente pas le nombre de bits vus par un filtre MAC et ne prouve pas que le récepteur a obtenu le bon contenu.

Le groupe est attribué avant que le service soit prouvé

RFC 10019 exclut explicitement l’usage du groupe après allocation. Un rapport IGMP ou MLD indique un intérêt observé ; il n’authentifie pas l’écouteur et ne garantit pas le chemin. Une entrée de commutateur décrit un état programmé, pas la trame traversée. Un compteur constate du trafic, pas son sens.

La chaîne minimale relie l’intention d’allocation, le domaine d’observation, l’unicité IP, l’unicité Ethernet, l’adhésion du récepteur, l’état du commutateur et de la carte, l’empreinte des paquets, le résultat applicatif et le retrait de l’ancienne époque. Chaque élément a sa propre portée. Le booléen « alloué » n’en résume aucun correctement.

La primauté du code en exécution formulée par Heng Lu place les observations du matériel et de l’application au-dessus d’une prétention symbolique, sans supprimer la valeur du journal d’allocation. La spécification initiale minimale permet de partager les exigences essentielles tout en laissant les choix locaux de priorité et de migration. La distinction des couches de réalité empêche enfin une adresse formellement correcte de masquer la compression et les limites physiques qui décident de la livraison.