Sujet
Routage multicast
Au sein de la facette Sujet, la veille thématique Routage multicast rassemble des articles qui partagent un même sujet, un même signal ou un même thème de suivi. Cette page offre aux lecteurs un parcours plus riche à travers les reportages associés, les preuves issues de sources publiques, les acteurs du marché et les implications pour l’infrastructure, avec suffisamment de contexte pour comprendre pourquoi le sujet compte pour les mouvements d’entreprises, les décisions de gouvernance, l’exposition régionale et le risque opérationnel. Les lecteurs peuvent comparer les signaux récurrents, les organisations concernées, les preuves publiques, le contexte du marché, la continuité de service, les achats, la concurrence, la conformité et les questions de planification stratégique liées au sujet, au lieu de se contenter d’une liste succincte d’articles correspondants. Elle explique ce que couvre le sujet, quels acteurs ou politiques de l’infrastructure sont impliqués, quelles preuves étayent la couverture et pourquoi le sujet peut être important pour les opérateurs, les clients, les investisseurs et les lecteurs de politiques publiques.

Histoire d'Internet
RFC 2357 : l’IETF a fait de la publication un test de confinement pour le multicast fiable
Distribuer une seule copie à mille destinataires paraît économe. Faire revenir mille demandes de réparation, maintenir le transfert jusqu’au dernier retardataire et traverser un arbre mondial peut transformer cette économie en dette imposée au reste du réseau. En 1998, RFC 2357 a…

IETF
Multicast IPv6 : un filtre mDNS peut transformer le silence en feu vert
L'attribution sans serveur central semble simple: choisir une adresse, demander si elle est prise, puis continuer si personne ne proteste. Le projet soumis à la dernière consultation de l'IETF rappelle que cette simplicité dépend d'une condition très concrète: les objections…

IETF
BIER Ping franchit le vote, pas encore la dernière étape du diagnostic
Un accusé de réception ne suffit pas à décrire une distribution multicast. Le nouveau protocole BIER Ping and Trace promet de rendre les pannes plus localisables, mais l'approbation de l'IESG doit encore être reliée à des numéros attribués, à un texte publié et à des…

Histoire d'Internet
L’adresse disait « reste ici ». Seul le routeur traçait la frontière : RFC 2365
Une destination en 239/8 signale une portée administrative; elle ne construit pas le mur qui la fait respecter. La RFC 2365 a confié ce travail à des routeurs de frontière configurés interface par interface. Une règle absente, asymétrique ou mal exécutée suffit donc à transformer…

Histoire d'Internet
Le Join n’avait aucun reçu : l’arbre survivait par rafraîchissement — RFC 2117
Dans RFC 2117, un arbre multicast clairsemé n’apparaissait jamais comme une transaction achevée. Une indication locale créait un état, des Join/Prune le renouvelaient routeur par routeur, un nouveau flux passait d’abord par des Register, puis certaines branches rejoignaient…

Histoire d'Internet
Le compteur a franchi la fenêtre d’un récepteur sans nommer l’émetteur : RFC 2085
Le RFC 2085 plaçait un compteur anti-rejeu de 64 bits dans une transformation HMAC-MD5 d’Authentication Header, uniquement si l’association de sécurité le prévoyait. Un récepteur pouvait admettre un numéro inédit dans sa propre fenêtre de désordre. Cette décision disait « nouveau…

IETF
EVPN peut sélectionner une source multicast, pas certifier la redondance
Deux sources peuvent émettre le service que l’exploitation considère comme identique, tandis qu’un récepteur n’en affiche qu’une copie nette. RFC 9856 organise cette sélection dans un EVPN. Il ne démontre ni l’équivalence des flux, ni la santé de la source retenue, ni une bascule…

IETF
TreeDN : moins de copies, mais quelle preuve de diffusion ?
Séparer la réplication du contenu peut alléger la distribution d’un direct. Cette séparation laisse pourtant au diffuseur une question entière: le programme est-il arrivé à temps chez le spectateur autorisé ?

