Zusammenfassung

  • Ein empfangender ETR darf einen multicastfähigen Receiver RLOC verwenden, wenn das LISP-Core-Underlay IP-Multicast unterstützt. Welche beitretbare Gruppe er wählt, bleibt seine lokale Entscheidung.
  • Der Root-ITR legt für jede eindeutige Underlay-Abbildung einen OIF-Listeneintrag an. Muss er ETRs verfolgen, verwendet er die Quell-IP des Join/Prune, die eine ETR-RLOC-Adresse sein muss.
  • PIM-Authentisierung kann Herkunft und Integrität einer Anfrage stützen; Gruppenzuständigkeit, Pfadfähigkeit, Mitgliedschaft und Lieferung bleiben unbewiesen.

Gruppenwert und Absender dürfen nicht zu einem Datensatz verschmelzen

Bei Transport=0 bedeutet ein multicastfähiger Receiver RLOC: Der ETR möchte den gekapselten Strom auf dieser Underlay-Gruppe empfangen. Der Wert sagt nicht, wie viele ETRs angefragt haben. Dafür schreibt RFC 9798 eine andere Quelle vor. Wenn der ITR die sendenden ETRs verfolgen muss, nutzt er die Quelladresse der eingehenden PIM-Join/Prune-Nachricht; diese Quelle muss ein ETR RLOC sein.

Auch diese Adresse belegt noch keinen Endempfänger. Sie nennt den Tunnelrouter, nicht die Hosts dahinter, und sie berichtet keinen Datenempfang. Ein belastbares Register braucht daher eigene Felder für angeforderte Gruppe, sendenden ETR, angenommenes Mapping, Laufzeitzustand und beobachtetes Ergebnis.

RFC 9798 erschien im Juni 2025 als Experimental RFC und aktualisiert RFC 8059. Syntax und Semantik des Transport Attribute bleiben unverändert. Das Update gilt ausschließlich für Transport=0. Der Receiver RLOC darf nun eine Unicast-Adresse für unicastgekapselte oder eine Multicast-Adresse für multicastgekapselte Ströme enthalten. Letztere ist nur zulässig, wenn das Underlay des LISP Core IP-Multicast unterstützt.

Die Norm enthält dafür keinen Fernnachweis. Entscheidet sich der ETR für Multicast, wählt er eine Underlay-Gruppe, der er beitreten kann, bestimmt die Upstream-LISP-Site als Wurzel und erzeugt den Join/Prune nach RFC 8059. RFC 9798 erklärt die Gruppenwahl ausdrücklich zur lokalen Entscheidung außerhalb seines Geltungsbereichs. Der Nachweis muss aus Capability-Test, Bereichsrichtlinie, Konfiguration und Entscheidungszeitpunkt kommen.

Die Kardinalität verteilt die Betriebskosten

RFC 6831 beschreibt (S-EID,G)-Zustand in den Sites und (S-RLOC,G)-Zustand im Core. Der ITR kapselt, das Multicast-Underlay kann replizieren, und der empfangende ETR prüft nach der Entkapselung seinen inneren Zustand.

RFC 9798 erlaubt drei Abbildungen: mehrere Overlay-Ströme auf einen Underlay-Strom, einen Overlay-Strom auf mehrere Underlay-Ströme oder eine eindeutige Eins-zu-eins-Zuordnung. Viele-zu-eins spart Core-Bäume, kann aber unnötigen Verkehr erzeugen. RFC 6831 zeigt, dass eine Site gekapselte Pakete für eine nicht beigetretene Quelle erhalten und erst anhand ihres inneren (S-EID,G) verwerfen kann. Eins-zu-viele trennt nachgelagerte Bereichsanforderungen, erhöht jedoch die Replikation an der Wurzel. Eins-zu-eins erhöht Isolation und Zustandsbedarf.

Die Root-Pflicht ist messbar: Für jedes eindeutige Underlay-Multicast-Mapping wird ein neuer Eintrag in der outgoing interface list angelegt. Der ITR darf die Anzahl der zu erzeugenden Kopien durch lokale Richtlinien begrenzen. Eine universelle Quote definiert der RFC nicht. Für Kapazitätsaussagen sind Mapping-Schlüssel, OIF-Eintrag, angeforderte und zugelassene Kopien sowie die Begrenzungsentscheidung erforderlich.

Auch Adressbereiche sind lokal gebunden. Ein PxTR kann zwischen Site und externem LISP Core unterschiedliche Multicastbereiche benötigen. Hardwarebeschränkungen können den verfügbaren Bereich weiter einengen. Eine Gruppenadresse trägt diese Randbedingungen nicht in sich; sie muss mit Grenze, Plattform und Richtlinienversion verknüpft werden.

Verständliches Encoding ist keine Capability Discovery

RFC 5384 definiert den allgemeinen PIM-Join-Attribute-Rahmen. Baumwirksame Attribute sind nur in kooperierenden Domänen sinnvoll, in denen vorab bekannt ist, dass die beteiligten Router Encoding und Attribut verstehen. Im normalen PIM signalisiert eine Hello-Option diese Fähigkeit.

Für LISP-xTRs hält RFC 8059 dagegen fest, dass sie keine PIM Hellos austauschen. Es gibt keine Hello-Aushandlung; Systeme mit Unicast-Head-End-Replikation werden als kompatibel vorausgesetzt. Transport und Receiver RLOC sind nicht transitiv. RFC 9798 erweitert den Anwendungsfall, schafft aber weder eine universelle Fähigkeitsabfrage noch eine zentrale Gruppenvergabe.

Darum bleiben die Belege geschichtet. Parsererfolg betrifft die Darstellung. Geladene Bereichsregeln betreffen Absicht. Ein OIF-Eintrag betrifft Kontrollzustand. Multicasttabellen und Zähler betreffen laufende Weiterleitung. Empfangsprotokolle betreffen das Ergebnis. Ein grünes Gesamtflag kann diese Ebenen nicht ersetzen.

Authentisierung bestätigt keine Semantik

RFC 8059 macht die Attributsicherheit von der PIM-Nachricht abhängig. RFC 9798 nennt viele Join-Anfragen mit unterschiedlichen oder überlappenden Gruppen als Angriffsvektor; sie können legitimen Verkehr stören oder Replikationsressourcen erschöpfen. PIM-Authentisierung nach RFC 5796 könnte Anfragen validieren, zusätzlich werden Tracking und Höchstwerte je Quell-ETR-RLOC erwogen.

RFC 5796 schützt linklokale PIM-SM-Nachrichten mit IPsec und beschreibt Sicherheitsbeziehungen, Schlüssel und Peer-Authentisierung. Bei korrekter Konfiguration entsteht ein Nachweis über Herkunft und Integrität. Es entsteht kein Nachweis über Gruppenvergabe, Multicastfähigkeit aller Segmente, Mitglieder oder Lieferung.

Ein vollständiger Receipt korreliert deshalb Join/Prune-Bytes, geparste Attribute, Authentisierung und SA, Quell-RLOC, lokale ETR-Entscheidung, Root, Kardinalität, OIF, Rate-Limit, Core-Zustand, Paketdaten, Entkapselung und Empfang. Nur so bleibt sichtbar, an welcher Grenze eine Behauptung nicht mehr durch Beobachtung gedeckt ist.

Quellen