|
|
| Zeile 9: |
Zeile 9: |
| ==== Links ==== | | ==== Links ==== |
| ===== Weblinks ===== | | ===== Weblinks ===== |
|
| |
| = TMP =
| |
| == 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.
| |
| * Wir haben dies mit diversen Echo Requests bereits ausprobiert.
| |
|
| |
| == Linux ==
| |
| lynx internal eth1
| |
|
| |
| 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
| |
|
| |
| == Windows ==
| |
| 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
| |
|
| |
|
| [[Kategorie:IPv6/Host]] | | [[Kategorie:IPv6/Host]] |
|
| |
|
| </noinclude> | | </noinclude> |