Summary

  • La RFC 2375 permettait à un identifiant permanent de conserver le même sens dans plusieurs portées IPv6, tout en précisant que chaque adresse de portée différente désignait un autre groupe.
  • L’inscription dans un registre prouvait une coordination de nommage, non la présence d’auditeurs, l’état d’acheminement, l’admission d’une source ou la réception par une application.

Une première carte, volontairement incomplète

IPv6 disposait déjà d’un format multicast. Il lui manquait une convention commune pour les destinations indispensables aux nœuds, aux routeurs, aux protocoles de routage, au temps réseau ou aux outils de conférence hérités de l’Internet expérimental.

La RFC 2375 a produit cette première carte. Elle n’a pas copié mécaniquement l’espace IPv4 : seules les affectations jugées pertinentes ont été adaptées, les autres ont été écartées, les commentaires ont été sollicités et tout le reste est demeuré réservé. Le texte se présentait comme un point de départ, pas comme l’inventaire définitif du multicast IPv6.

Cette modestie comptait. Une table partagée empêchait deux protocoles de donner des sens concurrents à la même valeur. Elle ne disait encore rien sur l’existence d’un service en exploitation.

Le X ne signifiait pas « partout à la fois »

Certaines adresses étaient attachées à une portée précise. D’autres employaient X dans le champ de portée : un identifiant permanent pouvait alors apparaître dans chacune des portées autorisées. On aurait pu lire cette écriture comme un seul groupe qui s’étendrait progressivement.

La RFC 2375 fermait cette interprétation. Deux adresses ne différant que par leur portée représentaient des groupes différents. Chaque nœud devait rejoindre chacun de ces groupes séparément.

Le sens du service pouvait rester stable. L’adresse complète, elle, changeait. Dans l’exemple architectural de la RFC 2373, le même identifiant NTP pouvait viser les serveurs présents sur le même nœud, le même lien, le même site ou dans la portée globale. Ces expressions partageaient une signification, pas une population automatiquement commune.

La portée fabriquait le destinataire

La portée n’était pas une étiquette d’affichage. Elle limitait la région topologique du groupe, et les routeurs ne devaient pas transférer le trafic au-delà de cette limite. « Tous les routeurs » sur une interface, sur un lien ou sur un site posait trois questions différentes à trois ensembles différents.

Pour une adresse temporaire, la séparation était plus forte encore. La RFC 2373 indiquait que la même valeur temporaire sur un autre site, dans une autre portée ou face à un groupe permanent homonyme n’établissait aucune parenté.

La ressemblance des bits ne suffisait donc pas à produire une continuité opérationnelle. Le groupe n’existait qu’à l’intérieur de son contexte complet.

Le registre n’avait pas de membres

Une affectation permanente créait un reçu utile : tel identifiant avait tel sens selon telle règle. Elle n’ouvrait pas un socket, ne choisissait pas une interface et n’informait pas le routeur voisin qu’un auditeur attendait du trafic.

La RFC 2710 a rendu cette étape visible avec Multicast Listener Discovery. Le protocole permettait aux routeurs de découvrir les adresses multicast intéressant leurs liens directement connectés. Les hôtes passaient entre des états sans auditeur, avec rapport différé ou avec auditeur inactif ; requêtes et rapports concernaient une adresse sur une interface.

Ainsi, l’inscription IANA et le rapport d’écoute répondaient à deux questions différentes. La première stabilisait la signification. Le second matérialisait, pour un temps et un lieu précis, l’existence d’un destinataire.

Trois formes de permanence

La RFC 3307 a ensuite distingué les adresses multicast permanentes, les identifiants permanents de groupe et les adresses dynamiques. Une adresse permanente réservait une forme complète. Un identifiant permanent pouvait désigner un même service fourni par plusieurs serveurs et dans plusieurs portées. Une allocation dynamique organisait un usage temporaire.

Chacune de ces catégories réduisait un risque de collision. Aucune ne prouvait qu’un chemin multicast était installé ou qu’un paquet arriverait. Même une identité globale de service devait être instanciée dans une adresse de portée, puis rejointe sur une interface.

La RFC 3306 a encore lié certaines adresses multicast à un préfixe unicast : la portée multicast ne devait pas dépasser celle du préfixe incorporé et sa durée de vie ne devait pas lui survivre. L’identité réutilisable restait enfermée dans une autorité d’allocation, un espace et une durée.

La table a survécu en changeant

La RFC 4291 a conservé le modèle des groupes délimités par leur portée. La RFC 7346 a plus tard attribué la valeur 3 à la portée « realm-local » et précisé la nomenclature. Le registre IANA actuel sépare toujours les valeurs de portée, les adresses à portée fixe, les adresses variables, les identifiants fondés sur un préfixe unicast et les identifiants dynamiques.

Cette continuité prouve l’utilité de la coordination. Elle ne transforme pas la table de 1998 en télémétrie. Une valeur peut rester réservée sans trafic contemporain ; une nouvelle affectation peut apparaître bien après la RFC 2375 ; un service enregistré peut n’avoir aucun auditeur sur un lien donné.

Le registre décrit ce qui peut être nommé sans collision. Le réseau en marche montre qui écoute réellement.

L’autorité s’arrêtait au bon endroit

La « spécification initiale minimale » de Lu Heng éclaire le choix de 1998 : ouvrir juste assez de l’espace commun, réserver le reste et laisser l’expérience corriger le plan. La primauté du code en fonctionnement place ensuite l’autorité dans les jointures, les rapports, l’état de transfert et les paquets observés.

Les couches de réalité empêchent enfin la confusion : nom de service, identifiant, portée, adresse complète, appartenance d’interface, état appris par le routeur, route multicast, source admise, paquet reçu et résultat applicatif sont autant de reçus séparés.

La RFC 2375 a donné des noms aux premiers groupes. Sa leçon durable tient dans la limite : un nom stable ne fabrique pas ses membres.