|
|
| Zeile 24: |
Zeile 24: |
| </noinclude> | | </noinclude> |
|
| |
|
| = TMP =
| |
| == 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 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
| |
|
| |
| == Effizienzsteigerung durch Multicast ==
| |
| 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
| |
|
| |
| == Multicast auf Ethernet ==
| |
| Die Umsetzung von Multicast Addresses auf Link-layer Addresses an Ethernet-Links werden wir wegen seiner praktischen Relevanz genauer untersuchen. Das ist in [[RFC 2464]] beschrieben.
| |
|
| |
| == Neighbor Solicitation mitschneiden ==
| |
| [[File:ipv6NeighborSolicitationLinklayerMulticast.png|mini|400px|Neighbor Solicitation mittels Link-layer-Multicast]]
| |
|
| |
| ; Aufzeichnung einer Neighbor Solicitation
| |
| # Wireshark starten
| |
| # Aufzeichnung erst starten, wenn der Neighbor Cache von ''router'' keinen Eintrag mehr für ''linux'' enthält
| |
| # Senden eines Echo Request vom ''router'' an ''linux'', um eine Neighbor Solicitation zu erzwingen <br clear=all>
| |
| user@router:~$ '''ping6 -c 3 fe80::200:ff:fe60:d1e%eth1'''
| |
| PING fe80::200:ff:fe60:d1e%eth1 (fe80::200:ff:fe60:d1e) 56 data bytes
| |
| 64 bytes from fe8::2:ff:fe6:d1e: icmp_seq=1 ttl=64 time =3.85ms
| |
| 3 packets transmitted, 3 received, 0% packet loss, time 2007ms
| |
|
| |
| == Solicited Node Multicast Address ==
| |
| ; Ethernet- und IPv6-Header der Neighbor Solicitation
| |
| [[File:ipv6LinklayerMulticastAddress.png|mini|400px|Link-layer Multicast Address]]
| |
| * Das Feld Destination im Ethernet-Header hat den Wert 33:33:ff:60:0d:1e
| |
| * Vergleichen wir den Wert mit der Zieladresse ff02::1:ff60:d1e im IPv6-Header, fallen Gemeinsamkeiten auf
| |
| * Offensichtlich wird die Link-layer Multicast Address aus der IPv6 Multicast Address abgeleitet
| |
|
| |
| Hier 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 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 entsprechende 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
| |
|
| |
| ; Sonderfall
| |
| Einen Sonderfall gibt es allerdings, beschrieben in [[RFC/6085|RFC 6085]]
| |
| * 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
| |
|
| |
|
| [[Kategorie:IPv6/Host]] | | [[Kategorie:IPv6/Host]] |
| [[Kategorie:Multicast]] | | [[Kategorie:Multicast]] |
Multicast auf dem Link-layer
IPv6/Host/Link Layer Multicast - Beschreibung
Beschreibung
Anhang
Siehe auch
Links
Weblinks