Histoire d'Internet
Eve Schooler et l’invitation qui ne transportait pas la conversation
Une adresse n’est pas une voix, et une invitation n’est pas une conversation. En contribuant aux premiers travaux sur SIP, Eve Schooler a aidé à faire de cette évidence une frontière d’architecture: trouver quelqu’un et lui proposer une session devait pouvoir rester distinct du…

IETF
La racine anycast a survécu, pas l’état multicast
L’adresse partagée répond de nouveau. La route RPF s’est recalée et les sondes de disponibilité sont au vert. Pourtant, certains sites récepteurs n’obtiennent toujours rien. Le nouvel ITR physique a repris l’adresse anycast, mais pas nécessairement la mémoire des flux `(S-EID,G)`…

IETF
Sans Hello, PIM Light déplace deux décisions de redondance hors de l’interface
La RFC 9739 permet de transmettre l’état multicast sans établir au préalable un voisinage PIM. Le domaine peut ainsi alléger sa frontière, mais doit conserver ailleurs l’élection du routeur qui relaie les demandes, le choix d’un seul flux amont et le retrait effectif des…

IETF
Une sonde de classe supérieure ne mesure pas tous les services BIER
La précision d’une mesure ne garantit pas la justesse de la conclusion qu’on lui fait porter. Dans un cas bien délimité, RFC 9974 permet d’observer la continuité à la classe de service la plus élevée et d’en déduire l’état de continuité des classes inférieures. La nuance…

IETF
Le routeur se souvenait d’un auditeur. Le flux, lui, n’est jamais arrivé : RFC 9777
MLDv2 donne au routeur IPv6 une mémoire rigoureuse mais locale de l’intérêt multicast. Cette mémoire devient trompeuse dès qu’on lui demande de prouver l’autorisation d’une application, la construction de l’arbre ou la livraison effective.

IETF
Un arbre P2MP ne vaut pas mandat de diffusion
Une réponse à un ping peut être exacte et néanmoins répondre à la mauvaise question. Elle peut montrer qu’une instance d’arbre MPLS déterminée atteint les feuilles attendues. Elle ne dit pas si ces feuilles sont encore les destinataires autorisés du service. Le RFC 9960 construit…

Histoire d'Internet
RFC 2022 : le registre indiquait les destinataires, pas le circuit
Dans RFC 2022, le serveur MARS savait associer un groupe IP aux adresses ATM déclarées dans son cluster. Il ne transportait pourtant aucun paquet multicast. Entre la liste reçue et la donnée livrée subsistait une opération décisive: chaque émetteur devait construire, entretenir…

Dossier
Un groupe de transport demandé ne prouve pas les récepteurs : RFC 9798
Dans RFC 9798, une adresse de groupe peut occuper le champ Receiver RLOC et provoquer la création d’un état réel au niveau de l’ITR racine. Elle ne devient pas pour autant une liste de sites récepteurs. Le contrôle sérieux commence précisément là: relier la demande du groupe…

Histoire d'Internet
Le paquet avait atteint la zone, pas encore la personne : RFC 2009
En 1996, RFC 2009 proposait de router vers une partition géographique assez précise pour le réseau, puis de laisser la périphérie vérifier le polygone exact: une économie d’état qui déplaçait aussi la charge de la preuve.

Dossier
Deux sources, un choix, mais aucune preuve de continuité : RFC 9856
La redondance multicast ne vaut que si le récepteur obtient un flux unique et exploitable. RFC 9856 organise le choix dans un EVPN; elle ne transforme pas ce choix en verdict de service.

IETF
Les standards de l’IETF deviennent une infrastructure opérationnelle — mais qui contrôle la continuité ?
Les standards de l’IETF ne font pas fonctionner directement les réseaux. Ils définissent plutôt les états, les échanges, les mécanismes de récupération et les dépendances de sécurité que les opérateurs doivent ensuite implémenter, maintenir et mesurer. Quand un chemin de routage…

Histoire d'Internet
Comment une norme IETF devient une frontière administrée de l’espace multicast IPv6
La révision de l’espace d’adresses multicast IPv6 ne se limite pas à une nouvelle classification technique. RFC 10028 montre comment un consensus de l’IETF, relayé par la gestion du registre IANA, transforme une convention normative en frontière administrative pour les…
