|
|
| Zeile 8: |
Zeile 8: |
| ==== Links ==== | | ==== Links ==== |
| ===== Weblinks ===== | | ===== Weblinks ===== |
|
| |
| = 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 ==
| |
| ; Belastung auf dem Link
| |
| 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 Verfahren ist auch in RFC 2464 [Cra98] beschrieben
| |
|
| |
| ; 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
| |
|
| |
| Abbildung 4.18: Neighbor Solicitation mittels Linklayer-Multicast
| |
|
| |
| == 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 simples und 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 ==
| |
| ; Beschrieben in 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/Link]] | | [[Kategorie:IPv6/Link]] |
| </noinclude> | | </noinclude> |