Zusammenfassung

  • Source-Specific Multicast bezeichnet einen Kanal durch das Paar aus Quelle und Gruppe (S,G).
  • Zwei private Sender dürfen dieselbe Gruppe verwenden und bleiben durch verschiedene private Quelladressen unterscheidbar.
  • Beim Weg nach außen schreibt der NAT die Quelladresse um, während Multicast-Ziel und Zielport unverändert bleiben.
  • Werden beide Sender durch dieselbe öffentliche Quelle dargestellt, können zwei private Paare zu demselben öffentlichen Paar werden.
  • RFC 5135 hält fest, dass der Verkehr dann nicht mehr eindeutig identifizierbar ist und sich beim Empfänger vermischen kann.
  • Ein multihomed Duplikat wiederholt einen Strom über mehrere Pfade; Quellen-Aliasing lässt mehrere Ströme wie einen erscheinen.
  • Die vorgeschriebene Abschaltmöglichkeit für ausgehenden Multicast behandelt das erste, aber nicht automatisch das zweite Problem.
  • Ein korrekt aggregierender IGMPv3-Proxy schützt die Mitgliedschaftslogik, stellt jedoch keine verschwundene Quellidentität wieder her.
  • Endpoint-Independent Mapping stabilisiert eine Übersetzungsregel und garantiert keine exklusive öffentliche Identität je privatem Sender.
  • Gruppenwechsel ist nur eine vorläufige Ausweichmöglichkeit, deren Verteilung und Annahme bei allen Empfängern belegt werden muss.
  • SSRC und CNAME können eine Anwendungsebene zur Unterscheidung liefern, sofern ihre gesamte Verarbeitung nachgewiesen wird.
  • Der Abschlussbeleg muss private Quelle, Mapping, öffentlich angekündigtes Paar, Empfängerauswahl und Ergebnis verbinden.

Zwei gegensätzliche Kardinalitätsfehler

Ein Multihoming-Fehler erhöht die Zahl der beobachteten Kopien. Ein interner Strom verlässt das Netz über zwei Übersetzer oder zwei Pfade und erscheint außen doppelt. RFC 5135 verlangt deshalb für ausgehenden UDP-Multicast eine Möglichkeit zur Deaktivierung. Betreiber sollen verhindern können, dass eine Topologie unerwünschten öffentlichen Verkehr dupliziert.

Das SSM-Aliasing in Appendix A verändert die Kardinalität in die andere Richtung. Nehmen wir zwei private Sender A und B, beide auf Gruppe G. Innen existieren (A,G) und (B,G). Wenn der NAT beide Quelladressen durch N ersetzt, sieht die Außenseite für beide (N,G). Zwei identifizierbare Kanäle wurden zu einem öffentlichen Auswahlbegriff verdichtet.

Beide Fehler können ähnliche Zähler erzeugen. Mehr Daten als erwartet können aus einer doppelten Übertragung desselben Stroms stammen oder aus zwei verschiedenen Strömen, die auf denselben öffentlichen Kanal einzahlen. Selbst eine Paketaufnahme außen beantwortet die Frage nicht, wenn die Zuordnung zu den privaten Quellen fehlt.

Darum muss eine Untersuchung zuerst fragen, welche Kardinalität sich geändert hat. Kam ein privater Strom über mehrere öffentliche Pfade? Oder kamen mehrere private Quellen unter einer öffentlichen Kennung an? Ohne diese Unterscheidung kann eine Abschaltmaßnahme den falschen Mechanismus behandeln.

Der öffentliche Paarbegriff hat Information verloren

SSM benutzt nicht bloß G. Die Quelle S ist Teil des Selektors. Dass A und B dieselbe Gruppe wählen, ist innen unproblematisch, solange ihre Adressen sichtbar bleiben. Ein Empfänger kann genau (A,G) oder (B,G) verlangen.

RFC 5135 fordert für Verkehr von innen nach außen die Umschreibung der Quell-IP. NAPT kann zusätzlich den Quellport ändern und muss bei erwarteten Antworten ein Mapping anlegen. Multicast-Zieladresse und Zielport werden nicht übersetzt. Mit einer gemeinsamen Außenadresse N bleibt also G konstant, während A und B verschwinden.

