|
|
| (90 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| '''topic''' - Kurzbeschreibung | | '''IPv6/Host/Neighbor Cache''' |
|
| |
|
| == Beschreibung == | | == Beschreibung == |
| | [[File:ipv6Abbildung4.5.png|mini|400px|Nodes am internen Link]] |
| | * [[Router]] |
| | * [[Linux]] |
| | * [[Windows]] |
|
| |
|
| [[File:ipv6Abbildung4.5.png|mini|400px]]
| | ; Neighbor Discovery Protocol (NDP) |
| ; Nodes am internen Link
| | Über die Link-local Addresses können Nodes auf dem internen Link kommunizieren |
| * Router
| | * Dies kann mit [[Ping#Echo Requests|ping]] getestet werden |
| * 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. | | ; Link-local Addresses zu Link-layer Addresses auflösen |
| * Unser Link internal ist ein virtuelles Ethernet, die Link-layer Addresses entsprechen in unserem Netz deshalb den bei Ethernet gebräuchlichen MAC-Adressen.
| | Nodes sind in der Lage die Link-local Addresses ihrer Nachbarn zu gültigen Link-layer Addresses aufzulösen |
| * 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.
| |
| * 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 | | ; Neighbor Discovery Protocol (NDP) |
| Unter IPv4 haben wir für die Auflösung noch ARP benutzt, dessen Ergebnisse in der ARP-Tabelle zwischengespeichert wurden.
| | Zuständig für die Auflösung von IPv6-Adressen zu Link-layer Addresses ist das Neighbor Discovery Protocol (NDP) |
| | * [[RFC/4861|RFC 4861]] |
|
| |
|
| ; Hinweis | | ; [[NDP]] wird über [[ICMPv6]] transportiert |
| Die Einträge in den Neighbor Caches sind je nach Betriebssystem und Zustand unterschiedlich lange gültig.
| | Damit ist es von IPv6 abhängig, wenn es IPv6-Adressen auflösen soll |
| * Im Normalfall sind sie sehr kurzlebig. | | * Wie und warum das dennoch funktioniert, werden wir uns gleich anschauen |
| * Wir brauchen für die folgenden Experimente deshalb mitunter mehrere Anläufe. | | * Vorher machen wir uns aber noch mit den Neighbor Caches vertraut |
| * Für das Einfangen eines ganz bestimmten Zustands müssen wir zum richtigen Zeitpunkt den Neighbor Cache auslesen.
| | * Jeder Node betreibt einen Neighbor Cache in dem er die Ergebnisse der Link-layerAdressauflösungen zwischenspeichert |
| * Manchmal ist es daher vorteilhaft, das nächste Kommando schon in der Zwischenablage bereit zu halten, um schneller reagieren zu können. | |
|
| |
|
| | Unter IPv4 wird für die Auflösung [[ARP]] genutzt |
| | * Ergebnisse in ARP-Tabelle zwischengespeichert |
|
| |
|
| == Neighbor Cache Windows ==
| | ; Gültigkeit des Neighbor Caches |
| Wir wechseln zur Maschine felis und öffnen ein Terminal, zum Beispiel mit der bereits bekannten Methode Windows-Taste+R und cmd.
| | Einträge im Neighbor Caches sind je nach Betriebssystem und Zustand unterschiedlich lange gültig |
| * Um sicher zu gehen, dass sich Einträge im Neighbor | | * Im Normalfall sind sie recht kurzlebig |
| | * Daher sind für die folgenden Experimente mitunter mehrere Anläufe notwendig |
|
| |
|
| Die Hosts Cache befinden werden, kommunizieren wir mit einem anderen Node auf dem Link.
| | Für das Einfangen eines ganz bestimmten Zustands müssen wir zum richtigen Zeitpunkt den Neighbor Cache auslesen |
| * Ein Echo Request an die Link-local Address von lynx bietet sich da an.
| | * Manchmal ist es daher vorteilhaft, das nächste Kommando schon in der Zwischenablage bereitzuhalten, um schneller reagieren zu können |
| 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 == | | == Zustände der Einträge == |
| Den anderen Zuständen hingegen sind klare Bedeutungen zugeordnet:
| |
| {| class="wikitable big options" | | {| class="wikitable big options" |
| |-
| |
| ! Zustand !! Beschreibung | | ! Zustand !! Beschreibung |
| |- | | |- |
| | Incomplete || Es findet gerade eine Adressauflösung statt. | | | Incomplete || Adressauflösung findet gerade 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 || 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 || Erreichbarkeit 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 || 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 || 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 == |
| Dass die Neighbor Caches funktionieren haben wir gerade gesehen.
| | ; Adressauflösung mitschneiden |
| * Auch wissen wir dank der erfolgreichen Echo Requests, dass die Auflösung von IPv6-Adressen und Link-layer Addresses funktioniert. | | * Neighbor Caches funktioniert |
| * Es ist nun an der Zeit, die Frage nach dem Wie zu beantworten.
| | * Echo Request zeigt, dass die Auflösung von IPv6-Adressen und Link-layer Addresses funktioniert |
|
| |
|
| Dazu suchen wir uns einen Node aus, der gerade einen leeren Neighbor Cache hat, zum Beispiel fuzzball. | | === Ablauf === |
| * Das Kommando zum Anzeigen des Neighbor Caches ist uns aus den vorherigen Experimenten noch bekannt. | | ; Leerer Neighbor Cache |
| * Sollten sich noch gültige Einträge im Neighbor Cache befinden, warten wir noch etwas ab. | | 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. | | 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> |
| Um eine Adressauflösung zu erzwingen versenden wir wieder Echo Requests:
| | ping -c3 fe80::200:ff:fe60:d1e%eth1 |
| user@fuzzball :~ $ ping6 -c 3 fe8 ::2 : ff : fe6 : d1e % eth1
| | </syntaxhighlight> |
| PING fe8 ::2 : ff : fe6 : d1e % eth1 ( fe8 ::2 : ff : fe6 : d1e ) '
| | <syntaxhighlight lang="bash" highlight="" line> |
| 56 data bytes
| | PING fe80::200:ff:fe60:d1e%eth1 (fe80::200:ff:fe60:d1e) 56 data bytes |
| 64 bytes from fe8 ::2 : ff : fe6 : d1e : icmp_seq =1 ttl =64 '
| | 64 bytes from fe80::200:ff:fe60:d1e: icmp_seq=1 ttl=64 time=3.75 ms |
| time =3.75 ms
| | 3 packets transmitted, 3 received, 0% packet loss, time 2005 ms |
| 3 packets transmitted , 3 received , % packet loss , time '
| | </syntaxhighlight> |
| 2 5 ms | |
|
| |
|
| === Neighbor Solicitation === | | === Neighbor Solicitation === |
| : 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).
| | [[Router 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 === | | === 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 | | Pakete an die Solicited Node Multicast Address eines Nodes können auch bei unbekannter Link-layer Address an diesen zugestellt werden |
| | | * siehe [[IPv6/Multicast]] |
| : 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 | | ; Solicited Node Multicast Address |
| | | [[File:ipv6NeighborAdvertisement.png|mini|400px|Neighbor Advertisement]] |
| ; 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 === | | === Neighbor Advertisement === |
| Natürlich antwortet der angesprochene Node kurz darauf.
| | [[Neighbor Advertisement]] |
| * Er tut dies mit einem sogenannten Neighbor Advertisement.
| | <noinclude> |
| | |
| 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
| | == Verwaltung == |
| {| class="wikitable big options" | | {| class="wikitable options gnu big" |
| |-
| |
| ! Flag !! Beschreibung
| |
| |- | | |- |
| | Router || Ein gesetztes Flag zeigt an, das es sich bei der Quelle um einen Router handelt.
| | ! System !! Beschreibung |
| * 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. | | | Windows || [[IPv6/Host/Neighbor/Cache/Windows]] |
| * 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.
| |
| |- | | |- |
| | Override || Mit dem Override-Flag kann die Quelle festlegen, was das Ziel des Neighbor Advertisements in den Neighbor Cache eintragen soll. | | | Linux || [[IPv6/Host/Neighbor/Cache/Linux]] |
| * 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.
| |
|
| |
| ; 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.
| |
|
| |
| <noinclude>
| |
|
| |
|
| == Anhang == | | == Anhang == |
| === Siehe auch === | | === Siehe auch === |
| {{Special:PrefixIndex/{{BASEPAGENAME}}}} | | {{Special:PrefixIndex/{{BASEPAGENAME}}/}} |
| ==== Links ====
| | === Links === |
| ===== Weblinks =====
| | ==== 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 <samp>show ipv6-neighbour-cache</samp> 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>
| |
| | |
| {| class="wikitable big options"
| |
| |+Bestandteile der Konsolenausgabe <samp>show ipv6-neighbour-cache</samp>
| |
| !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.
| |
|
| |
|
| [[Kategorie:IPv6/Host]] | | [[Kategorie:IPv6/Host]] |
| </noinclude> | | </noinclude> |
