IPv6/Host/Multicast: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
| Zeile 20: | Zeile 20: | ||
; Um die Nutzung von Multicast bei Datenströmen zu verstehen, denken wir uns folgende Situation | ; Um die Nutzung von Multicast bei Datenströmen zu verstehen, denken wir uns folgende Situation | ||
Mehrere Zuschauer möchten die Live-Übertragung einer Sportveranstaltung als Videostream auf ihren IPv6-fähigen Endgeräten verfolgen | Mehrere Zuschauer möchten die Live-Übertragung einer Sportveranstaltung als Videostream auf ihren IPv6-fähigen Endgeräten verfolgen | ||
* Das können Computer, Smartphones oder netzwerkfähige Fernseher sein | * Das können Computer, Smartphones oder netzwerkfähige Fernseher sein | ||
* Das Videomaterial wird in Form eines Datenstroms von einem Server bereitgestellt, den wir Multicast-Quelle nennen | * Das Videomaterial wird in Form eines Datenstroms von einem Server bereitgestellt, den wir Multicast-Quelle nennen | ||
* Auf dem Weg zu den Zuschauern, im Folgenden Konsumenten genannt, passiert der Datenstrom zwei Router | * Auf dem Weg zu den Zuschauern, im Folgenden Konsumenten genannt, passiert der Datenstrom zwei Router | ||
* Da es sich um eine Live-Übertragung handelt, erhalten alle Konsumenten zu jedem Zeitpunkt die gleichen Daten | * Da es sich um eine Live-Übertragung handelt, erhalten alle Konsumenten zu jedem Zeitpunkt die gleichen Daten | ||
* Wird kein Multicast verwendet, dann wird nach dem in Abbildung 4.12 dargestellten Prinzip verfahren | * Wird kein Multicast verwendet, dann wird nach dem in Abbildung 4.12 dargestellten Prinzip verfahren | ||
Jeder Konsument kontaktiert die Quelle des Datenstroms und erhält von ihr die Daten, obwohl weitgehend identisch, individuell zugestellt | Jeder Konsument kontaktiert die Quelle des Datenstroms und erhält von ihr die Daten, obwohl weitgehend identisch, individuell zugestellt | ||
* Alle beteiligten Links und Router auf dem Pfad werden mehrfach belastet | * Alle beteiligten Links und Router auf dem Pfad werden mehrfach belastet | ||
* Mit jedem neuen Konsumenten erhöht sich das Datenaufkommen | * Mit jedem neuen Konsumenten erhöht sich das Datenaufkommen | ||
=== Multicast Datenströme === | === Multicast Datenströme === | ||
; Nehmen wir an, die Sportveranstaltung aus unserem Beispiel gewinnt an Popularität | ; Nehmen wir an, die Sportveranstaltung aus unserem Beispiel gewinnt an Popularität | ||
* Plötzlich sind wir mit einer hohen Nachfrage konfrontiert | * Plötzlich sind wir mit einer hohen Nachfrage konfrontiert | ||
* Das bisherige Vorgehen ist nicht in der Lage, diese Nachfrage zu befriedigen, da die Kapazitätsgrenzen der Links und Router erreicht werden würden | * Das bisherige Vorgehen ist nicht in der Lage, diese Nachfrage zu befriedigen, da die Kapazitätsgrenzen der Links und Router erreicht werden würden | ||
; Lösung Multicast | ; Lösung Multicast | ||
[[File:ipv6DatenstromsMitMulticast.png|mini|400px|Datenstrom mit Multicast]] | [[File:ipv6DatenstromsMitMulticast.png|mini|400px|Datenstrom mit Multicast]] | ||
* Die Abbildung zeigt das Verfahren, die beteiligten Systeme bleiben die gleichen wie vorher | * Die Abbildung zeigt das Verfahren, die beteiligten Systeme bleiben die gleichen wie vorher | ||
Der wesentliche Unterschied ist, dass nun nicht mehr die Quelle für die Duplizierung des Datenstroms zuständig ist, sondern diese Aufgabe den Routern zuteilwird | Der wesentliche Unterschied ist, dass nun nicht mehr die Quelle für die Duplizierung des Datenstroms zuständig ist, sondern diese Aufgabe den Routern zuteilwird | ||
* Der Datenstrom wird genau einmal von der Multicast-Quelle zu Router B übertragen, dieser wiederum sendet die Pakete genau einmal an Router A weiter | * Der Datenstrom wird genau einmal von der Multicast-Quelle zu Router B übertragen, dieser wiederum sendet die Pakete genau einmal an Router A weiter | ||
* Von Router A schließlich wird der Datenstrom an die Konsumenten verteilt | * Von Router A schließlich wird der Datenstrom an die Konsumenten verteilt | ||
* Je besser die Hardware am Link (zum Beispiel ein Switch) mit Multicast umgehen kann, desto später findet die technische Duplizierung des Datenstroms statt | * Je besser die Hardware am Link (zum Beispiel ein Switch) mit Multicast umgehen kann, desto später findet die technische Duplizierung des Datenstroms statt | ||
* Idealerweise wird bei Nutzung von Ethernet erst am letzten Switchport eine Kopie der betroffenen Frames angefertigt | * Idealerweise wird bei Nutzung von Ethernet erst am letzten Switchport eine Kopie der betroffenen Frames angefertigt | ||
| Zeile 49: | Zeile 49: | ||
[[File:ipv6MulticastAddress.png|mini|400px|Multicast Address]] | [[File:ipv6MulticastAddress.png|mini|400px|Multicast Address]] | ||
; Präfix <nowiki>ff::/8</nowiki> | ; Präfix <nowiki>ff::/8</nowiki> | ||
* Sie beginnen also stets mit ff, daran können wir sie schnell erkennen | * Sie beginnen also stets mit ff, daran können wir sie schnell erkennen | ||
* Danach folgen 4 Bits für Flags und weitere 4 Bits für die Angabe des Multicast Scopes | * Danach folgen 4 Bits für Flags und weitere 4 Bits für die Angabe des Multicast Scopes | ||
* Der grundlegende Aufbau einer Multicast Address ist in Abbildung 4.14 dargestellt | * Der grundlegende Aufbau einer Multicast Address ist in Abbildung 4.14 dargestellt | ||
; Die Flags (in Leserichtung) haben folgende Bedeutung | ; Die Flags (in Leserichtung) haben folgende Bedeutung | ||
| Zeile 58: | Zeile 58: | ||
! Flags !! Beschreibung | ! Flags !! Beschreibung | ||
|- | |- | ||
| Reserviert || Das erste Flag ist reserviert für spätere Erweiterungen. Es wird auf Null gesetzt | | Reserviert || Das erste Flag ist reserviert für spätere Erweiterungen. Es wird auf Null gesetzt | ||
|- | |- | ||
| Rendezvous Point || Das Rendezvous Point Flag wird gesetzt wenn im Group Identifier die Adresse eines Rendezvous Points eingebettet ist | | Rendezvous Point || Das Rendezvous Point Flag wird gesetzt wenn im Group Identifier die Adresse eines Rendezvous Points eingebettet ist | ||
* Das Verfahren wird für Inter Domain Multicast verwendet, ein Thema das außerhalb des Workshops liegt. Interessierte finden mehr dazu im RFC 3956 | * Das Verfahren wird für Inter Domain Multicast verwendet, ein Thema das außerhalb des Workshops liegt. Interessierte finden mehr dazu im RFC 3956 | ||
|- | |- | ||
| Prefix || Mit dem Prefix Flag wird angezeigt, dass im Group Identifier ein Präfix und die zugehörige Präfixlänge eingebettet wurden | | Prefix || Mit dem Prefix Flag wird angezeigt, dass im Group Identifier ein Präfix und die zugehörige Präfixlänge eingebettet wurden | ||
* Nodes können das Präfix extrahieren und so erfahren, in welchem Netz die Multicast-Quelle beheimatet ist | * Nodes können das Präfix extrahieren und so erfahren, in welchem Netz die Multicast-Quelle beheimatet ist | ||
* Weitere Informationen zur Verwendung des Flags hält RFC 3306 [HT02] bereit | * Weitere Informationen zur Verwendung des Flags hält RFC 3306 [HT02] bereit | ||
|- | |- | ||
| Transient ||Ein gesetztes Transient Flag bedeutet, dass es sich nicht um eine Well-known Multicast Address handelt | | Transient ||Ein gesetztes Transient Flag bedeutet, dass es sich nicht um eine Well-known Multicast Address handelt | ||
Letztere werden von der IANA öffentlich verwaltet.4 Tabelle 4.5 enthält eine Auswahl üblicher Well-known Multicast Addresses | Letztere werden von der IANA öffentlich verwaltet.4 Tabelle 4.5 enthält eine Auswahl üblicher Well-known Multicast Addresses | ||
|} | |} | ||
| Zeile 79: | Zeile 79: | ||
; Multicast Addresses identifizieren eine Multicast Group innerhalb ihres Scopes eindeutig | ; Multicast Addresses identifizieren eine Multicast Group innerhalb ihres Scopes eindeutig | ||
* Für die Organisation dieser Gruppen ist das Protokoll Multicast Listener Discovery v2 (MLDv2) zuständig | * Für die Organisation dieser Gruppen ist das Protokoll Multicast Listener Discovery v2 (MLDv2) zuständig | ||
* Es ist in RFC 3810 [VC04] und RFC 4604 [HCH06] standardisiert und definiert verschiedene Nachrichten, welche über ICMPv6 transportiert werden | * Es ist in RFC 3810 [VC04] und RFC 4604 [HCH06] standardisiert und definiert verschiedene Nachrichten, welche über ICMPv6 transportiert werden | ||
Die heute gebräuchlichsten Nachrichten sind die | Die heute gebräuchlichsten Nachrichten sind die | ||
* Multicast Listener Query Message und die | * Multicast Listener Query Message und die | ||
* Multicast Listener Report Message | * Multicast Listener Report Message | ||
# http://www.iana.org/assignments/multicast-addresses | # http://www.iana.org/assignments/multicast-addresses | ||
| Zeile 92: | Zeile 92: | ||
|- | |- | ||
! Scope: Node Adresse, Präfix !! Nutzung | ! Scope: Node Adresse, Präfix !! Nutzung | ||
|- | |- | ||
| ff 1::1 || Alle Nodes | | ff 1::1 || Alle Nodes | ||
|- | |- | ||
| Zeile 163: | Zeile 163: | ||
| 0x2 || Link-local || Nur auf dem Link gültig. Die Pakete dürfen nicht geroutet werden | | 0x2 || Link-local || Nur auf dem Link gültig. Die Pakete dürfen nicht geroutet werden | ||
|- | |- | ||
| 0x3 || Reserviert || | | 0x3 || Reserviert || | ||
|- | |- | ||
| 0x4 || Admin-Local || Vom Administrator festzulegender Teil des Netzes. Wird auch für eigenständig administrierte Abteilungen verwendet | | 0x4 || Admin-Local || Vom Administrator festzulegender Teil des Netzes. Wird auch für eigenständig administrierte Abteilungen verwendet | ||
| Zeile 181: | Zeile 181: | ||
Beschreibung Das Multicast-Äquivalent zur Loopback Address ::1 | Beschreibung Das Multicast-Äquivalent zur Loopback Address ::1 | ||
Nur auf dem lokalen Node gültig | Nur auf dem lokalen Node gültig | ||
Nur auf dem Link gültig | Nur auf dem Link gültig | ||
Die Pakete dürfen nicht geroutet werden | Die Pakete dürfen nicht geroutet werden | ||
Vom Administrator festzulegender Teil des Netzes | Vom Administrator festzulegender Teil des Netzes | ||
Wird auch für eigenständig administrierte Abteilungen verwendet | Wird auch für eigenständig administrierte Abteilungen verwendet | ||
Lokales, physikalisches Netzwerk | Lokales, physikalisches Netzwerk | ||
* In der Regel eine Filiale oder eine Betriebsstätte | * In der Regel eine Filiale oder eine Betriebsstätte | ||
Zur freien Definition eigener Gültigkeitsbereiche | Zur freien Definition eigener Gültigkeitsbereiche | ||
Ein die gesamte Organisation umfassender Gültigkeitsbereich | Ein die gesamte Organisation umfassender Gültigkeitsbereich | ||
Umfasst auch geographisch entfernte Betriebsstätten, die über Standleitung oder Virtual Private Network | Umfasst auch geographisch entfernte Betriebsstätten, die über Standleitung oder Virtual Private Network | ||
(VPN) angebunden sind | (VPN) angebunden sind | ||
Zur freien Definition eigener Gültigkeitsbereiche | Zur freien Definition eigener Gültigkeitsbereiche | ||
Das gesamte Internet | Das gesamte Internet | ||
4.5 Multicast Darüber hinaus müssen Nodes aus Kompatibilitätsgründen auch die älteren MLDv1-Nachrichten | 4.5 Multicast Darüber hinaus müssen Nodes aus Kompatibilitätsgründen auch die älteren MLDv1-Nachrichten | ||
* Version 1 Multicast Listener Report und | * Version 1 Multicast Listener Report und | ||
* Version 1 Multicast Listener Done aus RFC 2710 [DFH99] unterstützen | * Version 1 Multicast Listener Done aus RFC 2710 [DFH99] unterstützen | ||
Mit der Listener Query Message kann festgestellt werden, ob eine Gruppe noch Mitglieder hat | Mit der Listener Query Message kann festgestellt werden, ob eine Gruppe noch Mitglieder hat | ||
* Damit kann auch ein nicht ordnungsgemäßes Verlassen einer Gruppe bemerkt werden | * Damit kann auch ein nicht ordnungsgemäßes Verlassen einer Gruppe bemerkt werden | ||
=== Listener Query Message === | === Listener Query Message === | ||
Die Listener Report Messages dienen dazu, Multicast Groups beizutreten oder sie zu verlassen | Die Listener Report Messages dienen dazu, Multicast Groups beizutreten oder sie zu verlassen | ||
* Jedes Interface, das Mitglied einer bestimmten Gruppe ist, nimmt für diese Gruppe die Rolle eines Multicast Listeners ein | * Jedes Interface, das Mitglied einer bestimmten Gruppe ist, nimmt für diese Gruppe die Rolle eines Multicast Listeners ein | ||
* Pakete die an die Gruppenadresse gesendet wurden, werden allen Mitgliedern zugestellt | * Pakete die an die Gruppenadresse gesendet wurden, werden allen Mitgliedern zugestellt | ||
* Möchte ein Interface für eine Gruppe keine Pakete mehr erhalten, so verlässt es die Gruppe wieder | * Möchte ein Interface für eine Gruppe keine Pakete mehr erhalten, so verlässt es die Gruppe wieder | ||
=== Listener Report Message === | === Listener Report Message === | ||
Den Beitritt zu einer Gruppe werden wir uns in Wireshark anschauen | Den Beitritt zu einer Gruppe werden wir uns in Wireshark anschauen | ||
* Dazu fahren wir das Interface eth0 auf lynx zuerst herunter: | * Dazu fahren wir das Interface eth0 auf lynx zuerst herunter: | ||
| Zeile 216: | Zeile 216: | ||
root@linux:~# '''ip link set down dev eth''' | root@linux:~# '''ip link set down dev eth''' | ||
Jetzt starten wir Wireshark und lassen ihn auf dem PseudoInterface lauschen | Jetzt starten wir Wireshark und lassen ihn auf dem PseudoInterface lauschen | ||
* Das Pseudo-Interface liefert die Daten von allen Interfaces, auch von denen, die erst nach dem Start des Mitschnitts hochgefahren werden | * Das Pseudo-Interface liefert die Daten von allen Interfaces, auch von denen, die erst nach dem Start des Mitschnitts hochgefahren werden | ||
* Wir haben also die Chance, den Start eines Interfaces zu beobachten | * Wir haben also die Chance, den Start eines Interfaces zu beobachten | ||
* In diesem Zeitraum treten nämlich vermehrt MLDv2 Messages auf | * In diesem Zeitraum treten nämlich vermehrt MLDv2 Messages auf | ||
: Dazu fahren wir das Interface wieder hoch | : Dazu fahren wir das Interface wieder hoch | ||
root@linux:~# ''ip link set up dev eth'' | root@linux:~# ''ip link set up dev eth'' | ||
Von den zahlreichen Paketen die von Wireshark mitgeschnitten wurden suchen wir uns eines vom Typ MLDv2 aus | Von den zahlreichen Paketen die von Wireshark mitgeschnitten wurden suchen wir uns eines vom Typ MLDv2 aus | ||
=== Multicast Listener Discovery === | === Multicast Listener Discovery === | ||
Wir sehen einen Multicast Listener Report, eingebettet in ICMPv6 als Typ 143 | Wir sehen einen Multicast Listener Report, eingebettet in ICMPv6 als Typ 143 | ||
* Neben den bekannten Code-, Checksumund Reserved-Feldern ist auch ein Feld namens Number of Multicast Address Records vorhanden | * Neben den bekannten Code-, Checksumund Reserved-Feldern ist auch ein Feld namens Number of Multicast Address Records vorhanden | ||
* Es gibt an, wie viele Multicast Address Record Changes folgen | * Es gibt an, wie viele Multicast Address Record Changes folgen | ||
* In unserem Beispiel folgt nur ein Eintrag, es wäre auch möglich mehrere Einträge auf einmal bekanntzugeben | * In unserem Beispiel folgt nur ein Eintrag, es wäre auch möglich mehrere Einträge auf einmal bekanntzugeben | ||
* Jeder Eintrag steht für Änderungen der Zugehörigkeit zu Multicast Groups eines Interfaces | * Jeder Eintrag steht für Änderungen der Zugehörigkeit zu Multicast Groups eines Interfaces | ||
=== Include und Exclude === | === Include und Exclude === | ||
Die Interpretation der Einträge ist nicht ganz trivial | Die Interpretation der Einträge ist nicht ganz trivial | ||
* Es gibt zwei Arten von Multicast Listener Report Messages | * Es gibt zwei Arten von Multicast Listener Report Messages | ||
* Diese heißen Include und Exclude | * Diese heißen Include und Exclude | ||
* Ein Include steht allerdings nicht, wie der Wortlaut vielleicht vermuten lässt, für einen Gruppenbeitritt eines Interfaces | * Ein Include steht allerdings nicht, wie der Wortlaut vielleicht vermuten lässt, für einen Gruppenbeitritt eines Interfaces | ||
* Und ein Exclude muss nicht unbedingt einen Gruppenaustritt bedeuten | * Und ein Exclude muss nicht unbedingt einen Gruppenaustritt bedeuten | ||
* Include und Exclude beziehen sich nämlich nicht auf die Multicast Group, sondern auf eine Liste von Quellen, von denen ein Interface Pakete an die Gruppe akzeptiert (Include) oder auch nicht akzeptiert (Exclude) | * Include und Exclude beziehen sich nämlich nicht auf die Multicast Group, sondern auf eine Liste von Quellen, von denen ein Interface Pakete an die Gruppe akzeptiert (Include) oder auch nicht akzeptiert (Exclude) | ||
* Nun kann ein Interface auch eine leere Liste mitschicken, und damit anzeigen, dass sich das Include oder Exclude auf keine Adressen bezieht | * Nun kann ein Interface auch eine leere Liste mitschicken, und damit anzeigen, dass sich das Include oder Exclude auf keine Adressen bezieht | ||
* Dann käme ein Include einem Gruppaustritt gleich, und ein Exclude mit leerer Liste entspräche einem Gruppenbeitritt | * Dann käme ein Include einem Gruppaustritt gleich, und ein Exclude mit leerer Liste entspräche einem Gruppenbeitritt | ||
* Multicast Listener Report Messages erwecken manchmal den Eindruck einer doppelten Verneinung | * Multicast Listener Report Messages erwecken manchmal den Eindruck einer doppelten Verneinung | ||
Beispiel: | Beispiel: | ||
Gruppenbeitritt | Gruppenbeitritt | ||
Dazu als Beispiel unsere MLDv2 Message: Wir klappen den Eintrag Multicast Address Record Changed to exclude auf und sehen uns die enthaltenen Informationen an | Dazu als Beispiel unsere MLDv2 Message: Wir klappen den Eintrag Multicast Address Record Changed to exclude auf und sehen uns die enthaltenen Informationen an | ||
* Wir sehen die | * Wir sehen die | ||
| Zeile 254: | Zeile 254: | ||
=== IPv6-Header eines MLDv2Paketes === | === IPv6-Header eines MLDv2Paketes === | ||
Art der Änderung, Exclude, und weitere Felder | Art der Änderung, Exclude, und weitere Felder | ||
* Das Feld Aux Data Length gibt an wie viele 8-Byte-Blöcke mit zusätzlichen Daten der Multicast Address folgen | * Das Feld Aux Data Length gibt an wie viele 8-Byte-Blöcke mit zusätzlichen Daten der Multicast Address folgen | ||
* Da es hier den Wert 0 | * Da es hier den Wert 0 | ||
hat, sind keine weiteren Daten zu erwarten | hat, sind keine weiteren Daten zu erwarten | ||
* Es folgt die Anzahl der einschränkenden Quellen, hier 0, und im Anschluss die betroffene Multicast Address | * Es folgt die Anzahl der einschränkenden Quellen, hier 0, und im Anschluss die betroffene Multicast Address | ||
Nach Auswertung aller Felder kommen wir zum dem Schluss: | Nach Auswertung aller Felder kommen wir zum dem Schluss: | ||
Es handelt sich in unserem Beispiel um eine Änderung der Art Exclude ohne Einschränkung der Quellen | Es handelt sich in unserem Beispiel um eine Änderung der Art Exclude ohne Einschränkung der Quellen | ||
* Für diese Multicast Group akzeptiert das Interface Pakete von allen Quellen, außer denen in der Liste | * Für diese Multicast Group akzeptiert das Interface Pakete von allen Quellen, außer denen in der Liste | ||
* Da die Liste leer ist, gibt es keine Quellen die vom Interface keine Pakete akzeptieren würde | * Da die Liste leer ist, gibt es keine Quellen die vom Interface keine Pakete akzeptieren würde | ||
Es handelt sich also um einen uneingeschränkten Gruppenbeitritt | Es handelt sich also um einen uneingeschränkten Gruppenbeitritt | ||
Abschließend schauen wir uns noch das Feld Hop Limit des vorangestellten IPv6-Headers an (siehe Abbildung 4.16) | Abschließend schauen wir uns noch das Feld Hop Limit des vorangestellten IPv6-Headers an (siehe Abbildung 4.16) | ||
* Es hat den Wert 1, was bedeutet, dass MLDv2-Pakete einen Router nicht passieren können | * Es hat den Wert 1, was bedeutet, dass MLDv2-Pakete einen Router nicht passieren können | ||
* Die ganze Organisation von Multicast Groups findet also auf dem lokalen Link statt | * Die ganze Organisation von Multicast Groups findet also auf dem lokalen Link statt | ||
=== Hop Limit === | === Hop Limit === | ||
Trotzdem möchte ein Interface vielleicht den Datenstrom einer Multicast-Quelle empfangen, die an einem anderen Link angeschlossen ist | Trotzdem möchte ein Interface vielleicht den Datenstrom einer Multicast-Quelle empfangen, die an einem anderen Link angeschlossen ist | ||
* Wenn die Pakete den Router nicht passieren können, muss der Router anderweitig tätig werden, um den angeforderten Datenstrom bereitzustellen | * Wenn die Pakete den Router nicht passieren können, muss der Router anderweitig tätig werden, um den angeforderten Datenstrom bereitzustellen | ||
* Dazu muss er | * Dazu muss er | ||
| Zeile 290: | Zeile 290: | ||
Versand von Multicast-Daten | Versand von Multicast-Daten | ||
Multicast-fähig sein | Multicast-fähig sein | ||
* Er wird dann auch Multicast Router genannt | * Er wird dann auch Multicast Router genannt | ||
* Tatsächlich, wenn wir den Header weiter analysieren, entdecken wir einen Hop-by-Hop Extension Header mit Router Alert Option | * Tatsächlich, wenn wir den Header weiter analysieren, entdecken wir einen Hop-by-Hop Extension Header mit Router Alert Option | ||
* Der Router wird explizit darauf hingewiesen, dass dieses Paket für ihn wichtige Informationen enthalten könnte | * Der Router wird explizit darauf hingewiesen, dass dieses Paket für ihn wichtige Informationen enthalten könnte | ||
Um den Datenstrom auf dem anfragenden Link bereitzustellen, muss der Router seinerseits den Datenstrom anfordern | Um den Datenstrom auf dem anfragenden Link bereitzustellen, muss der Router seinerseits den Datenstrom anfordern | ||
Entweder hat er ein Interface an einem Link an dem auch die Multicast-Quelle angeschlossen ist, dann tritt er einfach der entsprechenden Gruppe bei | Entweder hat er ein Interface an einem Link an dem auch die Multicast-Quelle angeschlossen ist, dann tritt er einfach der entsprechenden Gruppe bei | ||
* So erhält er die zugehörigen Pakete die er dann zum anfragenden Link routen kann | * So erhält er die zugehörigen Pakete die er dann zum anfragenden Link routen kann | ||
* Hat der Router kein Interface am Link der Multicast-Quelle, beauftragt er einen der ihm bekannten Multicast Router, die Daten bereitzustellen | * Hat der Router kein Interface am Link der Multicast-Quelle, beauftragt er einen der ihm bekannten Multicast Router, die Daten bereitzustellen | ||
* Dazu tritt er wieder der Multicast Group bei und nimmt für diese Gruppe am betroffenen Interface die Rolle eines Multicast Listeners ein | * Dazu tritt er wieder der Multicast Group bei und nimmt für diese Gruppe am betroffenen Interface die Rolle eines Multicast Listeners ein | ||
* Das Prinzip ist beispielhaft in Abbildung 4.17 dargestellt, hier ist die Quelle zwei Hops vom Konsumenten entfernt | * Das Prinzip ist beispielhaft in Abbildung 4.17 dargestellt, hier ist die Quelle zwei Hops vom Konsumenten entfernt | ||
== 4.6 | Multicast auf dem Link-layer All Nodes Multicast Address == | == 4.6 | Multicast auf dem Link-layer All Nodes Multicast Address == | ||
: All Nodes Multicast Address | : All Nodes Multicast Address | ||
Wo bei IPv4 häufig Broadcast zum Einsatz kam, wird unter IPv6 Multicast verwendet | Wo bei IPv4 häufig Broadcast zum Einsatz kam, wird unter IPv6 Multicast verwendet | ||
* Immer dann, wenn nicht alle Nodes am Link angesprochen werden sollen, ist die Verwendung von | * Immer dann, wenn nicht alle Nodes am Link angesprochen werden sollen, ist die Verwendung von | ||
4.6 Multicast auf dem Link-layer Multicast ressourcenschonender | 4.6 Multicast auf dem Link-layer Multicast ressourcenschonender | ||
* Idealerweise werden nur jene Nodes behelligt, die auch Interesse an den versendeten Daten haben | * Idealerweise werden nur jene Nodes behelligt, die auch Interesse an den versendeten Daten haben | ||
* Sollen doch einmal alle Nodes eines Links angesprochen werden, kann die All Nodes Multicast Address mit Link-local Scope genutzt werden | * Sollen doch einmal alle Nodes eines Links angesprochen werden, kann die All Nodes Multicast Address mit Link-local Scope genutzt werden | ||
* Sie repräsentiert eine Multicast Group der alle Nodes am Link beitreten müssen | * Sie repräsentiert eine Multicast Group der alle Nodes am Link beitreten müssen | ||
Um die Belastung auf dem Link gering zu halten, sollten Pakete für eine Multicast Group zwar an alle beigetretenen Interfaces zugestellt werden, unbeteiligte Interfaces aber außen vor gelassen werden | Um die Belastung auf dem Link gering zu halten, sollten Pakete für eine Multicast Group zwar an alle beigetretenen Interfaces zugestellt werden, unbeteiligte Interfaces aber außen vor gelassen werden | ||
* Da sich 128 Bits lange Multicast Addresses nicht ohne Verlust auf gängige Link-layer Addresses abbilden lassen, muss man hier Einschränkungen hinnehmen | * Da sich 128 Bits lange Multicast Addresses nicht ohne Verlust auf gängige Link-layer Addresses abbilden lassen, muss man hier Einschränkungen hinnehmen | ||
* Je nach verwendeter Link-Technologie und Intelligenz der beteiligten Link-layer-Geräte (Beispielsweise Switches), ist der Overhead kleiner oder größer | * Je nach verwendeter Link-Technologie und Intelligenz der beteiligten Link-layer-Geräte (Beispielsweise Switches), ist der Overhead kleiner oder größer | ||
* Im ungünstigsten Fall sinkt die Effizienz auf das Niveau von Broadcast | * Im ungünstigsten Fall sinkt die Effizienz auf das Niveau von Broadcast | ||
=== Effizienzsteigerung durch Multicast === | === Effizienzsteigerung durch Multicast === | ||
Die Umsetzung von Multicast Addresses auf Link-layer Addresses an Ethernet-Links werden wir wegen seiner praktischen Relevanz genauer untersuchen | Die Umsetzung von Multicast Addresses auf Link-layer Addresses an Ethernet-Links werden wir wegen seiner praktischen Relevanz genauer untersuchen | ||
* Das Verfahren ist auch in RFC 2464 [Cra98] beschrieben | * Das Verfahren ist auch in RFC 2464 [Cra98] beschrieben | ||
=== Multicast auf Ethernet === | === Multicast auf Ethernet === | ||
Zunächst fangen wir mit Wireshark wieder eine Neighbor Solicitation auf | Zunächst fangen wir mit Wireshark wieder eine Neighbor Solicitation auf | ||
* Den Vorgang starten wir aber erst, wenn der Neighbor Cache von fuzzball keinen Eintrag mehr für lynx aufweist | * Den Vorgang starten wir aber erst, wenn der Neighbor Cache von fuzzball keinen Eintrag mehr für lynx aufweist | ||
* Dann senden einen Echo Request von fuzzball an lynx, um eine Neighbor Solicitation zu erzwingen: | * Dann senden einen Echo Request von fuzzball an lynx, um eine Neighbor Solicitation zu erzwingen: | ||
| Zeile 350: | Zeile 350: | ||
Multicast Link-Layer Address (MAC) | Multicast Link-Layer Address (MAC) | ||
In Wireshark schauen wir uns den Ethernet-Header und den IPv6-Header der Neighbor Solicitation an | In Wireshark schauen wir uns den Ethernet-Header und den IPv6-Header der Neighbor Solicitation an | ||
* Das Feld Destination im Ethernet-Header hat den Wert 33:33:ff:6 : d:1e | * Das Feld Destination im Ethernet-Header hat den Wert 33:33:ff:6 : d:1e | ||
* Vergleichen wir den Wert mit der Zieladresse ff 2::1:ff6 :d1e im IPv6-Header, fallen Gemeinsamkeiten auf | * Vergleichen wir den Wert mit der Zieladresse ff 2::1:ff6 :d1e im IPv6-Header, fallen Gemeinsamkeiten auf | ||
* Offensichtlich wird die Link-layer Multicast Address aus der IPv6 Multicast Address abgeleitet | * Offensichtlich wird die Link-layer Multicast Address aus der IPv6 Multicast Address abgeleitet | ||
* Abbildung 4.19 verdeutlicht das Verfahren | * Abbildung 4.19 verdeutlicht das Verfahren | ||
In diesem Fall sind die letzten drei Bytes der Link-layer Multicast Address identisch mit denen der Link-layer Address des Interfaces | In diesem Fall sind die letzten drei Bytes der Link-layer Multicast Address identisch mit denen der Link-layer Address des Interfaces | ||
* Zur Erinnerung: Die Link-layer Address hatte uns der Node in einem Neighbor Advertisement mitgeteilt (siehe Abbildung 4.8 in Abschnitt 4.3 Neighbor Cache) | * Zur Erinnerung: Die Link-layer Address hatte uns der Node in einem Neighbor Advertisement mitgeteilt (siehe Abbildung 4.8 in Abschnitt 4.3 Neighbor Cache) | ||
* Ein Switch müsste in diesem Fall den Frame einfach auf allen Ports aussenden, deren zugeordnete Link-layer Addresses auf die letzten drei Bytes der Link-layer Multicast Address enden | * Ein Switch müsste in diesem Fall den Frame einfach auf allen Ports aussenden, deren zugeordnete Link-layer Addresses auf die letzten drei Bytes der Link-layer Multicast Address enden | ||
* Viele werden das nicht sein | * Viele werden das nicht sein | ||
* Ein so simples wie effizientes Verfahren | * Ein so simples wie effizientes Verfahren | ||
Multicast und Privacy Extensions | Multicast und Privacy Extensions | ||
Problematischer wird es, wenn die Clients Privacy Extensions nutzen | Problematischer wird es, wenn die Clients Privacy Extensions nutzen | ||
* Dann weisen die Interface Identifier keine Gemeinsamkeiten mit der Link-layer Address mehr auf | * Dann weisen die Interface Identifier keine Gemeinsamkeiten mit der Link-layer Address mehr auf | ||
* Trotzdem bilden die Interface Identifier die Grundlage für entsprechen- | * Trotzdem bilden die Interface Identifier die Grundlage für entsprechen- | ||
4.6 Multicast auf dem Link-layer de Solicited Node Multicast Addresses | 4.6 Multicast auf dem Link-layer de Solicited Node Multicast Addresses | ||
* Aus diesen wiederum wird die Link-layer Multicast Address abgeleitet | * Aus diesen wiederum wird die Link-layer Multicast Address abgeleitet | ||
* Einem Switch, und sei er auch noch so schlau konfiguriert, bieten sich nun keine Anhaltspunkte mehr, auf welchen Ports der Frame erwünscht sein könnte | * Einem Switch, und sei er auch noch so schlau konfiguriert, bieten sich nun keine Anhaltspunkte mehr, auf welchen Ports der Frame erwünscht sein könnte | ||
* Ihm bleibt nur eine Möglichkeit übrig: | * Ihm bleibt nur eine Möglichkeit übrig: | ||
Er sendet den Frame auf allen Ports hinaus | Er sendet den Frame auf allen Ports hinaus | ||
* Um diesem Effizienzverlust zu begegnen sind die Switch-Hersteller angehalten, MLDv2-Pakete auszuwerten | * Um diesem Effizienzverlust zu begegnen sind die Switch-Hersteller angehalten, MLDv2-Pakete auszuwerten | ||
* Indem sich die Switche merken, an welchem Port Nodes zu einer Multicast Group beigetreten sind, können sie den Overhead signifikant senken | * Indem sich die Switche merken, an welchem Port Nodes zu einer Multicast Group beigetreten sind, können sie den Overhead signifikant senken | ||
Dass sich dies spürbar auf die Herstellungskosten, und damit auch auf den Verkaufspreis auswirkt, dürfte auf der Hand liegen | Dass sich dies spürbar auf die Herstellungskosten, und damit auch auf den Verkaufspreis auswirkt, dürfte auf der Hand liegen | ||
Einen Sonderfall gibt es allerdings, beschrieben in RFC 6085 | Einen Sonderfall gibt es allerdings, beschrieben in RFC 6085 | ||
[GTTD11]: Wenn der Absender weiß, dass nur ein einziges Interface in einer Multicast Group Mitglied ist, und ihm darüber hinaus die Link-layer Unicast Address des Interfaces bekannt ist, dann darf er direkt an diese adressieren | [GTTD11]: Wenn der Absender weiß, dass nur ein einziges Interface in einer Multicast Group Mitglied ist, und ihm darüber hinaus die Link-layer Unicast Address des Interfaces bekannt ist, dann darf er direkt an diese adressieren | ||
* Einem Switch wird so unter Umständen das mehrfache Aussenden eines Frames erspart | * Einem Switch wird so unter Umständen das mehrfache Aussenden eines Frames erspart | ||
Sonderfall | Sonderfall | ||
Version vom 16. Januar 2024, 15:18 Uhr
topic - Kurzbeschreibung
Beschreibung
Anwendungsgebiete von Multicast
- Einsatz von Multicast
- Vermeidung von mehrfacher Übertragung identischer Datenströme
- Effizienten Organisation der Nodes an einem Link
- Wie werden Pakete an Ziele verschicken, deren Link-Layer-Adresse unbekannt ist?
- Die Lösung heißt Multicast
- Multicast Addresses
- Können mehrere Interfaces anzusprechen
Besonders nützlich ist das, wenn sich die angesprochenen Interfaces in verschiedenen Nodes befinden
- So können wir indirekt Gruppen von Nodes ansprechen
- Alle Interfaces, die innerhalb eines Gültigkeitsbereiches dieselbe Multicast Address nutzen, bilden deshalb eine Multicast Group
Szenario
- Um die Nutzung von Multicast bei Datenströmen zu verstehen, denken wir uns folgende Situation
Mehrere Zuschauer möchten die Live-Übertragung einer Sportveranstaltung als Videostream auf ihren IPv6-fähigen Endgeräten verfolgen
- Das können Computer, Smartphones oder netzwerkfähige Fernseher sein
- Das Videomaterial wird in Form eines Datenstroms von einem Server bereitgestellt, den wir Multicast-Quelle nennen
- Auf dem Weg zu den Zuschauern, im Folgenden Konsumenten genannt, passiert der Datenstrom zwei Router
- Da es sich um eine Live-Übertragung handelt, erhalten alle Konsumenten zu jedem Zeitpunkt die gleichen Daten
- Wird kein Multicast verwendet, dann wird nach dem in Abbildung 4.12 dargestellten Prinzip verfahren
Jeder Konsument kontaktiert die Quelle des Datenstroms und erhält von ihr die Daten, obwohl weitgehend identisch, individuell zugestellt
- Alle beteiligten Links und Router auf dem Pfad werden mehrfach belastet
- Mit jedem neuen Konsumenten erhöht sich das Datenaufkommen
Multicast Datenströme
- Nehmen wir an, die Sportveranstaltung aus unserem Beispiel gewinnt an Popularität
- Plötzlich sind wir mit einer hohen Nachfrage konfrontiert
- Das bisherige Vorgehen ist nicht in der Lage, diese Nachfrage zu befriedigen, da die Kapazitätsgrenzen der Links und Router erreicht werden würden
- Lösung Multicast
- Die Abbildung zeigt das Verfahren, die beteiligten Systeme bleiben die gleichen wie vorher
Der wesentliche Unterschied ist, dass nun nicht mehr die Quelle für die Duplizierung des Datenstroms zuständig ist, sondern diese Aufgabe den Routern zuteilwird
- Der Datenstrom wird genau einmal von der Multicast-Quelle zu Router B übertragen, dieser wiederum sendet die Pakete genau einmal an Router A weiter
- Von Router A schließlich wird der Datenstrom an die Konsumenten verteilt
- Je besser die Hardware am Link (zum Beispiel ein Switch) mit Multicast umgehen kann, desto später findet die technische Duplizierung des Datenstroms statt
- Idealerweise wird bei Nutzung von Ethernet erst am letzten Switchport eine Kopie der betroffenen Frames angefertigt
Multicast Addressen
- Präfix ff::/8
- Sie beginnen also stets mit ff, daran können wir sie schnell erkennen
- Danach folgen 4 Bits für Flags und weitere 4 Bits für die Angabe des Multicast Scopes
- Der grundlegende Aufbau einer Multicast Address ist in Abbildung 4.14 dargestellt
- Die Flags (in Leserichtung) haben folgende Bedeutung
| Flags | Beschreibung |
|---|---|
| Reserviert | Das erste Flag ist reserviert für spätere Erweiterungen. Es wird auf Null gesetzt |
| Rendezvous Point | Das Rendezvous Point Flag wird gesetzt wenn im Group Identifier die Adresse eines Rendezvous Points eingebettet ist
|
| Prefix | Mit dem Prefix Flag wird angezeigt, dass im Group Identifier ein Präfix und die zugehörige Präfixlänge eingebettet wurden
|
| Transient | Ein gesetztes Transient Flag bedeutet, dass es sich nicht um eine Well-known Multicast Address handelt
Letztere werden von der IANA öffentlich verwaltet.4 Tabelle 4.5 enthält eine Auswahl üblicher Well-known Multicast Addresses |
Multicast Scopes
- Während einige Multicast Scopes fest definierte Grenzen haben, lassen sich andere individuell festlegen
- Die Einhaltung der Grenzen kann dann nur gewährleistet werden, wenn die unternehmenseigenen Router entsprechend konfiguriert wurden
- Mehr Informationen zu den Multicast Scopes können der Tabelle entnommen werden
Organisation von Multicast Groups
- Multicast Addresses identifizieren eine Multicast Group innerhalb ihres Scopes eindeutig
- Für die Organisation dieser Gruppen ist das Protokoll Multicast Listener Discovery v2 (MLDv2) zuständig
- Es ist in RFC 3810 [VC04] und RFC 4604 [HCH06] standardisiert und definiert verschiedene Nachrichten, welche über ICMPv6 transportiert werden
Die heute gebräuchlichsten Nachrichten sind die
- Multicast Listener Query Message und die
- Multicast Listener Report Message
Well-known Multicast Addresses
Auswahl
| Scope: Node Adresse, Präfix | Nutzung |
|---|---|
| ff 1::1 | Alle Nodes |
| ff 1::2 | Alle Router |
| ff 1::fb | Multicast-DNS |
| Scope: Link Adresse, Präfix | Nutzung |
|---|---|
| ff 2::1 | |
| ff 2::2 | |
| ff 2::b | |
| ff 2::f | |
| ff 2::16 | |
| ff 2::6a | |
| ff 2::fb | |
| ff 2::1:2 | |
| ff 2::1:ff : /1 4 |
| Scope: Site Adresse, Präfix | Nutzung |
|---|---|
| ff 5::2 | |
| ff 5::1:3 | |
| ff 5::fb |
| Scope: Variabel (X) Adresse, Präfix | Nutzung |
|---|---|
| ff X::fb | |
| ff X::1 1 | |
| ff X::db8: : /96 |
Nutzung Alle Nodes Alle Router Multicast-DNS
Nutzung Alle Nodes Alle Router Mobile Agents (Mobile IPv6) Universal Plug and Play Alle MLDv2-fähigen Router Alle Multicast-Abonnenten Multicast-DNS Alle DHCP-Agents Solicited Node Multicast Address Nutzung Alle Router Alle DHCP-Server Multicast-DNS Nutzung Multicast-DNS NTP Dokumentation
Multicast Scopes
| Scope | Name | Beschreibung |
|---|---|---|
| 0x0 | Reserviert | |
| 0x1 | Interface-Local | Das Multicast-Äquivalent zur Loopback Address ::1. Nur auf dem lokalen Node gültig |
| 0x2 | Link-local | Nur auf dem Link gültig. Die Pakete dürfen nicht geroutet werden |
| 0x3 | Reserviert | |
| 0x4 | Admin-Local | Vom Administrator festzulegender Teil des Netzes. Wird auch für eigenständig administrierte Abteilungen verwendet |
| 0x5 | Site-Local | Lokales, physikalisches Netzwerk. In der Regel eine Filiale oder eine Betriebsstätte |
| 0x6 - 0x7 | Nutzerdefiniert | Zur freien Definition eigener Gültigkeitsbereiche |
| 0x8 | Organization-Local | Ein die gesamte Organisation umfassender Gültigkeitsbereich. Umfasst auch geographisch entfernte Betriebsstätten, die über Standleitung oder Virtual Private Network (VPN) angebunden sind |
| 0x9- 0xd | Nutzerdefiniert | Zur freien Definition eigener Gültigkeitsbereiche |
| 0xe | Global | -Das gesamte Internet |
| 0xf | Reserviert |
Beschreibung Das Multicast-Äquivalent zur Loopback Address ::1
Nur auf dem lokalen Node gültig
Nur auf dem Link gültig
Die Pakete dürfen nicht geroutet werden
Vom Administrator festzulegender Teil des Netzes
Wird auch für eigenständig administrierte Abteilungen verwendet
Lokales, physikalisches Netzwerk
- In der Regel eine Filiale oder eine Betriebsstätte
Zur freien Definition eigener Gültigkeitsbereiche Ein die gesamte Organisation umfassender Gültigkeitsbereich Umfasst auch geographisch entfernte Betriebsstätten, die über Standleitung oder Virtual Private Network (VPN) angebunden sind Zur freien Definition eigener Gültigkeitsbereiche Das gesamte Internet
4.5 Multicast Darüber hinaus müssen Nodes aus Kompatibilitätsgründen auch die älteren MLDv1-Nachrichten
- Version 1 Multicast Listener Report und
- Version 1 Multicast Listener Done aus RFC 2710 [DFH99] unterstützen
Mit der Listener Query Message kann festgestellt werden, ob eine Gruppe noch Mitglieder hat
- Damit kann auch ein nicht ordnungsgemäßes Verlassen einer Gruppe bemerkt werden
Listener Query Message
Die Listener Report Messages dienen dazu, Multicast Groups beizutreten oder sie zu verlassen
- Jedes Interface, das Mitglied einer bestimmten Gruppe ist, nimmt für diese Gruppe die Rolle eines Multicast Listeners ein
- Pakete die an die Gruppenadresse gesendet wurden, werden allen Mitgliedern zugestellt
- Möchte ein Interface für eine Gruppe keine Pakete mehr erhalten, so verlässt es die Gruppe wieder
Listener Report Message
Den Beitritt zu einer Gruppe werden wir uns in Wireshark anschauen
- Dazu fahren wir das Interface eth0 auf lynx zuerst herunter:
Gruppenbeitritt mitschneiden
root@linux:~# ip link set down dev eth
Jetzt starten wir Wireshark und lassen ihn auf dem PseudoInterface lauschen
- Das Pseudo-Interface liefert die Daten von allen Interfaces, auch von denen, die erst nach dem Start des Mitschnitts hochgefahren werden
- Wir haben also die Chance, den Start eines Interfaces zu beobachten
- In diesem Zeitraum treten nämlich vermehrt MLDv2 Messages auf
- Dazu fahren wir das Interface wieder hoch
root@linux:~# ip link set up dev eth
Von den zahlreichen Paketen die von Wireshark mitgeschnitten wurden suchen wir uns eines vom Typ MLDv2 aus
Multicast Listener Discovery
Wir sehen einen Multicast Listener Report, eingebettet in ICMPv6 als Typ 143
- Neben den bekannten Code-, Checksumund Reserved-Feldern ist auch ein Feld namens Number of Multicast Address Records vorhanden
- Es gibt an, wie viele Multicast Address Record Changes folgen
- In unserem Beispiel folgt nur ein Eintrag, es wäre auch möglich mehrere Einträge auf einmal bekanntzugeben
- Jeder Eintrag steht für Änderungen der Zugehörigkeit zu Multicast Groups eines Interfaces
Include und Exclude
Die Interpretation der Einträge ist nicht ganz trivial
- Es gibt zwei Arten von Multicast Listener Report Messages
- Diese heißen Include und Exclude
- Ein Include steht allerdings nicht, wie der Wortlaut vielleicht vermuten lässt, für einen Gruppenbeitritt eines Interfaces
- Und ein Exclude muss nicht unbedingt einen Gruppenaustritt bedeuten
- Include und Exclude beziehen sich nämlich nicht auf die Multicast Group, sondern auf eine Liste von Quellen, von denen ein Interface Pakete an die Gruppe akzeptiert (Include) oder auch nicht akzeptiert (Exclude)
- Nun kann ein Interface auch eine leere Liste mitschicken, und damit anzeigen, dass sich das Include oder Exclude auf keine Adressen bezieht
- Dann käme ein Include einem Gruppaustritt gleich, und ein Exclude mit leerer Liste entspräche einem Gruppenbeitritt
- Multicast Listener Report Messages erwecken manchmal den Eindruck einer doppelten Verneinung
Beispiel: Gruppenbeitritt
Dazu als Beispiel unsere MLDv2 Message: Wir klappen den Eintrag Multicast Address Record Changed to exclude auf und sehen uns die enthaltenen Informationen an
- Wir sehen die
IPv6-Header eines MLDv2Paketes
Art der Änderung, Exclude, und weitere Felder
- Das Feld Aux Data Length gibt an wie viele 8-Byte-Blöcke mit zusätzlichen Daten der Multicast Address folgen
- Da es hier den Wert 0
hat, sind keine weiteren Daten zu erwarten
- Es folgt die Anzahl der einschränkenden Quellen, hier 0, und im Anschluss die betroffene Multicast Address
Nach Auswertung aller Felder kommen wir zum dem Schluss: Es handelt sich in unserem Beispiel um eine Änderung der Art Exclude ohne Einschränkung der Quellen
- Für diese Multicast Group akzeptiert das Interface Pakete von allen Quellen, außer denen in der Liste
- Da die Liste leer ist, gibt es keine Quellen die vom Interface keine Pakete akzeptieren würde
Es handelt sich also um einen uneingeschränkten Gruppenbeitritt Abschließend schauen wir uns noch das Feld Hop Limit des vorangestellten IPv6-Headers an (siehe Abbildung 4.16)
- Es hat den Wert 1, was bedeutet, dass MLDv2-Pakete einen Router nicht passieren können
- Die ganze Organisation von Multicast Groups findet also auf dem lokalen Link statt
Hop Limit
Trotzdem möchte ein Interface vielleicht den Datenstrom einer Multicast-Quelle empfangen, die an einem anderen Link angeschlossen ist
- Wenn die Pakete den Router nicht passieren können, muss der Router anderweitig tätig werden, um den angeforderten Datenstrom bereitzustellen
- Dazu muss er
Multicast Routing
Quelle Multicast Listener
Multicast Listener
Multicast Router
Multicast Router
Multicast Listener
Beitritt zur Multicast-Gruppe
Konsument
Versand von Multicast-Daten
Multicast-fähig sein
- Er wird dann auch Multicast Router genannt
- Tatsächlich, wenn wir den Header weiter analysieren, entdecken wir einen Hop-by-Hop Extension Header mit Router Alert Option
- Der Router wird explizit darauf hingewiesen, dass dieses Paket für ihn wichtige Informationen enthalten könnte
Um den Datenstrom auf dem anfragenden Link bereitzustellen, muss der Router seinerseits den Datenstrom anfordern Entweder hat er ein Interface an einem Link an dem auch die Multicast-Quelle angeschlossen ist, dann tritt er einfach der entsprechenden Gruppe bei
- So erhält er die zugehörigen Pakete die er dann zum anfragenden Link routen kann
- Hat der Router kein Interface am Link der Multicast-Quelle, beauftragt er einen der ihm bekannten Multicast Router, die Daten bereitzustellen
- Dazu tritt er wieder der Multicast Group bei und nimmt für diese Gruppe am betroffenen Interface die Rolle eines Multicast Listeners ein
- Das Prinzip ist beispielhaft in Abbildung 4.17 dargestellt, hier ist die Quelle zwei Hops vom Konsumenten entfernt
4.6 | Multicast auf dem Link-layer All Nodes Multicast Address
- All Nodes Multicast Address
Wo bei IPv4 häufig Broadcast zum Einsatz kam, wird unter IPv6 Multicast verwendet
- Immer dann, wenn nicht alle Nodes am Link angesprochen werden sollen, ist die Verwendung von
4.6 Multicast auf dem Link-layer Multicast ressourcenschonender
- Idealerweise werden nur jene Nodes behelligt, die auch Interesse an den versendeten Daten haben
- Sollen doch einmal alle Nodes eines Links angesprochen werden, kann die All Nodes Multicast Address mit Link-local Scope genutzt werden
- Sie repräsentiert eine Multicast Group der alle Nodes am Link beitreten müssen
Um die Belastung auf dem Link gering zu halten, sollten Pakete für eine Multicast Group zwar an alle beigetretenen Interfaces zugestellt werden, unbeteiligte Interfaces aber außen vor gelassen werden
- Da sich 128 Bits lange Multicast Addresses nicht ohne Verlust auf gängige Link-layer Addresses abbilden lassen, muss man hier Einschränkungen hinnehmen
- Je nach verwendeter Link-Technologie und Intelligenz der beteiligten Link-layer-Geräte (Beispielsweise Switches), ist der Overhead kleiner oder größer
- Im ungünstigsten Fall sinkt die Effizienz auf das Niveau von Broadcast
Effizienzsteigerung durch Multicast
Die Umsetzung von Multicast Addresses auf Link-layer Addresses an Ethernet-Links werden wir wegen seiner praktischen Relevanz genauer untersuchen
- Das Verfahren ist auch in RFC 2464 [Cra98] beschrieben
Multicast auf Ethernet
Zunächst fangen wir mit Wireshark wieder eine Neighbor Solicitation auf
- Den Vorgang starten wir aber erst, wenn der Neighbor Cache von fuzzball keinen Eintrag mehr für lynx aufweist
- Dann senden einen Echo Request von fuzzball an lynx, um eine Neighbor Solicitation zu erzwingen:
Neighbor Solicitation mitschneiden
user@fuzzball :~ $ ping6 -c 3 fe8 ::2 : ff : fe6 : d1e % eth1 PING fe8 ::2 : ff : fe6 : d1e % eth1 ( fe8 ::2 : ff : fe6 : d1e ) ' 56 data bytes 64 bytes from fe8 ::2 : ff : fe6 : d1e : icmp_seq =1 ttl =64 ' time =3.85 ms 3 packets transmitted , 3 received , % packet loss , time ' 2 7 ms
Neighbor Solicitation mittels Linklayer-Multicast
Link-layer Multicast Address
Solicited Node Multicast Address
ff02::1:ff60:0d:1e
Solicited Node Multicast Address
33:33:ff:60:0d:1e
Multicast Link-Layer Address (MAC)
In Wireshark schauen wir uns den Ethernet-Header und den IPv6-Header der Neighbor Solicitation an
- Das Feld Destination im Ethernet-Header hat den Wert 33:33:ff:6 : d:1e
- Vergleichen wir den Wert mit der Zieladresse ff 2::1:ff6 :d1e im IPv6-Header, fallen Gemeinsamkeiten auf
- Offensichtlich wird die Link-layer Multicast Address aus der IPv6 Multicast Address abgeleitet
- Abbildung 4.19 verdeutlicht das Verfahren
In diesem Fall sind die letzten drei Bytes der Link-layer Multicast Address identisch mit denen der Link-layer Address des Interfaces
- Zur Erinnerung: Die Link-layer Address hatte uns der Node in einem Neighbor Advertisement mitgeteilt (siehe Abbildung 4.8 in Abschnitt 4.3 Neighbor Cache)
- Ein Switch müsste in diesem Fall den Frame einfach auf allen Ports aussenden, deren zugeordnete Link-layer Addresses auf die letzten drei Bytes der Link-layer Multicast Address enden
- Viele werden das nicht sein
- Ein so simples wie effizientes Verfahren
Multicast und Privacy Extensions
Problematischer wird es, wenn die Clients Privacy Extensions nutzen
- Dann weisen die Interface Identifier keine Gemeinsamkeiten mit der Link-layer Address mehr auf
- Trotzdem bilden die Interface Identifier die Grundlage für entsprechen-
4.6 Multicast auf dem Link-layer de Solicited Node Multicast Addresses
- Aus diesen wiederum wird die Link-layer Multicast Address abgeleitet
- Einem Switch, und sei er auch noch so schlau konfiguriert, bieten sich nun keine Anhaltspunkte mehr, auf welchen Ports der Frame erwünscht sein könnte
- Ihm bleibt nur eine Möglichkeit übrig:
Er sendet den Frame auf allen Ports hinaus
- Um diesem Effizienzverlust zu begegnen sind die Switch-Hersteller angehalten, MLDv2-Pakete auszuwerten
- Indem sich die Switche merken, an welchem Port Nodes zu einer Multicast Group beigetreten sind, können sie den Overhead signifikant senken
Dass sich dies spürbar auf die Herstellungskosten, und damit auch auf den Verkaufspreis auswirkt, dürfte auf der Hand liegen Einen Sonderfall gibt es allerdings, beschrieben in RFC 6085 [GTTD11]: Wenn der Absender weiß, dass nur ein einziges Interface in einer Multicast Group Mitglied ist, und ihm darüber hinaus die Link-layer Unicast Address des Interfaces bekannt ist, dann darf er direkt an diese adressieren
- Einem Switch wird so unter Umständen das mehrfache Aussenden eines Frames erspart
Sonderfall