IPv6/Link/Multicast: Unterschied zwischen den Versionen
Die Seite wurde neu angelegt: „=== 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-…“ |
Keine Bearbeitungszusammenfassung |
||
| Zeile 1: | Zeile 1: | ||
=== 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 Multicast ressourcenschonender | * 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 | * 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 | ||
=== Effizienzsteigerung durch Multicast === | === Effizienzsteigerung durch Multicast === | ||
; Belastung auf dem Link | ; 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 | 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 | ||
=== Multicast auf Ethernet === | === Multicast auf Ethernet === | ||
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 | ||
; 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 36: | Zeile 36: | ||
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 simples und effizientes Verfahren | * Ein simples und 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 entsprechende Solicited Node Multicast Addresses | * Trotzdem bilden die Interface Identifier die Grundlage für entsprechende 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: Er sendet den Frame auf allen Ports hinaus | ; 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 | * 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 | ||
| Zeile 64: | Zeile 64: | ||
=== Sonderfall === | === Sonderfall === | ||
; Beschrieben in RFC 6085 | ; 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 | * 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 | ||
[[Kategorie:IPv6/Link]] | [[Kategorie:IPv6/Link]] | ||
Version vom 3. Januar 2024, 13:37 Uhr
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