IPv6/Host/Multicast: Unterschied zwischen den Versionen

Aus Foxwiki
K Textersetzung - „lynx“ durch „linux“
 
(30 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''Multicast''' - Einsatz und Funktion
'''Multicast''' - Einsatz und Funktion


=== Anwendungsgebiete von Multicast ===
=== Anwendungsgebiete ===
[[File:datenstromOhneMulticast.png|mini|400px|Datenstrom ohne Multicast]]
[[File:datenstromOhneMulticast.png|mini|400px|Datenstrom ohne Multicast]]


; Einsatz von Multicast
; Einsatz von Multicast
* Vermeidung von mehrfacher Übertragung identischer Datenströme
* Vermeidung mehrfacher Übertragung identischer Datenströme
* Effizienten Organisation der Nodes an einem [[Link]]
* Effiziente Organisation von Nodes am [[Link]]
* Versenden von Nachrichten an Ziele, deren [[Link-Layer-Adresse]] unbekannt ist


; Wie werden Pakete an Ziele verschicken, deren [[Link-Layer-Adresse]] unbekannt ist?
; Multicast
; Die Lösung heißt Multicast
* [[Multicast Addresse]]n können mehrere Interfaces anzusprechen
* [[Multicast Addresses]] können mehrere Interfaces anzusprechen


Besonders nützlich ist das, wenn sich die angesprochenen Interfaces in verschiedenen Nodes befinden
Besonders nützlich ist das, wenn sich die angesprochenen Interfaces in verschiedenen Nodes befinden
* So können wir indirekt Gruppen von Nodes ansprechen
* Gruppen von Nodes ansprechen
* Alle Interfaces, die innerhalb eines Gültigkeitsbereiches dieselbe Multicast Address nutzen, bilden deshalb eine Multicast Group
* Alle Interfaces, die innerhalb eines Gültigkeitsbereiches dieselbe [[Multicast Address]] nutzen, bilden deshalb eine [[Multicast Group]]


==== Szenario ====
==== Szenario ====
; Um die Nutzung von Multicast bei Datenströmen zu verstehen, denken wir uns folgende Situation
Mehrere Zuschauer möchten eine 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
Zeile 31: Zeile 29:


=== 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
Zeile 38: Zeile 35:
; 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


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
Zeile 46: Zeile 42:
* 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


=== Multicast Addressen ===
=== Multicast Groups ===
[[File:ipv6MulticastAddress.png|mini|400px|Multicast Address]]
; Organisation von Multicast Groups
; Präfix <nowiki>ff::/8</nowiki>
* 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
{| class="wikitable options big"
|-
! 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
* 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
* 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
|-
| Transient || Ein gesetztes Transient Flag bedeutet, dass es sich nicht um eine Well-known Multicast Address handelt
|}


=== Multicast Scopes ===
Multicast Addresses identifizieren eine Multicast Group innerhalb ihres Scopes eindeutig
; 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
* Für die Organisation dieser Gruppen ist das Protokoll Multicast Listener Discovery v2 (MLDv2) zuständig
* Es ist in [[RFC 3810]] und [[RFC 4604]] standardisiert und definiert verschiedene Nachrichten, welche über ICMPv6 transportiert werden
* Es ist in [[RFC 3810]] und [[RFC 4604]] standardisiert und definiert verschiedene Nachrichten, welche über ICMPv6 transportiert werden


; Gebräuchliche Nachrichten
; Gebräuchliche Nachrichten
* Multicast Listener Query Message
* [[Multicast Listener Query Message]]
* Multicast Listener Report Message
* [[Multicast Listener Report Message]]
 
=== Well-known Multicast Addresses ===
{| class="wikitable options big"
|-
! Scope: Node Adresse !!
|-
! Präfix !! Nutzung
|-
| ff 1::1 || Alle Nodes
|-
| ff 1::2 || Alle Router
|-
| ff 1::fb || Multicast-DNS
|}
 
{| class="wikitable options big"
|-
! Scope: Link Adresse !!
|-
! Präfix !! Nutzung
|-
| ff 2::1 ||Alle Nodes
|-
| ff 2::2 ||Alle Router
|-
| ff 2::b ||Mobile Agents (Mobile IPv6)
|-
| ff 2::f ||Universal Plug and Play
|-
| ff 2::16 ||Alle MLDv2-fähigen Router
|-
| ff 2::6a ||Alle Multicast-Abonnenten
|-
| ff 2::fb ||Multicast-DNS
|-
| ff 2::1:2 ||Alle DHCP-Agents
|-
| ff 2::1:ff : /1 4 ||Solicited Node Multicast Address
|}
 
{| class="wikitable options big"
|-
! Scope: Site Adresse !!
|-
! Präfix !! Nutzung
|-
|ff 5::2 ||Alle Router
|-
|ff 5::1:3 ||Alle DHCP-Server
|-
|ff 5::fb ||Multicast-DNS
|}
 
{| class="wikitable options big"
|-
! Scope: Variabel (X) Adresse !!
|-
|-
! Präfix !! Nutzung
|-
|ff X::fb ||Multicast-DNS
|-
|ff X::1 1 ||NTP
|-
|ff X::db8: : /96 ||Dokumentation
|}
 
: IANA: http://www.iana.org/assignments/multicast-addresses


=== Multicast Scopes ===
=== Multicast Scopes ===
{| class="wikitable options big"
[[IPv6/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&#8209;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 ===
=== Listener Query Message ===
Zeile 209: Zeile 64:
=== 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 linux zuerst herunter
  root@linux:~# '''ip link set down dev eth'''
  root@linux:~# '''ip link set down dev eth'''


=== Gruppenbeitritt mitschneiden ===
=== Gruppenbeitritt ===
; Gruppenbeitritt mitschneiden
[[File:ipv6MulticastListenerDiscovery.png|mini|400px]]
[[File:ipv6MulticastListenerDiscovery.png|mini|400px]]
[[File:ipv6MLDv2Header.png|mini|400px]]
[[File:ipv6MLDv2Header.png|mini|400px]]
Zeile 223: Zeile 79:
  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<br clear=all>


=== Multicast Listener Discovery ===
=== Multicast Listener Discovery ===
Zeile 252: Zeile 108:
* 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


; Auswertung aller Felder
; Auswertung der Felder
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
Zeile 290: Zeile 146:


[[Kategorie:IPv6/Host]]
[[Kategorie:IPv6/Host]]
[[Kategorie:Multicast]]
</noinclude>
</noinclude>

Aktuelle Version vom 22. Januar 2024, 15:16 Uhr

Multicast - Einsatz und Funktion

Anwendungsgebiete

Datenstrom ohne Multicast
Einsatz von Multicast
  • Vermeidung mehrfacher Übertragung identischer Datenströme
  • Effiziente Organisation von Nodes am Link
  • Versenden von Nachrichten an Ziele, deren Link-Layer-Adresse unbekannt ist
Multicast

Besonders nützlich ist das, wenn sich die angesprochenen Interfaces in verschiedenen Nodes befinden

Szenario

Mehrere Zuschauer möchten eine 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
Datenstrom mit Multicast

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 Groups

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 und RFC 4604 standardisiert und definiert verschiedene Nachrichten, welche über ICMPv6 transportiert werden
Gebräuchliche Nachrichten

Multicast Scopes

IPv6/Multicast Scopes

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 linux zuerst herunter
root@linux:~# ip link set down dev eth

Gruppenbeitritt

Gruppenbeitritt mitschneiden

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 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

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 bekannt zugeben
  • Jeder Eintrag steht für Änderungen der Zugehörigkeit zu Multicast Groups eines Interfaces

Include und Exclude

Interpretation der Einträge
  • 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
Gruppenbeitritt
Abbildung 4.16 IPv6-Header eines MLDv2-Paketes
MLDv2 Message

Wir klappen den Eintrag Multicast Address Record Changed to exclude auf und sehen uns die enthaltenen Informationen an

  • Wir sehen die 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
Auswertung der Felder

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

Hop Limit

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

Multicast Routing

Multicast Routing

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-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

Multicast auf dem Link-layer

IPv6/Host/Multicast auf dem Link-layer


Anhang

Siehe auch

Links

Weblinks