Zusammenfassung

  • RFC 1469 verlangte von multicastfähigen Systemen auf demselben physischen Token-Ring, dieselbe Hardware-Adressmethode zu verwenden. Die Wahl war pro Schnittstelle konfigurierbar; Bridges konnten zwischen Methoden übersetzen.
  • Die gemeinsame funktionale Adresse löste eine lokale Empfangsauswahl unter Knappheit. Sie bewies weder, dass ein Frame IP-Multicast war, noch dass ein Host der Gruppe angehörte; RFC 1112 hält diese Zustände getrennt.

Der IP-Gruppenname war kein Befehl an die Karte

Eine IP-Multicast-Adresse benennt eine Hostgruppe, sagt einer lokalen Netzwerkkarte aber nicht von selbst, welche Frames sie nach oben liefern soll. Nach RFC 1112 ist die Gruppe dynamisch: Hosts können eintreten und austreten, und ein Host darf an eine Gruppe senden, ohne Mitglied zu sein. Mitgliedschaft wird je Schnittstelle geführt. Dieser Zustand der IP-Schicht wird lokal umgesetzt, geht aber nicht in einer MAC-Adresse auf.

RFC 1469 behandelt diese Umsetzung für Token Ring. Es gab drei Möglichkeiten, ein IP-Multicast-Ziel als Hardware-Adresse darzustellen: die All-Rings-Broadcast-Adresse, eine zugewiesene funktionale Token-Ring-Adresse oder bereits zugewiesene IEEE-IP-Multicast-Gruppenadressen. Entscheidend ist die Koordinationsregel: Alle Systeme, die auf einem physischen Ring IP-Multicast unterstützen, müssen dieselbe Hardware-Adresse vereinbaren. Deshalb muss die Methode an einer Schnittstelle konfigurierbar sein. Eine Bridge kann die Verfahren auf den von ihr verbundenen Ringen übersetzen.

Die gewählte Adresse ist damit eine lokale Empfangskonvention, kein Eigentumstitel für die Gruppe und keine universelle materielle Identität. Ein Ring konnte eine Darstellung verwenden, ein anderer eine andere; die Bridge hielt die Kommunikation über die Grenze hinweg aufrecht. Vereinheitlicht wurde der Empfang innerhalb eines Rings, nicht die Behauptung, sechs Oktette enthielten die gesamte Wahrheit über den IP-Gruppenzustand.

Knappheit zwang mehrere Bedeutungen in ein Signal

Funktionale Token-Ring-Adressen waren für häufige Funktionen wie Ringüberwachung, NetBIOS, Bridges und LAN Manager vorgesehen. RFC 1469 nennt nur 31 solcher Adressen. Nicht zusammenhängende Funktionen konnten also dieselbe Adresse teilen.

Im funktionalen Verfahren wurden alle IP-Multicast-Adressen auf 03-00-00-20-00-00 in kanonischer Form abgebildet, beziehungsweise auf C0-00-00-04-00-00 in der für Token-Ring-Schnittstellen üblichen nichtkanonischen Form. Diese Verdichtung war nützlich: Sie gab begrenzten Adaptern ein Signal, einen Frame weiter zu prüfen. Sie schuf keine exklusive Zuordnung zwischen einer MAC-Adresse und einer IP-Gruppe.

RFC 1469 zieht die notwendige negative Folgerung selbst: Ein Frame an diese funktionale Adresse ist allein deshalb nicht zwingend ein IP-Multicast-Frame. Ein anderes Protokoll kann dieselbe Adresse verwenden. Das MAC-Ziel öffnet die Prüfung; es stellt kein Zertifikat über das getragene Protokoll aus. Die Auslegung der höheren Schicht bleibt erforderlich.

Der Filter empfing, die Mitgliedschaft stand in einem anderen Buch

RFC 1112 trennt die beiden Aufgaben. Das IP-Modul hält Gruppenmitgliedschaften je Schnittstelle und meldet ihre Anwesenheit mit IGMP an unmittelbar benachbarte Multicast-Router. Das lokale Netzmodul hat eine engere Aufgabe: Es bildet IP-Gruppenadressen auf lokale Adressen ab, um seinen Empfangsfilter zu aktualisieren.

Die beiden Aufzeichnungen müssen nicht übereinstimmen. Reicht die Filterfähigkeit der Hardware nicht aus, darf das lokale Modul einen Leave-Wunsch ignorieren oder Pakete für mehr Adressen nach oben liefern als angefordert. Dass eine Schnittstelle einen Frame gesehen hat, beweist daher keinen passenden Mitgliedschaftseintrag. Ebenso beweist eine Sendung an eine Gruppe nicht die Mitgliedschaft des Senders. IP-Ziel, MAC-Filter, Mitgliedschaftszustand und IGMP-Report gehören zusammen, sind aber keine austauschbaren Belege.

RFC 1469 empfahl die IEEE-Methode, wenn der Controller sie tragen konnte. Wenn nicht, war die funktionale Adresse besser als All-Rings-Broadcast. Zugleich blieben die weniger leistungsfähigen Verfahren aus Kompatibilitätsgründen erhalten. Die Geschichte handelt nicht davon, dass alle Gruppen zu einer wurden, sondern davon, wie unterschiedliche Hardwarefähigkeiten eine gemeinsame Empfangsregel behalten konnten.

Aus der gemeinsamen funktionalen Adresse lassen sich deshalb weder Person, konkrete Maschine noch Hörerzahl ablesen. Sie beweist nicht, dass die Nutzlast IP-Multicast war, dass ein Router sie über den Ring hinaus weiterleitete, dass ein ferner Empfänger sie bekam oder dass eine Anwendung wirkte. Sie beschreibt eine lokale Auswahlentscheidung. Gerade diese Begrenzung macht den historischen Vertrag der RFC belastbar.

Quellen