Résumé

  • RFC 1469 imposait aux systèmes multicast d’un même anneau Token Ring de choisir la même méthode d’adresse matérielle; le choix pouvait varier par interface et être traduit par un pont.
  • L’adresse fonctionnelle commune réglait une sélection locale sous contrainte. Elle ne démontrait ni que la trame était du multicast IP ni qu’un hôte appartenait au groupe, états que RFC 1112 distingue.

Le nom IP ne descendait pas tel quel sur l’anneau

Une adresse multicast IP désigne un groupe d’hôtes, mais elle ne décrit pas à elle seule le mécanisme qui fait remonter une trame depuis un adaptateur local. RFC 1112 décrit un groupe comme un ensemble dynamique: un hôte peut le rejoindre ou le quitter, et il peut aussi lui envoyer un datagramme sans en être membre. L’appartenance est liée à une interface. Cette sémantique IP devait encore être traduite pour le réseau local.

RFC 1469 traite précisément cette traduction pour Token Ring. Elle propose trois manières d’associer une destination multicast IP à une destination matérielle: diffuser sur tous les anneaux, employer une adresse fonctionnelle Token Ring attribuée, ou employer les adresses de groupe multicast IP attribuées par l’IEEE. Le détail décisif n’est pas le dessin des bits, mais la règle de coordination: tous les systèmes qui font du multicast sur un anneau physique doivent adopter la même adresse matérielle. La méthode doit donc être configurable pour une interface; un pont peut faire la conversion entre les méthodes de ses anneaux.

Cette règle ne désigne pas un souverain du groupe. Elle fixe une convention locale de réception. Deux anneaux peuvent ne pas retenir la même solution, sans que l’adresse IP cesse de viser le même groupe. Le pont rend cette pluralité praticable. Ce qui est commun est l’exigence d’interopérer sur chaque anneau, non une identité universelle de la trame au niveau matériel.

La rareté a forcé une adresse commune

Les adresses fonctionnelles Token Ring étaient destinées à des services largement employés, notamment la surveillance d’anneau, NetBIOS et le pontage. RFC 1469 rappelle qu’il n’en existait que 31. Des fonctions sans lien pouvaient donc partager la même adresse.

Pour le mode de repli, toutes les adresses multicast IP ont été ramenées à une seule adresse fonctionnelle: 03-00-00-20-00-00 sous forme canonique, et C0-00-00-04-00-00 sous la représentation usuelle d’une interface Token Ring. Cette compression rendait la réception possible avec du matériel limité. Elle supprimait aussi toute prétention à une correspondance un-à-un entre une adresse de groupe IP et l’adresse de l’adaptateur.

RFC 1469 formule elle-même la limite: une trame envoyée à cette adresse fonctionnelle n’est pas, pour cette seule raison, une trame multicast IP. Un autre protocole peut employer la même adresse. L’adresse matérielle est donc un seuil d’examen, non le verdict sur le contenu de la trame. Il faut encore interpréter la couche supérieure.

Filtrer n’était pas tenir le registre des membres

RFC 1112 sépare les dossiers que l’on confond facilement. Le module IP conserve les appartenances de groupes et emploie IGMP pour signaler leur présence aux routeurs multicast voisins. Le module de réseau local reçoit une mission plus étroite: convertir les adresses de groupe IP en adresses locales et mettre à jour son filtre de réception.

Cette séparation n’est pas décorative. Le module local peut ignorer une demande de départ, ou livrer des paquets destinés à davantage d’adresses que celles demandées, si son filtrage est insuffisant. Voir une trame ne suffit donc pas à établir une entrée d’appartenance. Inversement, envoyer vers un groupe ne suffit pas à dire que l’émetteur y appartient. Le filtre, l’état IP, le datagramme envoyé et le rapport IGMP restent des éléments reliés mais différents.

RFC 1469 recommandait l’option IEEE lorsqu’elle était supportée. Lorsque les contrôleurs ne le permettaient pas, l’adresse fonctionnelle était préférable à la diffusion générale. Les exigences de compatibilité forçaient les systèmes les plus capables à conserver les méthodes moins capables. Ce n’était pas l’effacement des groupes dans une seule masse: c’était la conservation d’une interopérabilité entre matériels inégaux.

La leçon historique tient dans cette modestie. L’anneau pouvait convenir d’un filtre, l’interface pouvait changer de méthode, le pont pouvait traduire. Rien de cela ne certifiait une identité, une permission, un acheminement hors de l’anneau, une réception distante ou un effet applicatif. Une adresse partagée rendait une décision locale exécutable; elle ne portait pas toutes les vérités que l’on pourrait vouloir lui faire dire.

Sources