IPv6/Host/Neighbor Cache: Unterschied zwischen den Versionen

Aus Foxwiki
Subpages:
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
 
(102 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== Neighbor Cache ==
'''IPv6 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|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 [[Echo Requests]] getestet werden


eth0
; Link-local Addresses zu Link-layer Addresses auflösen
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|RFC 4861]]


Abbildung 4.5
; [[NDP]] wird über [[ICMPv6]] transportiert
Link internal mit fuzzball, lynx und felis
* 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
Unter IPv4 haben wir für die Auflösung noch ARP benutzt, dessen Ergebnisse in der ARP-Tabelle zwischengespeichert wurden


felis
; Gültigkeit des Neighbor Caches
Einträge im Neighbor Caches sind je nach Betriebssystem und Zustand unterschiedlich lange gültig
* Im Normalfall sind sie recht kurzlebig
* Daher sind für die folgenden Experimente mitunter mehrere Anläufe notwendig


LAN1
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


Das heißt, die Nodes waren in der Lage die Link-local Addresses ihrer Nachbarn zu gültigen Link-layer Addresses aufzulösen.
== Windows ==
* Unser Link internal ist ein virtuelles Ethernet, die Link-layer Addresses entsprechen in unserem Netz deshalb den bei Ethernet gebräuchlichen MAC-Adressen.
[[IPv6/Host/Neighbor Cache/Windows]]
* 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
== Linux ==
[[IPv6/Host/Neighbor Cache/Linux]]


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"
|+ Bedeutungen der Zustände
|-
! Zustand !! Beschreibung
|-
| 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
|-
| 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
|}


=== Neighbor Cache (Windows 8) ===
== 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


4 Die Hosts Cache befinden werden, kommunizieren wir mit einem anderen Node auf dem Link.
; Dazu suchen wir uns einen Node aus, der gerade einen leeren Neighbor Cache hat, zum Beispiel ''router''
* Ein Echo Request an die Link-local Address von lynx bietet sich da an.
* 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


  C :\ Users \ user > ping -n 3 fe8 ::2 : ff : fe6 : d1e %12
Um eine Adressauflösung zu erzwingen versenden wir wieder Echo Requests
  Pinging fe8 ::2 : ff : fe6 : d1e %12 with 32 bytes of data :
  user@router:~ '''ping6 -c3 fe80::200:ff:fe60:d1e%eth1'''
  Reply from fe8 ::2 : ff : fe6 : d1e %12: time <1 ms
  PING fe80::200:ff:fe60:d1e%eth1 (fe80::200:ff:fe60:d1e) 56 data bytes
  Packets : Sent = 3 , Received = 3, Lost =
  64 bytes from fe80::200:ff:fe60:d1e: icmp_seq=1 ttl=64 time=3.75 ms
( % loss ) ,
  3 packets transmitted, 3 received, 0% packet loss, time  2005 ms


Sobald eine Antwort eintrifft, können wir den Vorgang abbrechen und uns den Neighbor Cache ausgeben lassen.
=== Neighbor Solicitation ===
* Das Kommando dazu geben wir unmittelbar nach dem letzten Echo Request ein:
[[Router Solicitation]]
Q


Q
=== Solicited Node Multicast Address ===
[[File:ipv6SolicitedNodeMulticastAddress.png|mini|400px|Solicited Node Multicast Address]]
Pakete an die Solicited Node Multicast Address eines Nodes können auch bei unbekannter Link-layer Address an diesen 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


C :\ Users \ user > netsh interface
; Solicited Node Multicast Address
Interface 12: LAN1
[[File:ipv6NeighborAdvertisement.png|mini|400px|Neighbor Advertisement]]
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.
=== Neighbor Advertisement ===
* Der Zustand des Eintrages ist Reachable, das heißt, der zugehörige Node gilt auf dem Link als erreichbar.
[[Neighbor Advertisement]]
* Nach circa 20 Sekunden lassen wir uns den Neighbor Cache ein weiteres Mal ausgeben:
<noinclude>
Q


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>

Aktuelle Version vom 23. Januar 2024, 12:14 Uhr

IPv6 Neighbor Cache

Beschreibung

Nodes am internen Link
Neighbor Discovery Protocol (NDP)
  • Über die Link-local Addresses können Nodes auf dem internen Link kommunizieren
  • Dies kann mit Echo Requests getestet werden
Link-local Addresses zu Link-layer Addresses auflösen

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

Unter IPv4 haben wir für die Auflösung noch ARP benutzt, dessen Ergebnisse in der ARP-Tabelle zwischengespeichert wurden

Gültigkeit des Neighbor Caches

Einträge im Neighbor Caches sind je nach Betriebssystem und Zustand unterschiedlich lange gültig

  • Im Normalfall sind sie recht kurzlebig
  • Daher sind für die folgenden Experimente mitunter mehrere Anläufe notwendig

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

Windows

IPv6/Host/Neighbor Cache/Windows

Linux

IPv6/Host/Neighbor Cache/Linux

Zustände der Einträge

Bedeutungen der Zustände
Zustand Beschreibung
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
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 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

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@router:~ ping6 -c3 fe80::200:ff:fe60:d1e%eth1
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

Neighbor Solicitation

Router Solicitation

Solicited Node Multicast Address

Solicited Node Multicast Address

Pakete an die Solicited Node Multicast Address eines Nodes können auch bei unbekannter Link-layer Address an diesen 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
Solicited Node Multicast Address
Neighbor Advertisement

Neighbor Advertisement

Neighbor Advertisement


Anhang

Siehe auch

Links

Weblinks
Abgerufen von „https://wiki.foxtom.de/index.php?title=IPv6/Host/Neighbor_Cache&oldid=91734“