IPv6/Host/Neighbor Cache: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
| Zeile 2: | Zeile 2: | ||
== Beschreibung == | == Beschreibung == | ||
[[File:ipv6Abbildung4.5.png|mini|400px]] | [[File:ipv6Abbildung4.5.png|mini|400px]] | ||
; Nodes am internen Link | ; Nodes am internen Link | ||
| Zeile 8: | Zeile 7: | ||
* Linux Host | * Linux Host | ||
* Windows Host | * Windows Host | ||
; Neighbor Discovery Protocol | ; Neighbor Discovery Protocol | ||
Dank der Link-local Addresses waren die Nodes in der Lage miteinander auf dem internen Link zu kommunizieren | 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 | * Wir haben dies mit diversen Echo Requests bereits ausprobiert | ||
; Das heißt, die Nodes waren in der Lage die Link-local Addresses ihrer Nachbarn zu gültigen Link-layer Addresses aufzulösen | ; 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 | * 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|RFC 4861]] | * Zuständig für die Auflösung von IPv6-Adressen zu Link-layer Addresses ist das Neighbor Discovery Protocol (NDP), spezifiziert in [[RFC/4861|RFC 4861]] | ||
* NDP wird über ICMPv6 transportiert | * NDP wird über ICMPv6 transportiert | ||
* Damit ist es von IPv6 abhängig, wenn es IPv6-Adressen auflösen soll | * 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 | * Wie und warum das dennoch funktioniert, werden wir uns gleich anschauen | ||
* Vorher machen wir uns aber noch mit den Neighbor Caches vertraut | * 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 | * Jeder Node betreibt einen Neighbor Cache in dem er die Ergebnisse der Link-layerAdressauflösungen zwischenspeichert | ||
; Übrigens | ; Übrigens | ||
Unter IPv4 haben wir für die Auflösung noch ARP benutzt, dessen Ergebnisse in der ARP-Tabelle zwischengespeichert wurden | Unter IPv4 haben wir für die Auflösung noch ARP benutzt, dessen Ergebnisse in der ARP-Tabelle zwischengespeichert wurden | ||
; Hinweis | ; Hinweis | ||
Die Einträge in den Neighbor Caches sind je nach Betriebssystem und Zustand unterschiedlich lange gültig | Die Einträge in den Neighbor Caches sind je nach Betriebssystem und Zustand unterschiedlich lange gültig | ||
* Im Normalfall sind sie sehr kurzlebig | * Im Normalfall sind sie sehr kurzlebig | ||
* Wir brauchen für die folgenden Experimente deshalb mitunter mehrere Anläufe | * 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 | * 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 | * Manchmal ist es daher vorteilhaft, das nächste Kommando schon in der Zwischenablage bereit zu halten, um schneller reagieren zu können | ||
== Neighbor Cache Windows == | == Neighbor Cache Windows == | ||
Wir wechseln zur Maschine felis und öffnen ein Terminal, zum Beispiel mit der bereits bekannten Methode Windows-Taste+R und cmd | 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 | * Um sicher zu gehen, dass sich Einträge im Neighbor | ||
Die Hosts Cache befinden werden, kommunizieren wir mit einem anderen Node auf dem Link | 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 | * Ein Echo Request an die Link-local Address von lynx bietet sich da an | ||
C:\Users\user> ping -n3 fe8::2:ff:fe6:d1e %12 | C:\Users\user> ping -n3 fe8::2:ff:fe6:d1e %12 | ||
Pinging fe8::2:ff:fe6:d1e %12 with 32 bytes of data : | Pinging fe8::2:ff:fe6:d1e %12 with 32 bytes of data : | ||
| Zeile 44: | Zeile 43: | ||
Packets : Sent = 3 , Received = 3, Lost = ( % loss ) , | Packets : Sent = 3 , Received = 3, Lost = ( % loss ) , | ||
Sobald eine Antwort eintrifft, können wir den Vorgang abbrechen und uns den Neighbor Cache ausgeben lassen | 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 | Das Kommando dazu geben wir unmittelbar nach dem letzten Echo Request ein | ||
| Zeile 53: | Zeile 52: | ||
ff 2 ::1 | ff 2 ::1 | ||
ff 2 ::1: ff6 : d1e | ff 2 ::1: ff6 : d1e | ||
'''ipv6 show neighbors''' | |||
Physical Address | Physical Address | ||
----------------- - -6 - d -1 e | ----------------- - -6 - d -1 e | ||
33 -33 - - - - 1 | 33 -33 - - - - 1 | ||
33 -33 - ff -6 - d -1 e | 33 -33 - ff -6 - d -1 e | ||
Type | Type | ||
--------Reachable | --------Reachable | ||
| Zeile 66: | Zeile 65: | ||
Permanent | Permanent | ||
Die IPv6-Adresse fe8 ::2 :ff:fe6 :d1e wurde korrekt zur Link-layer Address - - -6 - d-1e aufgelöst | 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 | * 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: | Nach circa 20 Sekunden lassen wir uns den Neighbor Cache ein weiteres Mal ausgeben: | ||
| Zeile 77: | Zeile 76: | ||
ff 2 ::1: ff6 : d1e | ff 2 ::1: ff6 : d1e | ||
ipv6 show neighbors | |||
Physical Address | Physical Address | ||
----------------- - -6 - d -1 e | ----------------- - -6 - d -1 e | ||
33 -33 - - - - 1 | 33 -33 - - - - 1 | ||
33 -33 - ff -6 - d -1 e | 33 -33 - ff -6 - d -1 e | ||
Type | Type | ||
--------Stale | --------Stale | ||
| Zeile 88: | Zeile 87: | ||
Permanent | Permanent | ||
Der Eintrag für die Adresse fe8 ::2 :ff:fe6 :d1e hat seinen Zustand zwischenzeitlich auf Stale gewechselt | 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 | * Die Nachbarn am Link können offensichtlich verschiedene Zustände haben | ||
== Neighbor Cache Linux == | == Neighbor Cache Linux == | ||
Die Zustände werden wir in einem weiteren Experiment, diesmal von lynx aus, untersuchen | 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 | * Wir verschicken Echo Requests an fuzzball, werden uns aber bei Eingabe der Adresse im letzten Zeichen vertippen | ||
* Die Echo Requests gehen an die Adresse fe8 ::219:83ff:fe 9:17db | * Die Echo Requests gehen an die Adresse fe8 ::219:83ff:fe 9:17db | ||
* Den Vorgang brechen wir vorerst nicht ab | * Den Vorgang brechen wir vorerst nicht ab | ||
user@lynx :~ | user@lynx :~ ping6 fe8 ::219:83 ff : fe 9 :17 db % eth | ||
PING 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 | ( fe8 ::219:83 ff : fe 9 :17 db ) 56 data bytes | ||
| Zeile 106: | Zeile 105: | ||
packet loss , time 47182 ms | 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 | 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 | * Unter Linux steht uns dafür das Kommando ip neighbor show zur Verfügung | ||
user@lynx :~ | user@lynx :~ ip neighbor show | ||
fe8 ::219:83 ff : fe 9 :17 db dev eth | fe8 ::219:83 ff : fe 9 :17 db dev eth | ||
| Zeile 114: | Zeile 113: | ||
INCOMPLETE | INCOMPLETE | ||
Wir lernen mit Incomplete einen weiteren Zustand kennen | 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 | 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 :~ | user@lynx :~ ip neighbor show fe8 ::219:83 ff : fe 9 :17 db dev eth | ||
FAILED | FAILED | ||
Sofern wir uns nicht zu viel Zeit gelassen haben, sehen wir noch den Zustand Failed bevor der Eintrag aus dem Neighbor Cache verschwindet | 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 | * 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 | ||
== Zustände der Einträge == | == Zustände der Einträge == | ||
| Zeile 130: | Zeile 129: | ||
! Zustand !! Beschreibung | ! Zustand !! Beschreibung | ||
|- | |- | ||
| Incomplete || Es findet gerade eine Adressauflösung statt | | Incomplete || Es findet gerade eine Adressauflösung statt | ||
* Diese konnte aber noch nicht erfolgreich beendet werden | * Diese konnte aber noch nicht erfolgreich beendet werden | ||
|- | |- | ||
| Reachable || Der zugehörige Nachbar gilt als erreichbar | | Reachable || Der zugehörige Nachbar gilt als erreichbar | ||
* Entweder findet gerade eine Kommunikation mit ihm statt oder eine solche ist erst wenige Sekunden her | * Entweder findet gerade eine Kommunikation mit ihm statt oder eine solche ist erst wenige Sekunden her | ||
|- | |- | ||
| Stale || Die Erreichbarkeit des zugehörigen Nachbarn ist unbekannt | | Stale || Die Erreichbarkeit des zugehörigen Nachbarn ist unbekannt | ||
* Es fand kürzlich eine Kommunikation mit ihm statt | * Es fand kürzlich eine Kommunikation mit ihm statt | ||
* Solange keine weitere Kommunikation beabsichtigt ist, sollte auf eine erneute Adressauflösung verzichtet werden | * Solange keine weitere Kommunikation beabsichtigt ist, sollte auf eine erneute Adressauflösung verzichtet werden | ||
|- | |- | ||
| Delay || Der zugehörige Nachbar gilt nicht als erreichbar | | Delay || Der zugehörige Nachbar gilt nicht als erreichbar | ||
* Es wurde aber wieder eine Kommunikation mit ihm gestartet | * 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 | * 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 | | Probe || Der zugehörige Nachbar gilt nicht als erreichbar | ||
* Seine Erreichbarkeit wird gerade aktiv geprüft | * Seine Erreichbarkeit wird gerade aktiv geprüft | ||
* Sollte die Prüfung fehlschlagen, wird der Eintrag entfernt | * Sollte die Prüfung fehlschlagen, wird der Eintrag entfernt | ||
|} | |} | ||
== Adressauflösung mitschneiden == | == Adressauflösung mitschneiden == | ||
Dass die Neighbor Caches funktionieren haben wir gerade gesehen | 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 | * 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 | * 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 | 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 | * 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 | * 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 | 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: | Um eine Adressauflösung zu erzwingen versenden wir wieder Echo Requests: | ||
user@fuzzball :~ | user@fuzzball :~ ping6 -c 3 fe8 ::2 : ff : fe6 : d1e % eth1 | ||
PING fe8 ::2 : ff : fe6 : d1e % eth1 ( fe8 ::2 : ff : fe6 : d1e ) ' | PING fe8 ::2 : ff : fe6 : d1e % eth1 ( fe8 ::2 : ff : fe6 : d1e ) ' | ||
56 data bytes | 56 data bytes | ||
| Zeile 171: | Zeile 170: | ||
=== Neighbor Solicitation === | === Neighbor Solicitation === | ||
: Abbildung 4.6 | : Abbildung 4.6 | ||
* Hat der betroffene Node wie gewünscht geantwortet stoppen wir die Aufzeichnung und schauen uns die Ergebnisse in Wireshark an | * 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) | * Das erste Paket von Interesse ist eine Neighbor Solicitation genannte Nachricht (siehe Abbildung 4.6) | ||
Da das Neighbor Discovery Protocol ein in ICMPv6 eingebettetes Protokoll ist, fängt der spannende Teil mit einem ICMPv6-Header an | 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 | * Der Nachrichtentyp hat die Nummer 135 und den Code 0 | ||
* Neben der Checksum und reservierten Bytes existiert ein weiteres Feld, die Target Address | * 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 | * 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 | * 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 | * 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 | * 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 | * 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 | * 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 | 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 | * Sie wird wie in Abbildung 4.7 dargestellt berechnet | ||
=== Solicited Node Multicast Address === | === Solicited Node Multicast Address === | ||
| Zeile 203: | Zeile 202: | ||
; Abbildung 4.8 - Neighbor Advertisement | ; Abbildung 4.8 - Neighbor Advertisement | ||
zugestellt werden | zugestellt werden | ||
* Wie genau das funktioniert werden wir in Abschnitt 4.5 Multicast lernen | * Wie genau das funktioniert werden wir in Abschnitt 4.5 Multicast lernen | ||
* Vorerst werden wir uns damit begnügen, dass es irgendwie funktioniert | * Vorerst werden wir uns damit begnügen, dass es irgendwie funktioniert | ||
=== Neighbor Advertisement === | === Neighbor Advertisement === | ||
Natürlich antwortet der angesprochene Node kurz darauf | Natürlich antwortet der angesprochene Node kurz darauf | ||
* Er tut dies mit einem sogenannten Neighbor Advertisement | * Er tut dies mit einem sogenannten Neighbor Advertisement | ||
Wieder schauen wir in das Paket, ähnlich Abbildung 4.8, hinein | 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 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 | * Die Target Address gibt weiterhin an, für welche IPv6-Adresse eine Auflösung stattfindet | ||
* Neu ist das Feld Flags, das wir neugierig aufklappen | * Neu ist das Feld Flags, das wir neugierig aufklappen | ||
Wireshark erläutert die Flags eher sparsam, darum hier ihre Bedeutung | Wireshark erläutert die Flags eher sparsam, darum hier ihre Bedeutung | ||
| Zeile 221: | Zeile 220: | ||
! Flag !! Beschreibung | ! Flag !! Beschreibung | ||
|- | |- | ||
| Router || Ein gesetztes Flag zeigt an, das es sich bei der Quelle um einen Router handelt | | 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 | * Das ist wichtig zu wissen, da ein Router an einem Link seine Rolle aufgeben kann | ||
* Er wird dann zu einem normalen Host | * Er wird dann zu einem normalen Host | ||
* Diese Änderung zeigt er durch das Nichtsetzen des Flags an | * 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 | | 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 | * Der Empfänger bekommt damit die Erreichbarkeit eines Nodes bestätigt | ||
* Mit der Information kann er seinen Neighbor Cache aktualisieren und Einträge im Zustand Stale oder Probe zurück auf Reachable setzen | * Mit der 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 | | 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 gesetzt, werden existierende Einträge zu der angegeben Adresse überschrieben | ||
* Ist es nicht gesetzt, darf es lediglich einen unvollständigen Eintrag ergänzen | * 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 | * 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 | * 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 | Die letzte Information im Paket ist die Source Link-layer Address, der eigentliche Grund der Anfrage | ||
; Übrigens | ; Übrigens | ||
An diesem Beispiel zeigt sich die Flexibilität von IPv6 | An diesem Beispiel zeigt sich die Flexibilität von IPv6 | ||
* Die ICMPv6-Optionen werden stets zusammen mit einer Längenangabe versendet | * 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 | * 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 | ||
; Ablauf einer typischen Adressauflösung | ; Ablauf einer typischen Adressauflösung | ||
Der gesamte Prozess der Adressauflösung zwischen zwei Nodes auf dem Link besteht aus nur zwei Paketen | 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) | * 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 | * Gegenüber Broadcast stellt das eine deutliche Einsparung dar, gerade an Links mit vielen Nodes | ||
<noinclude> | <noinclude> | ||
| Zeile 260: | Zeile 259: | ||
== IPv6 - Neighbor Cache == | == IPv6 - Neighbor Cache == | ||
Bei IPv6 wird die MAC-Adressenanfrage nicht wie bei IPv4 über das ARP-Protokoll realisiert, sondern über das Neighbor Discovery Protokoll (ein spezifisches ICMPv6-Protokoll). Dementsprechend werden die angefragten MAC-Adresse-IP-Adresse-Zuordnungen in den Neighbor-Cache abgelegt | Bei IPv6 wird die MAC-Adressenanfrage nicht wie bei IPv4 über das ARP-Protokoll realisiert, sondern über das Neighbor Discovery Protokoll (ein spezifisches ICMPv6-Protokoll). Dementsprechend werden die angefragten MAC-Adresse-IP-Adresse-Zuordnungen in den Neighbor-Cache abgelegt | ||
Die Abfrage dieses Caches erfolgt über den Befehl: | Die Abfrage dieses Caches erfolgt über den Befehl: | ||
ip -6 neigh | |||
Um eine MAC-Adressanfrage manuell zu initiieren kann das tool ndisc6 (neighbor discovery) verwendet werden | Um eine MAC-Adressanfrage manuell zu initiieren kann das tool ndisc6 (neighbor discovery) verwendet werden | ||
ndisc6 <IPv6-Zieladresse> <Quellinterface> | |||
ndisc6 <2001:638:408:200::1> <eth1> | |||
== IPv6-Neighbour Cache == | == IPv6-Neighbour Cache == | ||
Der Befehl <samp>show ipv6-neighbour-cache</samp> zeigt den aktuellen Neighbour Cache an | Der Befehl <samp>show ipv6-neighbour-cache</samp> zeigt den aktuellen Neighbour Cache an | ||
Die Ausgabe ist folgendermaßen formatiert: | Die Ausgabe ist folgendermaßen formatiert: | ||
| Zeile 283: | Zeile 282: | ||
|- | |- | ||
|IPv6-Adresse | |IPv6-Adresse | ||
|Die IPv6-Adresse des benachbarten Gerätes | |Die IPv6-Adresse des benachbarten Gerätes | ||
|- | |- | ||
|Interface | |Interface | ||
|Das Interface, über das der Nachbar erreichbar ist | |Das Interface, über das der Nachbar erreichbar ist | ||
|- | |- | ||
|MAC-Adresse | |MAC-Adresse | ||
|Die MAC-Adresse des Nachbarn | |Die MAC-Adresse des Nachbarn | ||
|- | |- | ||
|Switchport | |Switchport | ||
|Der Switchport, auf dem der Nachbar festgestellt wurde | |Der Switchport, auf dem der Nachbar festgestellt wurde | ||
|- | |- | ||
|Gerätetyp | |Gerätetyp | ||
|Gerätetyp des Nachbarn (Host oder Router) | |Gerätetyp des Nachbarn (Host oder Router) | ||
|- | |- | ||
|Status | |Status | ||
|Der Status der Verbindung zum benachbarten Gerät | |Der Status der Verbindung zum benachbarten Gerät | ||
|- | |- | ||
|Quelle | |Quelle | ||
|Die IPv6-Adresse, über die der Nachbar entdeckt wurde | |Die IPv6-Adresse, über die der Nachbar entdeckt wurde | ||
|} | |} | ||
Mögliche Einträge sind: | Mögliche Einträge sind: | ||
* INCOMPLETE – Die Auflösung der Adresse ist noch im Gange und die Link Layer Adresse des Nachbarn wurde noch nicht bestimmt | * INCOMPLETE – Die Auflösung der Adresse ist noch im Gange und die Link Layer Adresse des Nachbarn wurde noch nicht bestimmt | ||
* REACHABLE – Der Nachbar ist in den letzten zehn Sekunden erreichbar gewesen | * REACHABLE – Der Nachbar ist in den letzten zehn Sekunden erreichbar gewesen | ||
* STALE – Der Nachbar ist nicht länger als REACHABLE qualifiziert, aber eine Aktualisierung wird erst durchgeführt, wenn versucht wird ihn zu erreichen | * STALE – Der Nachbar ist nicht länger als REACHABLE qualifiziert, aber eine Aktualisierung wird erst durchgeführt, wenn versucht wird ihn zu erreichen | ||
* DELAY – Der Nachbar ist nicht länger als REACHABLE qualifiziert, aber es wurden vor kurzem Daten an ihn gesendet und auf Verifikation durch andere Protokolle gewartet | * DELAY – Der Nachbar ist nicht länger als REACHABLE qualifiziert, aber es wurden vor kurzem Daten an ihn gesendet und auf Verifikation durch andere Protokolle gewartet | ||
* PROBE – Der Nachbar ist nicht länger als REACHABLE qualifiziert. Es werden Neighbour Solicitation Probes an ihn gesendet um die Erreichbarkeit zu bestätigen | * PROBE – Der Nachbar ist nicht länger als REACHABLE qualifiziert. Es werden Neighbour Solicitation Probes an ihn gesendet um die Erreichbarkeit zu bestätigen | ||
[[Kategorie:IPv6/Host]] | [[Kategorie:IPv6/Host]] | ||
</noinclude> | </noinclude> | ||
Version vom 14. Januar 2024, 23:39 Uhr
topic - Kurzbeschreibung
Beschreibung
- Nodes am internen Link
- Router
- Linux Host
- Windows Host
- 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
- 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
- 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
- Hinweis
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
Neighbor Cache Windows
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
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
C:\Users\user> ping -n3 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
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:
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 Linux
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 Adresse fe8 ::219:83ff:fe 9:17db
- Den Vorgang brechen wir vorerst nicht ab
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
Zustände der Einträge
Den anderen Zuständen hingegen sind klare Bedeutungen zugeordnet:
| Zustand | Beschreibung |
|---|---|
| Incomplete | Es findet gerade eine Adressauflösung statt
|
| Reachable | Der zugehörige Nachbar gilt als erreichbar
|
| Stale | Die Erreichbarkeit des zugehörigen Nachbarn ist unbekannt
|
| Delay | Der zugehörige Nachbar gilt nicht als erreichbar
|
| Probe | Der zugehörige Nachbar gilt nicht als erreichbar
|
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:
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
Neighbor Solicitation
- Abbildung 4.6
- 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)
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
- 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
| Flag | Beschreibung |
|---|---|
| Router | Ein gesetztes Flag zeigt an, das es sich bei der Quelle um einen Router handelt
|
| Solicited | Mit diesem Flag wird darauf hingewiesen, dass das Neighbor Advertisement die Folge einer vorhergehen Neighbor Solicitation ist
|
| Override | Mit dem Override-Flag kann die Quelle festlegen, was das Ziel des Neighbor Advertisements in den Neighbor Cache eintragen soll
|
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
- Ablauf einer typischen Adressauflösung
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
Anhang
Siehe auch
Links
Weblinks
TMP
IPv6 - Neighbor Cache
Bei IPv6 wird die MAC-Adressenanfrage nicht wie bei IPv4 über das ARP-Protokoll realisiert, sondern über das Neighbor Discovery Protokoll (ein spezifisches ICMPv6-Protokoll). Dementsprechend werden die angefragten MAC-Adresse-IP-Adresse-Zuordnungen in den Neighbor-Cache abgelegt
Die Abfrage dieses Caches erfolgt über den Befehl:
ip -6 neigh
Um eine MAC-Adressanfrage manuell zu initiieren kann das tool ndisc6 (neighbor discovery) verwendet werden
ndisc6 <IPv6-Zieladresse> <Quellinterface>
ndisc6 <2001:638:408:200::1> <eth1>
IPv6-Neighbour Cache
Der Befehl show ipv6-neighbour-cache zeigt den aktuellen Neighbour Cache an
Die Ausgabe ist folgendermaßen formatiert:
<IPv6-Adresse> iface <Interface> lladdr <MAC-Adresse> (<Switchport>) <Gerätetyp> <Status> src <Quelle>
| Ausgabe | Erläuterung |
|---|---|
| IPv6-Adresse | Die IPv6-Adresse des benachbarten Gerätes |
| Interface | Das Interface, über das der Nachbar erreichbar ist |
| MAC-Adresse | Die MAC-Adresse des Nachbarn |
| Switchport | Der Switchport, auf dem der Nachbar festgestellt wurde |
| Gerätetyp | Gerätetyp des Nachbarn (Host oder Router) |
| Status | Der Status der Verbindung zum benachbarten Gerät |
| Quelle | Die IPv6-Adresse, über die der Nachbar entdeckt wurde |
Mögliche Einträge sind:
- INCOMPLETE – Die Auflösung der Adresse ist noch im Gange und die Link Layer Adresse des Nachbarn wurde noch nicht bestimmt
- REACHABLE – Der Nachbar ist in den letzten zehn Sekunden erreichbar gewesen
- STALE – Der Nachbar ist nicht länger als REACHABLE qualifiziert, aber eine Aktualisierung wird erst durchgeführt, wenn versucht wird ihn zu erreichen
- DELAY – Der Nachbar ist nicht länger als REACHABLE qualifiziert, aber es wurden vor kurzem Daten an ihn gesendet und auf Verifikation durch andere Protokolle gewartet
- PROBE – Der Nachbar ist nicht länger als REACHABLE qualifiziert. Es werden Neighbour Solicitation Probes an ihn gesendet um die Erreichbarkeit zu bestätigen