Der RFC beschreibt den daraus folgenden Verkehr als nicht mehr eindeutig identifizierbar und potenziell vermischt. Das ist keine Behauptung über jeden NAT oder jede Anwendung. Es ist eine Bedingung: gleiche Gruppe, verschiedene private Quellen, gleiche öffentliche Quellrepräsentation. Unter dieser Bedingung kann das öffentliche (S,G) allein die private Herkunft nicht beweisen.

Weiterleitung und Bedeutung laufen auseinander. Der NAT kann alle Pakete vorschriftsmäßig übertragen. Der Empfänger kann ohne Verlust lesen. Dennoch kann er auf IP-Ebene nicht mehr zeigen, ob ein Paket von A oder B kam. Ein grüner Transportstatus kann daher neben einer fehlgeschlagenen Quellenauswahl stehen.

Was Mapping-Konsistenz tatsächlich zusagt

Endpoint-Independent Mapping verlangt, dass die Abbildung eines internen Endpunkts nicht vom jeweiligen Unicast- oder Multicast-Ziel abhängt. Paired address pooling empfiehlt bei mehreren Außenadressen, denselben internen Endpunkt an derselben öffentlichen Adresse zu halten. Beide Regeln machen das Verhalten nachvollziehbarer.

Keine der Regeln verspricht, verschiedene interne Endpunkte auf verschiedene öffentliche Quelladressen abzubilden. Jeder der beiden Sender kann ein stabiles Mapping besitzen und trotzdem unter N erscheinen. Stabilität bedeutet hier Wiederholbarkeit der Transformation, nicht Erhaltung aller Identitätsdimensionen.

Das hat Folgen für die Beweisführung. Ein Mapping-Datensatz muss mindestens Generation, interne Quelle, öffentliche Adresse, gegebenenfalls übersetzten Port, Pooling-Entscheidung und Laufzeit enthalten. Um Aliasing zu erkennen, muss er mit gleichzeitig aktiven Quellen und Gruppen korreliert werden. Ein isolierter Eintrag kann die Viele-zu-eins-Beziehung verschleiern.

IGMP aggregiert Zustände, nicht Biografien

Der Proxy reicht Berichte privater Hosts nicht einfach weiter. Er sammelt Downstream-Mitgliedschaften und Quellfilter, berechnet einen Gesamtzustand und erzeugt eigene Upstream-Berichte. IGMPv1 darf, IGMPv2 muss und IGMPv3 sollte unterstützt werden. Wer IGMPv3 unterstützt, muss SSM und die einschlägige Filtersemantik beherrschen.

Die Aggregation ist nötig, weil das naive Verschachteln unabhängiger Zustandsänderungen keine gültige Folge für einen einzelnen Upstream-Reporter ergeben muss. Tritt ein Host bei, während ein anderer austritt, kann vorübergehendes Blackholing entstehen. Der Proxy verhindert, dass mehrere private Zustandsmaschinen fälschlich wie eine ungeordnete einzelne auftreten.

Diese Leistung endet am Kontrollzustand. Ein Außenfilter sieht die Quelle, die außen existiert. Nachdem A und B als N dargestellt werden, enthält ein korrekter IGMPv3-Bericht keine verborgene Rückübersetzung. Proxy-Gesundheit und Datenquellen-Aliasing schließen sich nicht gegenseitig aus.

Reichweite ist eine andere Achse

Standardmäßig darf administrativ begrenzter Verkehr aus 239.0.0.0/8 nicht nach außen weitergeleitet werden. Der Local Network Control Block 224.0.0.0/24 darf die Außengrenze ebenfalls nicht passieren. TTL eins kann einen Strom zusätzlich am lokalen Router halten.

Diese Regeln schützen räumliche Grenzen. Sie sagen, ob ein Paket den Bereich verlassen darf, nicht, welchen privaten Sender eine erlaubte öffentliche Quelle repräsentiert. Ein Scope-Zähler darf deshalb nicht als Identitätsprüfung erscheinen. Auch ein korrekt blockierter Strom belegt nur die Blockierung, nicht die Ursache einer anderen Empfängerbeobachtung.

Der Gruppenwechsel ist ein verteilter Vorgang

