|
|
| (135 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| == Neighbor Cache ==
| | '''IPv6/Host/Neighbor Cache''' |
| 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.
| | == Beschreibung == |
| * Wir haben dies mit diversen Echo Requests bereits ausprobiert. | | [[File:ipv6Abbildung4.5.png|mini|400px|Nodes am internen Link]] |
| | * [[Router]] |
| | * [[Linux]] |
| | * [[Windows]] |
|
| |
|
| === Neighbor Cache fuzzball ===
| | ; Neighbor Discovery Protocol (NDP) |
| lynx internal eth1
| | Über die Link-local Addresses können Nodes auf dem internen Link kommunizieren |
| | * Dies kann mit [[Ping#Echo Requests|ping]] getestet werden |
|
| |
|
| eth0
| | ; Link-local Addresses zu Link-layer Addresses auflösen |
| | Nodes sind in der Lage die Link-local Addresses ihrer Nachbarn zu gültigen Link-layer Addresses aufzulösen |
|
| |
|
| Abbildung 4.5
| | ; Neighbor Discovery Protocol (NDP) |
| Link internal mit fuzzball, lynx und felis | | Zuständig für die Auflösung von IPv6-Adressen zu Link-layer Addresses ist das Neighbor Discovery Protocol (NDP) |
| | * [[RFC/4861|RFC 4861]] |
|
| |
|
| felis
| | ; [[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 |
|
| |
|
| LAN1
| | Unter IPv4 wird für die Auflösung [[ARP]] genutzt |
| | * Ergebnisse in ARP-Tabelle zwischengespeichert |
|
| |
|
| Das heißt, die Nodes waren in der Lage die Link-local Addresses ihrer Nachbarn zu gültigen Link-layer Addresses aufzulösen.
| | ; Gültigkeit des Neighbor Caches |
| * Unser Link internal ist ein virtuelles Ethernet, die Link-layer Addresses entsprechen in unserem Netz deshalb den bei Ethernet gebräuchlichen MAC-Adressen.
| | Einträge im Neighbor Caches sind je nach Betriebssystem und Zustand unterschiedlich lange gültig |
| * 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].
| | * Im Normalfall sind sie recht kurzlebig |
| * NDP wird über ICMPv6 transportiert.
| | * Daher sind für die folgenden Experimente mitunter mehrere Anläufe notwendig |
| * 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
| | 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 bereitzuhalten, um schneller reagieren zu können |
|
| |
|
| Wir wechseln zur Maschine felis und öffnen ein Terminal, zum Beispiel mit der bereits bekannten Methode Windows-Taste+R und cmd.
| | == Zustände der Einträge == |
| * Um sicher zu gehen, dass sich Einträge im Neighbor | | {| class="wikitable big options" |
| | ! Zustand !! Beschreibung |
| | |- |
| | | Incomplete || Adressauflösung findet gerade statt |
| | * Diese konnte aber noch nicht erfolgreich beendet werden |
| | |- |
| | | Reachable || Nachbar gilt als erreichbar |
| | * Entweder findet gerade eine Kommunikation mit ihm statt oder eine solche ist erst wenige Sekunden her |
| | |- |
| | | Stale || Erreichbarkeit 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 || 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 || Nachbar gilt nicht als erreichbar |
| | * Seine Erreichbarkeit wird gerade aktiv geprüft |
| | * Sollte die Prüfung fehlschlagen, wird der Eintrag entfernt |
| | |} |
|
| |
|
| === Neighbor Cache (Windows 8) === | | == Adressauflösung == |
| | ; Adressauflösung mitschneiden |
| | * Neighbor Caches funktioniert |
| | * Echo Request zeigt, dass die Auflösung von IPv6-Adressen und Link-layer Addresses funktioniert |
|
| |
|
| 4 Die Hosts Cache befinden werden, kommunizieren wir mit einem anderen Node auf dem Link.
| | === Ablauf === |
| * Ein Echo Request an die Link-local Address von lynx bietet sich da an. | | ; Leerer Neighbor Cache |
| | Dazu suchen wir uns einen Node aus, der gerade einen leeren Neighbor Cache hat, zum Beispiel ''router'' |
| | * 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 |
|
| |
|
| Q
| | Wenn der Node seine IPv6-Nachbarn schließlich vergessen hat, starten wir Wireshark auf dem entsprechenden Interface (hier:eth1) |
| | <syntaxhighlight lang="bash" highlight="1" line copy> |
| | ping -c3 fe80::200:ff:fe60:d1e%eth1 |
| | </syntaxhighlight> |
| | <syntaxhighlight lang="bash" highlight="" line> |
| | PING fe80::200:ff:fe60:d1e%eth1 (fe80::200:ff:fe60:d1e) 56 data bytes |
| | 64 bytes from fe80::200:ff:fe60:d1e: icmp_seq=1 ttl=64 time=3.75 ms |
| | 3 packets transmitted, 3 received, 0% packet loss, time 2005 ms |
| | </syntaxhighlight> |
|
| |
|
| C :\ Users \ user > ping -n 3 fe8 ::2 : ff : fe6 : d1e %12
| | === Neighbor Solicitation === |
| Pinging fe8 ::2 : ff : fe6 : d1e %12 with 32 bytes of data :
| | [[Neighbor Solicitation]] |
| Reply from fe8 ::2 : ff : fe6 : d1e %12: time <1 ms
| | <!-- |
| Packets : Sent = 3 , Received = 3, Lost =
| | [[Router Solicitation]] |
| ( % loss ) ,
| | --> |
|
| |
|
| Sobald eine Antwort eintrifft, können wir den Vorgang abbrechen und uns den Neighbor Cache ausgeben lassen.
| | === Solicited Node Multicast Address === |
| * Das Kommando dazu geben wir unmittelbar nach dem letzten Echo Request ein: | | [[File:ipv6SolicitedNodeMulticastAddress.png|mini|400px|Solicited Node Multicast Address]] |
| Q
| | Pakete an die Solicited Node Multicast Address eines Nodes können auch bei unbekannter Link-layer Address an diesen zugestellt werden |
| | * siehe [[IPv6/Multicast]] |
|
| |
|
| Q
| | ; Solicited Node Multicast Address |
| | [[File:ipv6NeighborAdvertisement.png|mini|400px|Neighbor Advertisement]] |
|
| |
|
| C :\ Users \ user > netsh interface
| | === Neighbor Advertisement === |
| Interface 12: LAN1
| | [[Neighbor Advertisement]] |
| Internet Address
| | <noinclude> |
| ---------------------------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.
| | == Verwaltung == |
| * Der Zustand des Eintrages ist Reachable, das heißt, der zugehörige Node gilt auf dem Link als erreichbar.
| | {| class="wikitable options gnu big" |
| * Nach circa 20 Sekunden lassen wir uns den Neighbor Cache ein weiteres Mal ausgeben:
| | |- |
| Q
| | ! System !! Beschreibung |
| | |- |
| | | Windows || [[IPv6/Host/Neighbor/Cache/Windows]] |
| | |- |
| | | Linux || [[IPv6/Host/Neighbor/Cache/Linux]] |
| | |} |
|
| |
|
| Q
| | == Anhang == |
| | | === Siehe auch === |
| C :\ Users \ user > netsh interface
| | {{Special:PrefixIndex/{{BASEPAGENAME}}/}} |
| Interface 12: LAN1
| | === Links === |
| Internet Address
| | ==== Weblinks ==== |
| ---------------------------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
| |
|
| |
|
| [[Kategorie:IPv6/Host]] | | [[Kategorie:IPv6/Host]] |
| | </noinclude> |
