Documentation
Répliquer le multicast IP, chiffré, à travers le mesh
VIGIL-MESH restitue le multicast IP comme sur un LAN : mDNS, SSDP, WS-Discovery, LLMNR, jeux en réseau local et UDP métier atteignent tous les membres intéressés. Les abonnements sont détectés automatiquement par un querier IGMPv3/MLDv2 local, le trafic est chiffré sous des clés d'émetteur que le relais réplique sans lire, un contrôle de tempête à double étage borne le débit, et le TTL link-local 255 arrive intact. Les piles de découverte DDS, dont celles de ROS 2, s'appuient sur ce multicast répliqué.
Les protocoles pris en charge
Le multicast et le broadcast link-local ne sont pas un cas particulier : ils traversent le réseau VIGIL comme sur un même câble. Les familles de protocoles qui reposent sur cette diffusion fonctionnent donc entre membres distants exactement comme sur un LAN local.
- mDNS/Bonjour — imprimantes, Chromecast, AirPlay, partages de fichiers, découverte de services.
- SSDP/UPnP — téléviseurs, box multimédia, passerelles domotiques.
- WS-Discovery — caméras et périphériques ONVIF, scanners réseau.
- LLMNR et NetBIOS-NS — résolution de noms héritée des postes Windows.
- Jeux en réseau local (LAN) — découverte de parties et lobbies sur le segment local.
- UDP multicast et broadcast métier — annonces d'automates, capteurs et services propriétaires.
Pour tous ces usages, une découverte lancée depuis un membre atteint les autres membres du réseau, où qu'ils se trouvent physiquement. La page consacrée à la diffusion L2 détaille le modèle « un réseau = un lien logique » sur lequel repose ce comportement.
Abonnements automatiques, zéro configuration
Vous n'avez aucun groupe multicast à déclarer. L'agent joue le rôle de querier IGMPv3 (IPv4) et MLDv2 (IPv6) local sur l'interface TUN de chaque machine. Quand une application s'abonne à un groupe, le système d'exploitation l'annonce comme sur n'importe quel réseau, et l'agent le détecte.
Ces abonnements sont ensuite propagés dans le mesh : la diffusion n'est répliquée que vers les membres réellement intéressés par le groupe. Il n'y a ni liste de groupes à maintenir à la main, ni configuration par machine — la pile IP du système fait le travail, l'agent l'écoute.
Chiffrement du multicast
Diffuser en clair à travers un relais mutualisé serait un contresens. Chaque émetteur multicast possède sa propre clé d'émetteur (sender key) : une clé symétrique ChaCha20-Poly1305 de 32 octets, propre à cet émetteur et à une époque donnée. Elle est distribuée aux membres autorisés via les sessions chiffrées de bout en bout — jamais par le relais.
La clé tourne à trois occasions : à la révocation d'un membre du groupe, au redémarrage de l'émetteur, et au plus tard toutes les 24 heures. Un membre parti ne peut donc plus déchiffrer les diffusions suivantes.
Côté relais, l'identifiant du groupe multicast n'est qu'un haché opaque (BLAKE2s). La vigie réplique le paquet vers les bons récepteurs sur la foi de cet identifiant, sans savoir à quel groupe applicatif il correspond et sans jamais accéder à son contenu.
| Élément | Ce qui protège | Qui y a accès |
|---|---|---|
| Clé d'émetteur | ChaCha20-Poly1305, 32 octets, rotation à la révocation / au redémarrage / sous 24 h | Les membres autorisés du groupe |
| Identifiant de groupe | Haché opaque BLAKE2s | Le relais, pour aiguiller — sans lire le contenu |
| Contenu du paquet | Chiffré de bout en bout | Émetteur et récepteurs autorisés uniquement |
Contrôle de tempête
La diffusion est puissante mais dangereuse : mal bornée, elle dégénère en tempête de broadcast. VIGIL applique un contrôle de tempête à double étage, complété par des garde-fous qui interdisent structurellement les boucles.
- Par émetteur : un token bucket de 200 paquets/s et 512 kbit/s, appliqué à la fois à l'émission et au fan-out.
- Par réseau, côté vigie : un plafond global de 2 000 paquets/s répliqués, quel que soit le nombre d'émetteurs.
- Jamais d'écho : un récepteur ne réémet jamais un paquet de diffusion reçu. Aucune boucle ne peut se former.
- Déduplication stricte sur le quadruplet (groupe, index d'émetteur, époque, compteur) : un paquet dupliqué par le maillage n'est délivré qu'une fois.
Un émetteur emballé est étranglé à sa source, un réseau entier reste plafonné à la vigie, et l'absence de réémission par les récepteurs empêche toute boucle de s'installer.
TTL link-local 255 intact
Beaucoup de protocoles link-local se protègent en exigeant un TTL de 255 à la réception : si le paquet a été routé — donc décrémenté — il est rejeté. C'est notamment le cas des piles mDNS strictes. Un overlay qui route naïvement casse ces protocoles sans prévenir.
VIGIL traite le réseau comme un unique lien logique : le TTL link-local est transporté d'un bout à l'autre sans décrément. Un paquet émis avec TTL 255 arrive avec TTL 255, et la pile réceptrice le considère comme légitimement local — parce que, du point de vue de la diffusion, il l'est.
DDS et ROS 2
Les intergiciels DDS — dont s'appuie ROS 2 par l'intermédiaire de son RMW — reposent nativement sur le multicast IP pour la découverte des participants. Comme VIGIL réplique ce multicast IP chiffré entre les membres, cette découverte peut fonctionner à travers le mesh sans passerelle applicative dédiée : les participants s'annoncent et se trouvent comme sur un LAN.
In English
VIGIL-MESH replicates encrypted IP multicast across the mesh: mDNS, SSDP, WS-Discovery, LLMNR, LAN games and business UDP reach interested members as if on one wire. A local IGMPv3/MLDv2 querier picks up subscriptions with zero configuration.
Each sender uses a rotating 32-byte ChaCha20-Poly1305 sender key; the group id is an opaque BLAKE2s hash, so the relay fans packets out without reading them. A two-stage storm control (200 pps per sender, 2000 pps per network, no echo, strict dedup) keeps the mesh stable, and link-local TTL 255 arrives intact.
DDS-based discovery, including ROS 2, rides on this replicated multicast. End-to-end ROS 2 validation is on the roadmap, and storm control needs watching under chatty discovery.