Résumé

  • La RFC 2365 a défini 239.0.0.0–239.255.255.255 comme espace multicast IPv4 de portée administrative. Cette classification ne bloque aucun paquet : les routeurs doivent recevoir des définitions de frontière par interface et les appliquer dans les deux sens.
  • L’exécution concerne aussi l’état de routage : élagage à la frontière en mode dense, refus des joins concernés en mode sparse. Une mauvaise configuration ou un défaut d’implémentation peut laisser sortir le trafic ; la portée n’est donc ni un pare-feu ni une garantie de confidentialité.

Un inventaire peut être parfaitement propre et pourtant décrire un réseau qui ne l’est pas. La colonne « groupe multicast » contient uniquement des adresses commençant par 239. Le plan d’adressage les range dans une zone interne. Aucun appareil n’est marqué en erreur. Sur cette base, le contrôle paraît terminé.

Il manque précisément l’objet qui agit. La valeur de destination ne révèle pas les interfaces de sortie, les chemins de secours, la version chargée sur la carte de ligne ni la réaction du protocole multicast. Elle nomme une portée souhaitée. Le routeur décide, paquet après paquet, si cette portée existe réellement.

Publiée en juillet 1998 comme BCP 23, la RFC 2365 a séparé ces deux faits. Cette séparation est plus importante que le seul souvenir du préfixe 239/8.

Quand le TTL servait de géographie

Les opérateurs du MBONE utilisaient couramment des seuils TTL. Un paquet ne franchissait une interface que si son TTL restant dépassait la valeur configurée. Le champ chargé d’empêcher une circulation sans fin devenait en même temps une approximation de site, de région ou de domaine.

La RFC expliquait pourquoi ce cumul produisait un contrôle fragile. Le TTL portait deux responsabilités parfois contradictoires. Avec les protocoles de diffusion puis d’élagage, un paquet expiré ou bloqué par le seuil pouvait être jeté à un endroit qui ne pouvait pas élaguer correctement les sources amont. Le paquet suivant pouvait emprunter une autre route et arriver avec davantage de TTL. Le point de rejet continuait alors à absorber du trafic sans récepteur utile.

La portée administrative changeait le langage de la décision. L’adresse choisissait un espace localement attribué ; une frontière explicite disait où cet espace cessait d’être transférable.

Le bloc ne contenait pas sa propre politique

La RFC 2365 a réservé l’ensemble 239/8. Elle distinguait notamment la portée locale IPv4 239.255.0.0/16 et la portée locale d’organisation 239.192.0.0/14, tout en laissant d’autres blocs à une extension future. La RFC 5771 a ensuite décrit 239/8 comme espace local à un domaine, sans politique ordinaire d’attribution IANA. Le registre IANA conserve aujourd’hui le lien avec la RFC 2365.

Ces documents établissent une catégorie et une règle d’attribution. Ils ne prouvent pas qu’un réseau a installé une frontière. Le même numéro de groupe peut être réutilisé dans deux régions, justement parce que l’unicité n’est pas exigée au-delà de la frontière. Une fuite peut donc exposer des données, consommer une capacité imprévue ou rencontrer un autre usage local du même numéro.

Il serait trompeur d’appeler ce mécanisme « multicast privé » si le mot privé suggère une propriété, une identité ou une protection comparable à un pare-feu. L’adresse ne contient ni le nom de l’organisation, ni une autorisation, ni un résultat de filtrage.

La frontière se trouvait sur chaque interface

Un routeur conforme au modèle doit permettre une définition de portée par interface. Le routeur de frontière refuse de transférer, dans les deux directions, les paquets correspondant à cette définition. La symétrie n’est pas décorative : sur un réseau multi-accès, la direction d’arrivée d’un paquet ne suffit pas à désigner de façon stable l’intérieur et l’extérieur.

Le contrôle ne se limite pas au paquet observé. Pour les groupes en mode dense, la frontière doit toujours être élaguée. Pour les groupes en mode sparse, le routeur n’accepte pas de join pour la plage bloquée. Une ACL qui arrête un flux de données mais laisse l’état multicast traverser la limite ne reconstitue donc pas à elle seule le mécanisme de la RFC.

La région doit en outre être connectée et convexe : un chemin entre deux points internes ne devrait pas quitter la région avant d’y rentrer. Les routeurs qui l’entourent doivent partager des définitions cohérentes. Lorsqu’une topologie fait se croiser des portées, la RFC recommande de ne pas faire aussi se croiser leurs plages d’adresses. Une seule configuration correcte ne compense pas une autre sortie oubliée.

La preuve devait suivre l’exécution

Un audit utile conserve plusieurs reçus. Le premier confirme que l’adresse appartient à la plage prévue. Un document de politique nomme la région, son propriétaire et ses liaisons frontières. La preuve de configuration montre la valeur chargée sur chaque interface. La preuve du plan de contrôle montre l’élagage ou le refus de join. La preuve d’exécution relie la règle au chemin effectivement programmé. Des essais actifs observent les deux côtés. Enfin, le chiffrement et la distribution de clés fournissent une preuve séparée de confidentialité.

Ces couches ne sont pas interchangeables. Une base de configuration peut être juste tandis qu’un ASIC conserve un ancien état. Le chemin principal peut bloquer et le secours laisser passer. Un compteur nul peut indiquer qu’aucun paquet d’essai n’a atteint l’interface, non que la frontière fonctionne. Une capture extérieure vide ne dit rien si la source était silencieuse.

La primauté du code en fonctionnement, la spécification initiale minimale et la distinction des couches de réalité sont des lectures éditoriales postérieures, pas des exigences de la RFC 2365. Elles fournissent néanmoins une discipline : garder la sémantique commune de l’adresse, les choix topologiques locaux et le résultat exécuté dans des dossiers différents.

La section sécurité refusait la promesse facile

Le texte de 1998 avertissait explicitement qu’une organisation ne devait pas compter sur la portée administrative pour retenir des données sensibles. Une erreur de configuration, un bug dans le code de portée ou un autre problème du routeur de frontière pouvait transférer le paquet hors de sa région correcte. Le remède indiqué était un mécanisme de confidentialité, par exemple le chiffrement.

La RFC précisait aussi que le routeur de frontière n’était pas nécessairement un pare-feu. Il ne prouvait ni l’identité de l’émetteur, ni le droit du récepteur, ni la réception par une application. La portée contrôlait un chemin de transfert chez les routeurs qui exécutaient correctement la règle.

Voilà la leçon durable : un espace d’adresses peut publier une intention sans posséder son moyen d’exécution. Pour dire qu’un flux est resté dans sa région, il faut relier le plan, les interfaces, l’état de routage et l’observation réelle — et conserver le chiffrement comme protection indépendante.

Sources