RFC 5135 überlässt eine allgemeine Lösung weiterer Untersuchung und empfiehlt vorläufig, dass SSM-Anwendungen einen Gruppenwechsel ermöglichen. Verwendet A G1 und B G2, entstehen trotz gemeinsamer Quelle N die Paare (N,G1) und (N,G2). Die verlorene Varianz wird über die Gruppenseite zurückgewonnen.

Der operative Aufwand liegt außerhalb des Feldes in der Benutzeroberfläche. Jemand muss die Kollision erkennen, eine zulässige Gruppe wählen, die Sitzungsbeschreibung aktualisieren, Filter und Berechtigungen ändern, alle Empfänger erreichen und den alten Kanal abbauen. Offline-Clients und Caches können die alte Angabe noch lange weiterverwenden.

Deshalb braucht jede Änderung eine Generation und einen Zeitraum. Der Senderbeleg zeigt, wann G2 aktiv war. Der Signalisierungsbeleg zeigt, welche Version veröffentlicht wurde. Der Empfängerbeleg zeigt, welche Version gelesen und welches Paar tatsächlich abonniert wurde. Erst der letzte Schritt macht aus einer Konfiguration eine wirksame Änderung.

Höhere Identität muss ebenfalls laufen

RTP stellt mit SSRC und CNAME Kennungen oberhalb von IP bereit. Weil RFC-1918-Räume hinter vielen NATs wiederverwendet werden, betont RFC 5135 eine korrekte CNAME-Erzeugung. Eine Anwendung kann damit Teilnehmer trotz gemeinsamer übersetzter Adresse unterscheiden.

Doch der Sender muss die Kennung erzeugen, Transport und Signalisierung müssen sie bewahren, der Empfänger muss Kollisionsregeln anwenden und die Anwendung muss sie dem richtigen Teilnehmer zuordnen. Eine SSRC-Kollision ist zudem nicht dasselbe wie ein SSM-Quellenalias. Beide Fehler brauchen eigene Diagnosen.

Für ASM mit RTP behandelt der RFC die Mapping-Lebensdauer. Eine Neuanlage kann die übersetzte Transportadresse verändern und RTP-Kollisionserkennung auslösen. Empfohlen werden 60 Minuten und die Löschung beim Verlassen der Gruppe; Ressourcenknappheit darf verkürzen, aber nicht unter das Minimum von RFC 4787. Der Timer belegt den Fortbestand des NAT-Zustands, nicht den Fortbestand der Empfängerbedeutung.

Die Beweiskette entlang des Pfades

Innen werden betriebliche Senderidentität, private Adresse, Gruppe, Konfigurationsgeneration, Zeitraum und das beobachtete Paar festgehalten. Am Rand folgen Mapping, Außenadresse, Port, Pooling und Ablauf. IGMP-Version, Downstream-Mitglieder, Filter und Upstream-Aggregat bleiben getrennte, verknüpfte Datensätze.

Außen werden angekündigtes, angefordertes und beobachtetes (S,G) verglichen. Die Überwachung muss erkennen, wenn mehrere private Quellen in dasselbe öffentliche Paar einspeisen oder derselbe Strom mehrere Pfade nimmt. Anwendungskennungen werden bis zur Kollisionsentscheidung und zum dargestellten Inhalt verfolgt.

Der Empfänger liefert den entscheidenden Beleg: welche logische Quelle gewählt, welche Pakete akzeptiert oder verworfen, ob Inhalte vermischt, Fristen eingehalten und welche Ausgabe gespeichert oder verarbeitet wurde. Erst dann ist aus „weitergeleitet“ ein belegtes „wie beabsichtigt angekommen“ geworden.

Quellen

  1. RFC 5135, HTML
  2. RFC 5135, Text
  3. RFC-Editor-Eintrag
  4. IETF-Datatracker-Eintrag
  5. Dokumenthistorie
  6. Errata-Suche
  7. RFC 4787
  8. RFC 4605
  9. RFC 3376
  10. RFC 4607
  11. RFC 5760
  12. RFC 3550
  13. RFC 2365
  14. RFC 5771
  15. RFC 1918
  16. RFC 8085
  17. IANA-Register für Multicast-Adressen
  18. IANA-Register als XML
  19. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  20. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  21. Running-Code Primary