|
|
| (40 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| ; Die Hosts
| | '''IPv6-Host''' - |
|
| |
|
| Jetzt, wo wir uns eine Maschine gebaut haben die später routen soll, stehen wir vor einem Henne-Ei-Problem. Erweiterten wir fuzzball jetzt um die Routing-Funktionalitäten, dann täten wir uns schwer diese zu testen. Uns fehlen im Moment noch die Hosts am internen Link, die den Router benutzen könnten.
| | == Beschreibung == |
| Wie also sollten wir die Korrektheit des Routings überprüfen?
| | ; Hosts am internen Link |
| Deshalb werden wir den internen Link zunächst mit Hosts bevölkern. Anschließend wenden wir uns im Kapitel 5 Der Link wieder dem Router zu.
| |
| Aus lizenzrechtlichen Gründen ist es leider nicht möglich eine Windows-Appliance zur Verfügung zu stellen. Bei der LinuxAppliance haben Sie wieder die Wahl: Sie können die virtuelle Maschine selbst installieren oder als fertige Appliance von der Homepage des IPv6-Workshops herunterladen und in VirtualBox importieren.1 Wenn Sie sich für die Appliance entschieden haben können Sie den folgenden Abschnitt überspringen.
| |
|
| |
|
| == Debian Linux == | | {| class="wikitable big options" |
| [[IPv6/Host/Debian]] | | |- |
| | ! [[Betriebssystem]] !! Beschreibung |
| | |- |
| | | Debian Linux || [[IPv6/Host/Debian]] |
| | |- |
| | | Microsoft Windows || [[IPv6/Host/Windows]] |
| | |} |
|
| |
|
| == Microsoft Windows == | | ; Funktionen |
| [[IPv6/Host/Windows]] | | {| class="wikitable big options" |
| | |- |
| | ! Funktion !! Beschreibung |
| | |- |
| | | Neighbor Cache || [[IPv6/Host/Neighbor Cache]] |
| | |- |
| | | Interface Identifier || [[IPv6/Host/Interface Identifier]] |
| | |- |
| | | Multicast || [[IPv6/Host/Multicast]] |
| | |} |
|
| |
|
| == Neighbor Cache ==
| | <noinclude> |
| Am internen Link sind nun drei Nodes vorhanden. Der Router fuzzball sowie die Hosts lynx und felis. Sind alle Maschinen hochgefahren, sieht der interne Link wie in Abbildung 4.5 dargestellt aus.
| |
| Neighbor Discovery Protocol
| |
|
| |
|
| Dank der Link-local Addresses waren die Nodes in der Lage miteinander auf dem internen Link zu kommunizieren. Wir haben dies mit diversen Echo Requests bereits ausprobiert.
| | == Anhang == |
| | | === Siehe auch === |
| 4.3 Neighbor Cache fuzzball
| | {{Special:PrefixIndex/{{BASEPAGENAME}}}} |
| | | ==== Links ==== |
| lynx internal eth1
| | ===== Weblinks ===== |
| | |
| eth0
| |
| | |
| Abbildung 4.5
| |
| Link internal mit fuzzball, lynx und felis
| |
| | |
| felis
| |
| | |
| LAN1
| |
| | |
| Das heißt, die Nodes waren in der Lage die Link-local Addresses ihrer Nachbarn zu gültigen Link-layer Addresses aufzulösen. Unser Link internal ist ein virtuelles Ethernet, die Link-layer Addresses entsprechen in unserem Netz deshalb den bei Ethernet gebräuchlichen MAC-Adressen. Zuständig für die Auflösung von IPv6-Adressen zu Link-layer Addresses ist das Neighbor Discovery Protocol (NDP), spezifiziert in RFC 4861 [NNSS07]. NDP wird über ICMPv6 transportiert. Damit ist es von IPv6 abhängig, wenn es IPv6-Adressen auflösen soll. Wie und warum das dennoch funktioniert, werden wir uns gleich anschauen. Vorher machen wir uns aber noch mit den Neighbor Caches vertraut. Jeder Node betreibt einen Neighbor Cache in dem er die Ergebnisse der Link-layerAdressauflösungen zwischenspeichert.
| |
| Übrigens: Unter IPv4 haben wir für die Auflösung noch ARP benutzt, dessen Ergebnisse in der ARP-Tabelle zwischengespeichert wurden.
| |
| Die Einträge in den Neighbor Caches sind je nach Betriebssystem und Zustand unterschiedlich lange gültig. Im Normalfall sind sie sehr kurzlebig. Wir brauchen für die folgenden Experimente deshalb mitunter mehrere Anläufe. Für das Einfangen eines ganz bestimmten Zustands müssen wir zum richtigen Zeitpunkt den Neighbor Cache auslesen. Manchmal ist es daher vorteilhaft, das nächste Kommando schon in der Zwischenablage bereit zu halten, um schneller reagieren zu können.
| |
| | |
| Hinweis
| |
| | |
| Wir wechseln zur Maschine felis und öffnen ein Terminal, zum Beispiel mit der bereits bekannten Methode Windows-Taste+R und cmd. Um sicher zu gehen, dass sich Einträge im Neighbor
| |
| | |
| Neighbor Cache
| |
| (Windows 8)
| |
| | |
| 4 Die Hosts Cache befinden werden, kommunizieren wir mit einem anderen Node auf dem Link. Ein Echo Request an die Link-local Address von lynx bietet sich da an.
| |
| | |
| Q
| |
| | |
| C :\ Users \ user > ping -n 3 fe8 ::2 : ff : fe6 : d1e %12
| |
| Pinging fe8 ::2 : ff : fe6 : d1e %12 with 32 bytes of data :
| |
| Reply from fe8 ::2 : ff : fe6 : d1e %12: time <1 ms
| |
| Packets : Sent = 3 , Received = 3, Lost =
| |
| ( % loss ) ,
| |
| | |
| Sobald eine Antwort eintrifft, können wir den Vorgang abbrechen und uns den Neighbor Cache ausgeben lassen. Das Kommando dazu geben wir unmittelbar nach dem letzten Echo Request ein:
| |
| Q
| |
| | |
| Q
| |
| | |
| C :\ Users \ user > netsh interface
| |
| Interface 12: LAN1
| |
| Internet Address
| |
| ---------------------------fe8 ::2 : ff : fe6 : d1e
| |
| ff 2 ::1
| |
| ff 2 ::1: ff6 : d1e
| |
|
| |
| ipv6 show neighbors
| |
| Physical Address
| |
| ----------------- - -6 - d -1 e
| |
| 33 -33 - - - - 1
| |
| 33 -33 - ff -6 - d -1 e
| |
|
| |
| Type
| |
| --------Reachable
| |
| Permanent
| |
| Permanent
| |
| | |
| Die IPv6-Adresse fe8 ::2 :ff:fe6 :d1e wurde korrekt zur Link-layer Address - - -6 - d-1e aufgelöst. Der Zustand des Eintrages ist Reachable, das heißt, der zugehörige Node gilt auf dem Link als erreichbar. Nach circa 20 Sekunden lassen wir uns den Neighbor Cache ein weiteres Mal ausgeben:
| |
| Q
| |
| | |
| Q
| |
| | |
| C :\ Users \ user > netsh interface
| |
| Interface 12: LAN1
| |
| Internet Address
| |
| ---------------------------fe8 ::2 : ff : fe6 : d1e
| |
| ff 2 ::1
| |
| ff 2 ::1: ff6 : d1e
| |
|
| |
| ipv6 show neighbors
| |
| Physical Address
| |
| ----------------- - -6 - d -1 e
| |
| 33 -33 - - - - 1
| |
| 33 -33 - ff -6 - d -1 e
| |
|
| |
| Type
| |
| --------Stale
| |
| Permanent
| |
| Permanent
| |
| | |
| Der Eintrag für die Adresse fe8 ::2 :ff:fe6 :d1e hat seinen Zustand zwischenzeitlich auf Stale gewechselt. Die Nachbarn am Link können offensichtlich verschiedene Zustände haben.
| |
| Neighbor Cache
| |
| (Debian GNU/Linux 6)
| |
| | |
| Die Zustände werden wir in einem weiteren Experiment, diesmal von lynx aus, untersuchen. Wir verschicken Echo Requests an fuzzball, werden uns aber bei Eingabe der Adresse im letzten Zeichen vertippen. Die Echo Requests gehen an die
| |
| | |
| 4.3 Neighbor Cache Adresse fe8 ::219:83ff:fe 9:17db. Den Vorgang brechen wir vorerst nicht ab.
| |
| | |
| Q
| |
| | |
| user@lynx :~ $ ping6 fe8 ::219:83 ff : fe 9 :17 db % eth
| |
| PING fe8 ::219:83 ff : fe 9 :17 db % eth '
| |
| ( fe8 ::219:83 ff : fe 9 :17 db ) 56 data bytes
| |
| From fe8 ::2 : ff : fe6 : d1e icmp_seq =1 Destination '
| |
| unreachable : Address unreachable
| |
| 48 packets transmitted ,
| |
| received , +42 errors , 1 % '
| |
| packet loss , time 47182 ms
| |
| | |
| Während lynx weiter fleißig Echo Requests versendet, öffnen wir ein zweites Terminal und schauen in diesem auf den Neighbor Cache. Unter Linux steht uns dafür das Kommando ip neighbor show zur Verfügung.
| |
| user@lynx :~ $ ip neighbor show
| |
| fe8 ::219:83 ff : fe 9 :17 db dev eth
| |
| | |
| INCOMPLETE
| |
| | |
| Wir lernen mit Incomplete einen weiteren Zustand kennen.
| |
| Nun brechen wir das Senden der Echo Requests im ersten Terminal ab, wechseln zügig in das zweite Terminal und lassen uns erneut den Neighbor Cache ausgeben.
| |
| user@lynx :~ $ ip neighbor show fe8 ::219:83 ff : fe 9 :17 db dev eth
| |
| | |
| FAILED
| |
| | |
| Sofern wir uns nicht zu viel Zeit gelassen haben, sehen wir noch den Zustand Failed bevor der Eintrag aus dem Neighbor Cache verschwindet. Failed ist allerdings kein Zustand den man in RFC 4861 [NNSS07] findet, sondern soll verdeutlichen, dass die Auflösung der Adresse nicht erfolgreich beendet werden konnte.
| |
| Den anderen Zuständen hingegen sind klare Bedeutungen zugeordnet:
| |
| | |
| Zustände der Einträge
| |
| | |
| Incomplete Es findet gerade eine Adressauflösung statt. Diese konnte aber noch nicht erfolgreich beendet werden.
| |
| Reachable Der zugehörige Nachbar gilt als erreichbar. Entweder findet gerade eine Kommunikation mit ihm statt oder eine solche ist erst wenige Sekunden her.
| |
| | |
| 4 Die Hosts Stale Die Erreichbarkeit des zugehörigen Nachbarn ist unbekannt. Es fand kürzlich eine Kommunikation mit ihm statt. Solange keine weitere Kommunikation beabsichtigt ist, sollte auf eine erneute Adressauflösung verzichtet werden.
| |
| Delay Der zugehörige Nachbar gilt nicht als erreichbar. Es wurde aber wieder eine Kommunikation mit ihm gestartet. Bleibt eine Bestätigung der Erreichbarkeit durch die kommunizierende Schicht aus, wird auf IP-Schicht die Erreichbarkeit aktiv überprüft werden.
| |
| Probe Der zugehörige Nachbar gilt nicht als erreichbar. Seine Erreichbarkeit wird gerade aktiv geprüft. Sollte die Prüfung fehlschlagen, wird der Eintrag entfernt.
| |
| Adressauflösung mitschneiden
| |
| | |
| Dass die Neighbor Caches funktionieren haben wir gerade gesehen. Auch wissen wir dank der erfolgreichen Echo Requests, dass die Auflösung von IPv6-Adressen und Link-layer Addresses funktioniert. Es ist nun an der Zeit, die Frage nach dem Wie zu beantworten.
| |
| Dazu suchen wir uns einen Node aus, der gerade einen leeren Neighbor Cache hat, zum Beispiel fuzzball. Das Kommando zum Anzeigen des Neighbor Caches ist uns aus den vorherigen Experimenten noch bekannt. Sollten sich noch gültige Einträge im Neighbor Cache befinden, warten wir noch etwas ab.
| |
| Wenn der Node seine IPv6-Nachbarn schließlich vergessen hat, starten wir Wireshark auf dem entsprechenden Interface, hier eth1. Um eine Adressauflösung zu erzwingen versenden wir wieder Echo Requests:
| |
| | |
| Q
| |
| | |
| 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.75 ms
| |
| 3 packets transmitted , 3 received , % packet loss , time '
| |
| 2 5 ms
| |
| | |
| 4.3 Neighbor Cache Abbildung 4.6
| |
| Neighbor Solicitation
| |
| | |
| Hat der betroffene Node wie gewünscht geantwortet stoppen wir die Aufzeichnung und schauen uns die Ergebnisse in Wireshark an.
| |
| Das erste Paket von Interesse ist eine Neighbor Solicitation genannte Nachricht (siehe Abbildung 4.6).
| |
| | |
| Neighbor Solicitation
| |
| | |
| Da das Neighbor Discovery Protocol ein in ICMPv6 eingebettetes Protokoll ist, fängt der spannende Teil mit einem ICMPv6-Header an. Der Nachrichtentyp hat die Nummer 135
| |
| und den Code 0. Neben der Checksum und reservierten Bytes existiert ein weiteres Feld, die Target Address. Sie enthält die aufzulösende IPv6-Adresse und gehört zum Ziel unseres Echo Requests. Danach folgt eine ICMPv6-Option namens Source Link-layer Address. Dabei handelt es sich um zusätzliche Informationen, die der Absender im Paket unterbringen kann. Hier hat fuzzball die Link-layer Address seines Interfaces freundlicherweise im Paket vermerkt. Der Gegenseite liefert er damit wertvolle Informationen für ihren eigenen Neighbor Cache. Ganz nebenbei ersparen solche Zusatzinformationen dem Link das ein oder andere Paket.
| |
| Aber wie konnte das Paket überhaupt beim richtigen Node am Link landen, wo wir doch seine Link-layer Address noch nicht kennen? Die Lösung ist im IPv6-Header des Paketes versteckt und lautet Solicited Node Multicast Address. Sie wird wie in Abbildung 4.7 dargestellt berechnet.
| |
| | |
| Solicited Node Multicast Address
| |
| | |
| Pakete an die Solicited Node Multicast Address eines Nodes können auch bei unbekannter Link-layer Address an diesen
| |
| | |
| 4 Die Hosts Abbildung 4.7
| |
| Solicited Node Multicast Address
| |
| | |
| 00:00:00:60:0d:1e
| |
| | |
| Link-Layer Address (MAC)
| |
| | |
| ff02::1:ff60:0d1e
| |
| | |
| Solicited Node Multicast Address
| |
| | |
| Abbildung 4.8
| |
| Neighbor Advertisement
| |
| | |
| zugestellt werden. Wie genau das funktioniert werden wir in Abschnitt 4.5 Multicast lernen. Vorerst werden wir uns damit begnügen, dass es irgendwie funktioniert.
| |
| Neighbor Advertisement
| |
| | |
| Natürlich antwortet der angesprochene Node kurz darauf.
| |
| Er tut dies mit einem sogenannten Neighbor Advertisement.
| |
| Wieder schauen wir in das Paket, ähnlich Abbildung 4.8, hinein.
| |
| Die Typnummer lautet nun 136, der Code bleibt unverändert und hat den Wert 0. Die Target Address gibt weiterhin an, für welche IPv6-Adresse eine Auflösung stattfindet. Neu ist das Feld Flags, das wir neugierig aufklappen. Wireshark erläutert die Flags eher sparsam, darum hier ihre Bedeutung:
| |
| Router Ein gesetztes Flag zeigt an, das es sich bei der Quelle um einen Router handelt. Das ist wichtig zu wissen, da ein Router an einem Link seine Rolle aufgeben kann.
| |
| Er wird dann zu einem normalen Host. Diese Änderung zeigt er durch das Nichtsetzen des Flags an.
| |
| Solicited Mit diesem Flag wird darauf hingewiesen, dass das Neighbor Advertisement die Folge einer vorhergehen Neighbor Solicitation ist. Der Empfänger bekommt damit die Erreichbarkeit eines Nodes bestätigt. Mit der
| |
| | |
| 4.4 Interface Identifier
| |
| Information kann er seinen Neighbor Cache aktualisieren und Einträge im Zustand Stale oder Probe zurück auf Reachable setzen.
| |
| Override Mit dem Override-Flag kann die Quelle festlegen, was das Ziel des Neighbor Advertisements in den Neighbor Cache eintragen soll. Ist es gesetzt, werden existierende Einträge zu der angegeben Adresse überschrieben.
| |
| Ist es nicht gesetzt, darf es lediglich einen unvollständigen Eintrag ergänzen. Adressen, deren Einträge man nicht mit jedem Neighbor Advertisement überschreiben will, sind zum Beispiel Anycast Addresses. Wenn mehrere Anycast Hosts am Link vorhanden sind, laufen die anderen Hosts sonst Gefahr, ständig ihre Neighbor Caches zu überschreiben, ohne einen Nutzen daraus zu ziehen.
| |
| Die letzte Information im Paket ist die Source Link-layer Address, der eigentliche Grund der Anfrage.
| |
| Übrigens: An diesem Beispiel zeigt sich die Flexibilität von IPv6. Die ICMPv6-Optionen werden stets zusammen mit einer Längenangabe versendet. Sollte sich irgendwann eine LinkTechnologie durchsetzen die mehr als 6 Bytes für eine Linklayer Address benötigt, steht einer Vergrößerung der entsprechenden ICMPv6-Option nichts im Wege.
| |
| Der gesamte Prozess der Adressauflösung zwischen zwei Nodes auf dem Link besteht aus nur zwei Paketen. Von den Paketen musste keines an alle Nodes gesendet werden (siehe Abbildung 4.9). Gegenüber Broadcast stellt das eine deutliche Einsparung dar, gerade an Links mit vielen Nodes.
| |
| | |
| Ablauf einer typischen Adressauflösung
| |
| | |
| == Interface Identifier == | |
| Die Nodes am Link internal haben sich ihre Link-local Addresses selbst gegeben. Dabei hat jeder Node eine eigene Adresse erhalten, ohne das eine Adresse doppelt vorkam. Bisher haben wir das als gegeben hingenommen oh95
| |
| | |
| 4 Die Hosts Abbildung 4.9
| |
| Ablauf einer typischen Adressauflösung
| |
| | |
| Abbildung 4.10
| |
| Link-local Address (ungekürzt)
| |
| | |
| 64 Bit
| |
| | |
| 64 Bit
| |
| | |
| fe80:0000:0000:0000:0020:00ff:fe60:0d1e /64
| |
| Präfix
| |
| | |
| Interface Identifier
| |
| | |
| ne das Prinzip dahinter zu kennen. Das werden wir jetzt ändern.
| |
| Interface Identifier
| |
| | |
| Abbildung 4.10 zeigt eine Link-local Address mit einer Präfixlänge von 64 Bits. Die hinteren 64 Bits sind nicht durch das Präfix vorgegeben und stehen den Interfaces am Link zur Adressierung zur Verfügung. Sie werden deshalb Interface Identifier genannt.
| |
| Das A und O in IP-Netzen ist die Eindeutigkeit der Adressen innerhalb ihres Scopes.2 Unter IPv4 haben wir entweder den dezimalen Hostanteil der Adresse mit jedem neuen Node inkrementiert oder die Aufgabe gleich ganz einem DHCP-Server übertragen. Von Tippfehlern oder mutwilligen Störungen abgesehen, war damit die Eindeutigkeit der Adressen gewährleistet.
| |
| IPv6 nimmt uns das Adressieren des einzelnen Nodes aber ab.
| |
| Darum muss es auch für die Eindeutigkeit der Adressen Sorge tragen.
| |
| | |
| An dieser Stelle sprechen wir von Unicast Addresses. Für einen Moment ignorieren wie die Tatsache, dass daneben noch Multicast und Anycast Addresses existieren.
| |
| | |
| 4.4 Interface Identifier
| |
| | |
| 00000000b
| |
| | |
| 00:00:00:60:0d:1e
| |
| | |
| Link-Layer Address (MAC)
| |
| | |
| 00000010b fe80::0200:00ff:fe60:0d:1e
| |
| | |
| Link-Local Address
| |
| | |
| Was also liegt näher, als die Link-layer Address des zugehörigen Interfaces als Quelle für einen eindeutigen Interface Identifier herzunehmen? Benutzt das Interface schon einen Extended Unique Identifier mit einer Länge von 64 Bits, dann kann dieser ohne Umwege übernommen werden.3 Auf dem klassischen Ethernet sind die Link-layer Addresses aber nur 48 Bits lang.
| |
| | |
| Abbildung 4.11
| |
| Bildung der Linklocal Address von lynx
| |
| | |
| Von der Mac-Adresse zum EUI-64
| |
| | |
| Schauen wir doch bei lynx nach, wie sein IPv6-Stack das Problem gelöst hat. Als erstes ein Blick auf die Link-layer Address:
| |
| user@lynx :~ $ ip link show dev eth
| |
| 2: eth : < BROADCAST , MULTICAST ,UP , LOWER_UP > mtu 15
| |
| '
| |
| qdisc pfifo_fast state UP qlen 1
| |
| link / ether
| |
| : : :6 : d :1 e brd ff : ff : ff : ff : ff : ff
| |
| | |
| Danach die Link-local Address des Interfaces:
| |
| user@lynx :~ $ ip addr show dev eth
| |
| 2: eth : < BROADCAST , MULTICAST ,UP , LOWER_UP > mtu 15
| |
| '
| |
| qdisc pfifo_fast state UP qlen 1
| |
| link / ether
| |
| : : :6 : d :1 e brd ff : ff : ff : ff : ff : ff
| |
| inet6 fe8 ::2 : ff : fe6 : d1e /64 scope link
| |
| valid_lft forever preferred_lft forever
| |
| | |
| Offensichtlich wurde die Link-layer Address in den Interface Identifier aufgenommen. Der Stack hat das zweit-niederwertigste Bit im ersten Byte der Link-layer Address gekippt. In der Mitte der Link-layer Address wurden darüberhinaus die hexadezimale Zeichenfolge ff:fe eingefügt. Auf diese Weise ist ein sogenannter Modified EUI-64 entstanden. In Abbildung 4.11 ist der Vorgang graphisch dargestellt.
| |
| | |
| 64-Bit Extended Unique Identifier haben, ebenso wie 48-Bit Extended Unique Identifier (auch bekannt als MAC-Adressen), die Aufgabe, auf dem Link-layer teilnehmende Geräte zu adressieren. Um einer Knappheit an EUI-48 frühzeitig vorzubeugen, hat die IEEE die EUI-64 definiert.
| |
| | |
| 4 Die Hosts Bitspielereien
| |
| | |
| Das gekippte Bit verwirrt im ersten Augenblick. Die Erklärung liegt in der Bedeutung des betroffenen Bits verborgen, dessen Name Universal/Local Bit lautet. Es zeigt an, ob die MACAdresse vom Hersteller vergeben wurde (Wert 0), oder ob sie lokal überschrieben wurde (Wert 1). Die Werte 0 und 1 des Universal/Local Bit sind bei einem Modified EUI-64 von umgekehrter Bedeutung, deswegen verlangt der IPv6-Standard das Kippen desselben.
| |
| | |
| Privacy Extensions
| |
| | |
| Der so generierte Interface Identifier findet sich nicht nur in Link-local Addresses, sondern auch in Global Unicast Addresses wieder. Die Link-layer Adress eines Nodes, dessen IPv6Adresse einen solchen Interface Identifier enthält, kann zurückgerechnet werden. Das beeinträchtigt natürlich die Privatsphäre der betroffenen Nutzer. Erstens können Kommunikationspartner einen Node wiedererkennen, selbst wenn er zwischenzeitlich das Präfix gewechselt haben sollte, denn der Interface Identifier ändert sich bei einem Präfixwechsel nicht.
| |
| Zweitens lässt sich vom Interface Identifier auf den Hersteller des verwendeten Interfaces schließen. Damit ist einem umfangreichen Tracking und Profiling von Nutzern Tür und Tor geöffnet.
| |
| Das Problem wurde schließlich mit der Einführung der Privacy Extensions gelöst. Das sind Adressen, die keine Rückschlüsse mehr auf die Link-layer Address des Interfaces zulassen.
| |
| Windows 8 geht sogar so weit, und setzt die Privacy Extensions auch bei den Link-local Addresses ein. Das werden wir uns auf felis ansehen:
| |
| | |
| Q
| |
| | |
| C :\ Users \ user > ipconfig
| |
| Ethernet adapter LAN1 :
| |
| Link - local IPv6 Address . . . . . : '
| |
| fe8 :: e8a4 :145 b :625 c: e6a1 %12
| |
| | |
| Ein Muster ist nicht zu erkennen, und auch das markante ff:fe fehlt. Diese Adresse folgt keinem bestimmten Muster! Es handelt sich um eine zufällige Folge hexadezimaler Zeichen. In regelmäßigen Abständen wird eine neue, zufällige Adresse generiert und die alte verworfen. Die Standardeinstellung vieler
| |
| | |
| 4.5 Multicast Betriebssysteme dafür ist 24 Stunden. Ein Tracking des Nutzers ist so, zumindest auf IP-Schicht, nicht über 24 Stunden hinweg möglich.
| |
| Die zufällig generierten Adressen kann man Windows 8 mit netsh abgewöhnen. Für die Änderung dieser Einstellung verlangt Windows 8 Administratorrechte, darum führen wir das folgende Kommando als Administrator aus. Dazu betätigen wir die Tastenkombination Windowstaste+X. Es erscheint ein Menü in dem wir den Punkt Command Prompt (Admin) auswählen:
| |
| C :\ Users \ user > netsh interface ipv6 set global '
| |
| randomizeidentifiers = disabled
| |
| Ok .
| |
| | |
| Von der Wirkung können wir uns sofort überzeugen.
| |
| | |
| Q Q
| |
| | |
| C :\ Users \ user > ipconfig / all
| |
| Ethernet adapter LAN1 :
| |
| Physical Address . . . . . . . . . :
| |
| Link - local IPv6 Address . . . . . : '
| |
| fe8 ::2 : ff : fe f : e715 %12( Preferred )
| |
| | |
| -
| |
| | |
| - F -E7 -15
| |
| | |
| Diesmal wurde die Adresse mit Hilfe eines Modified EUI-64 erzeugt. Wenn Sie möchten, können Sie die Privacy Extensions jetzt wieder einschalten:
| |
| C :\ Users \ user > netsh interface ipv6 set global '
| |
| randomizeidentifiers = enabled
| |
| Ok .
| |
| | |
| == Multicast == | |
| Wir haben beim ersten Blick auf die Neighbor Solicitation eine wichtige Frage vorerst zurückgestellt: Wie verschicken wir Pakete an Ziele, deren Link-layer Address uns noch nicht bekannt ist? Die Lösung heißt Multicast und die zugehörigen Adressen sind die Multicast Addresses. Multicast Addresses sind in der Lage, mehrere Interfaces anzusprechen. Besonders nützlich ist das, wenn sich die angesprochenen Interfaces in verschiedenen Nodes befinden. So können wir indirekt Gruppen von
| |
| | |
| 4 Die Hosts Abbildung 4.12
| |
| Übertragung eines Datenstroms ohne Multicast
| |
| | |
| Router A
| |
| | |
| Konsument 1
| |
| | |
| Konsument 2
| |
| | |
| Router B
| |
| | |
| Quelle
| |
| | |
| Nodes ansprechen. Alle Interfaces, die innerhalb eines Gültigkeitsbereiches dieselbe Multicast Address nutzen, bilden deshalb eine Multicast Group.
| |
| Anwendungsgebiete von Multicast
| |
| | |
| Szenario
| |
| | |
| In IPv6 verwenden wir Multicast hauptsächlich zur
| |
| • Vermeidung von mehrfacher Übertragung identischer Datenströme und
| |
| • effizienten Organisation der Nodes an einem Link.
| |
| Um die Nutzung von Multicast bei Datenströmen zu verstehen, denken wir uns in folgende Situation hinein: 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.
| |
| | |
| MulticastDatenströ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
| |
| | |
| 4.5 Multicast
| |
| | |
| Router A
| |
| | |
| Konsument 1
| |
| | |
| Router B
| |
| | |
| Konsument 2
| |
| | |
| Präfix
| |
| | |
| Abbildung 4.13
| |
| Übertragung eines Datenstroms mit Multicast
| |
| | |
| Multicast-Quelle
| |
| | |
| Flags Scope Group Identifier ff02::13:37:23:42
| |
| | |
| Abbildung 4.14
| |
| Multicast Address
| |
| | |
| in der Lage, diese Nachfrage zu befriedigen, da die Kapazitätsgrenzen der Links und Router erreicht werden würden.
| |
| Eine Lösung stellt Multicast dar. Abbildung 4.13 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 Addresses sind durch das Präfix ff::/8 gekennzeichnet. 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.
| |
| | |
| Multicast Addresses
| |
| | |
| Die Flags (in Leserichtung) haben folgende Bedeutung:
| |
| Reserviert Das erste Flag ist reserviert für spätere Erweiterungen.
| |
| Es wird auf Null gesetzt.
| |
| | |
| 4 Die Hosts 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
| |
| [SH04].
| |
| 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.
| |
| 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 4.6 entnommen werden.
| |
| | |
| Organisation von Multicast Groups
| |
| | |
| Eine Multicast Address identifiziert 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.
| |
| | |
| http:// www.iana.org/ assignments/ multicast-addresses
| |
| | |
| 4.5 Multicast
| |
| | |
| Scope: Node
| |
| Adresse, Präfix
| |
| ff 1::1
| |
| ff 1::2
| |
| ff 1::fb
| |
| Scope: Link
| |
| Adresse, Präfix
| |
| 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
| |
| ff 5::2
| |
| ff 5::1:3
| |
| ff 5::fb
| |
| Scope: Variabel (X)
| |
| Adresse, Präfix
| |
| ff X::fb
| |
| ff X::1 1
| |
| ff X::db8: : /96
| |
| | |
| Nutzung Alle Nodes Alle Router Multicast-DNS
| |
| | |
| Tabelle 4.5
| |
| Well-known Multicast Addresses
| |
| (Auswahl)
| |
| | |
| 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
| |
| | |
| 4 Die Hosts
| |
| | |
| Tabelle 4.6
| |
| Multicast Scopes
| |
| | |
| Scope x
| |
| x1
| |
| | |
| Name Reserviert Interface-Local
| |
| | |
| x2
| |
| | |
| Link-local
| |
| | |
| x3
| |
| x4
| |
| | |
| Reserviert Admin-Local
| |
| | |
| x5
| |
| | |
| Site-Local
| |
| | |
| x6- x7
| |
| | |
| Nutzerdefiniert
| |
| | |
| x8
| |
| | |
| Organization-Local
| |
| | |
| x9- xd
| |
| | |
| Nutzerdefiniert
| |
| | |
| xe xf
| |
| | |
| Global 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@lynx :~# 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@lynx :~# ip link set up dev eth
| |
| | |
| Von den zahlreichen Paketen die von Wireshark mitgeschnitten wurden suchen wir uns eines vom Typ MLDv2 aus. Es sollte dem in Abbildung 4.15 gezeigten ähneln.
| |
| | |
| 4 Die Hosts Abbildung 4.15
| |
| 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
| |
| | |
| 4.5 Multicast Abbildung 4.16
| |
| 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
| |
| | |
| 4 Die Hosts Abbildung 4.17
| |
| 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
| |
| | |
| 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
| |
| | |
| Q
| |
| | |
| 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
| |
| | |
| Das Ergebnis sollte der Abbildung 4.18 ähnlich sehen.
| |
| | |
| 4 Die Hosts Abbildung 4.18
| |
| Neighbor Solicitation mittels Linklayer-Multicast
| |
| | |
| Abbildung 4.19
| |
| 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
| |
|
| |
|
|
| |
|
| [[Kategorie:IPv6/Host]] | | [[Kategorie:IPv6/Host]] |
| | </noinclude> |