Neighbor Discovery Protocol: Unterschied zwischen den Versionen
K Textersetzung - „==== Links ====“ durch „=== Links ===“ |
K Textersetzung - „Proposed Standard“ durch „Proposed Standard“ |
||
(50 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
''' | '''{{BASEPAGENAME}}''' - [[Address Resolution]] mit [[IPv6]] ([[NDP]]) | ||
== Beschreibung == | == Beschreibung == | ||
Nachfolger des [[Address Resolution Protocol]] (ARP) bei [[IPv6]] | Nachfolger des [[Address Resolution Protocol]] (ARP) bei [[IPv6]] | ||
Zeile 13: | Zeile 13: | ||
* Für alle nicht am selben Netzwerk hängenden Knoten wird NDP benutzt, um einen/den [[Router]] zu finden, der die [[Datenpaket|Pakete]] weiterleiten kann | * Für alle nicht am selben Netzwerk hängenden Knoten wird NDP benutzt, um einen/den [[Router]] zu finden, der die [[Datenpaket|Pakete]] weiterleiten kann | ||
=== | === Informationen === | ||
NDP-Knoten verwalten für jedes [[Netzwerkschnittstelle|Interface]] folgende Informationen | |||
* Die Informationen zum Erstellen dieser Listen werden per [[ICMPv6]] (Internet Control Message Protocol Version 6) ausgetauscht | |||
{| class="wikitable big options" | {| class="wikitable big options" | ||
Zeile 36: | Zeile 37: | ||
|} | |} | ||
=== Nachrichtentypen === | |||
; NDP ICMPv6-Nachrichtentypen | |||
== | {| class="wikitable big options col1center" | ||
{| class="wikitable options | |||
|- | |- | ||
! | ! Type !! Bezeichnung | ||
|- | |- | ||
| | | 133 || [[Router Solicitation|Router Solicitation]] | ||
|- | |- | ||
| [[ | | 134 || [[Router Advertisement|Router Advertisement]] | ||
|- | |- | ||
| [[ | | 135 || [[Neighbor Solicitation|Neighbor Solicitation]] | ||
|- | |- | ||
| [[ | | 136 || [[Neighbor Advertisement|Neighbor Advertisement]] | ||
|- | |- | ||
| [[ | | 137 || [[Redirect|Redirect]] | ||
|} | |||
=== Funktionen === | |||
{| class="wikitable options big col1center" | |||
|- | |- | ||
! !! Funktion !! Beschreibung | |||
|- | |- | ||
| [[# | | 1 || [[#Router- und Präfix-Ermittlung|Router- und Präfix-Ermittlung]] || | ||
|- | |- | ||
| [[# | | 2 || [[#Parameterermittlung|Parameterermittlung]] || | ||
|- | |- | ||
| 3 || [[#Adress-Autokonfiguration|Adress-Autokonfiguration]] || | |||
|- | |- | ||
| | | 4 || [[#Bestimmung des nächsten Hops|Bestimmung des nächsten Hops]] || | ||
|- | |- | ||
| | | 5 || [[#Adressauflösung|Adressauflösung]] || | ||
|- | |- | ||
| | | 6 || [[#Erkennung der Nichterreichbarkeit des Nachbarn|Erkennung der Nichterreichbarkeit des Nachbarn]] || | ||
|- | |- | ||
| | | 7 || [[#Erkennung doppelter Adressen|Erkennung doppelter Adressen]] || | ||
|- | |- | ||
| | | 8 || [[#Umleitung|Umleitung]] || | ||
|} | |} | ||
== Router- und Präfix-Ermittlung == | |||
; Router versenden in gewissen Zeitabständen ''Router-Advertisement''-Nachrichten per [[IPv6/Host/Multicast|Multicast]] | ; Router versenden in gewissen Zeitabständen ''Router-Advertisement''-Nachrichten per [[IPv6/Host/Multicast|Multicast]] | ||
Die Informationen in diesen Nachrichten werden verwendet, um die ''Default Router List'' und die ''Prefix List'' zu erstellen | |||
* Nach Ablauf der angegebenen Lebenszeit werden die Einträge wieder aus den Listen gelöscht | * Nach Ablauf der angegebenen Lebenszeit werden die Einträge wieder aus den Listen gelöscht | ||
* Dadurch bleiben nur Router eingetragen, die aktiv sind und ihre Anwesenheit periodisch kundtun | * Dadurch bleiben nur Router eingetragen, die aktiv sind und ihre Anwesenheit periodisch kundtun | ||
Zeile 86: | Zeile 85: | ||
* Dies ist besonders beim Aktivieren eines neuen Interfaces von Vorteil, um mit der Konfiguration nicht warten zu müssen | * Dies ist besonders beim Aktivieren eines neuen Interfaces von Vorteil, um mit der Konfiguration nicht warten zu müssen | ||
== Parameterermittlung == | |||
Mit diesem Mechanismus ermitteln Knoten relevante Parameter für den Link ( | Mit diesem Mechanismus ermitteln Knoten relevante Parameter für den Link (beispielsweise die für den Link verwendete [[Maximum Transmission Unit|MTU]]), an dem sie angeschlossen sind, oder Internet Parameter (wie zum Beispiel den Wert für den [[Time to Live|Hop Limit]]), die für ausgehende Pakete verwendet werden müssen | ||
== Adress-Autokonfiguration == | |||
Mit diesem Verfahren konfigurieren Netzknoten IPv6-Adressen für ihre Interfaces ohne einen [[Dynamic Host Configuration Protocol|DHCP]]-Dienst zu nutzen | Mit diesem Verfahren konfigurieren Netzknoten IPv6-Adressen für ihre Interfaces ohne einen [[Dynamic Host Configuration Protocol|DHCP]]-Dienst zu nutzen | ||
* '''[[SLACC]]''' | |||
=== Bestimmung des nächsten Hops | == Nächste Hop == | ||
; Bestimmung des nächsten Hops | |||
Wenn ein Paket versendet werden soll, wird im ''Destination Cache'' nachgeschaut, ob für dieses Ziel schon ein Eintrag vorhanden ist | |||
* Wenn kein Eintrag existiert, wird anhand der ''Prefix List'' und der ''Default Router List'' der nächste Hop für das Paket ermittelt | * Wenn kein Eintrag existiert, wird anhand der ''Prefix List'' und der ''Default Router List'' der nächste Hop für das Paket ermittelt | ||
* Diese Information wird dann im ''Destination Cache'' gespeichert, um dies nicht jedes Mal ermitteln zu müssen | * Diese Information wird dann im ''Destination Cache'' gespeichert, um dies nicht jedes Mal ermitteln zu müssen | ||
Wenn der neue Eintrag auf einen nichtvorhandenen Eintrag im ''Neighbor Cache'' zeigt, wird dieser ebenfalls erzeugt, als unfertig markiert und die ''Adressauflösung'' (engl. ''Address resolution'') angestoßen | |||
* Das Paket wird in die Queue gestellt und im ''Neighbor Cache'' ein Pointer darauf gesetzt | * Das Paket wird in die Queue gestellt und im ''Neighbor Cache'' ein Pointer darauf gesetzt | ||
== Adressauflösung == | |||
Um die Link-Layer-Adresse eines Knotens zu ermitteln, wird eine ''Neighbor-Solicitation''-Nachricht per IPv6-Multicast an die sog. ''Solicited Nodes''-Adresse des Ziels versendet | |||
* Anzumerken ist, dass auf Link-Layer-Ebene ebenfalls Multicast genutzt wird | * Anzumerken ist, dass auf Link-Layer-Ebene ebenfalls Multicast genutzt wird - jeder IPv6-Knoten muss also auf Link-Layer-Ebene nicht nur auf seine originäre feste MAC-Adresse (beispielsweise [[Ethernet]]) hören, sondern auch auf eine spezifische Multicast-Adresse, die auf seiner IPv6-Adresse beruht | ||
* Im ''Neighbor-Solicitation''-Paket ist dann die vollständige gesuchte IPv6-Adresse in den Nutzdaten enthalten, und nur der Knoten mit der gleichen Adresse antwortet darauf | * Im ''Neighbor-Solicitation''-Paket ist dann die vollständige gesuchte IPv6-Adresse in den Nutzdaten enthalten, und nur der Knoten mit der gleichen Adresse antwortet darauf | ||
* Er verschickt eine ''Neighbor-Advertisement''-Nachricht | * Er verschickt eine ''Neighbor-Advertisement''-Nachricht | ||
Zeile 108: | Zeile 109: | ||
* Wenn ein Eintrag noch unfertig war, kann er nun als erreichbar markiert werden und die Pakete, auf die er verweist, können ausgelöst werden | * Wenn ein Eintrag noch unfertig war, kann er nun als erreichbar markiert werden und die Pakete, auf die er verweist, können ausgelöst werden | ||
;Beispiel | ; Beispiel | ||
Ein IPv6-Host in einem Ethernet-Netzwerk mit einer MAC-Adresse 00:1d:e0:2a:42:42 bekommt über [[EUI-64]] eine link-lokale IPv6-Adresse fe80::021d:e0ff:fe'''2a:4242''' | Ein IPv6-Host in einem Ethernet-Netzwerk mit einer MAC-Adresse 00:1d:e0:2a:42:42 bekommt über [[EUI-64]] eine link-lokale IPv6-Adresse fe80::021d:e0ff:fe'''2a:4242''' | ||
* Die zugehörige Solicitated Node Multicast Adresse, an welche Neighbor-Solicitation-Paket auf IPv6-Ebene versendet werden, lautet FF02::1:FF'''2a:4242''' | * Die zugehörige Solicitated Node Multicast Adresse, an welche Neighbor-Solicitation-Paket auf IPv6-Ebene versendet werden, lautet FF02::1:FF'''2a:4242''' | ||
* Der Host hört auf der Link-Layer-Ebene nicht nur auf seine MAC-Adresse 00:1d:e0:'''2a:42:42''', sondern auch auf die (der Solicitated Node Multicast Adresse zugeordneten) Ethernet-Multicast-Adresse 33:33:'''ff:2a:42:42'''. 33:33 ist dabei der Teil, der ein IPv6 Multicast-Paket im Ethernet kennzeichnet, '''ff:2a:42:42''' identifiziert die eigentliche Gruppe ([[Multicast]]) | * Der Host hört auf der Link-Layer-Ebene nicht nur auf seine MAC-Adresse 00:1d:e0:'''2a:42:42''', sondern auch auf die (der Solicitated Node Multicast Adresse zugeordneten) Ethernet-Multicast-Adresse 33:33:'''ff:2a:42:42'''. 33:33 ist dabei der Teil, der ein IPv6 Multicast-Paket im Ethernet kennzeichnet, '''ff:2a:42:42''' identifiziert die eigentliche Gruppe ([[Multicast]]) | ||
=== Erkennung der Nichterreichbarkeit des Nachbarn | == Erkennung der Nichterreichbarkeit == | ||
; Erkennung der Nichterreichbarkeit des Nachbarn | |||
Um den ''Neighbor Cache'' aktuell zu halten, wird versucht herauszufinden, ob die Einträge darin noch aktuell sind | |||
* Es gibt dabei verschiedene Wege festzustellen, ob ein Knoten nicht aktiv ist | * Es gibt dabei verschiedene Wege festzustellen, ob ein Knoten nicht aktiv ist | ||
* Solange man [[Transmission Control Protocol|TCP]]-Daten oder TCP-Empfangsbestätigungen erhält, weiß man, dass der Knoten noch erreichbar ist | * Solange man [[Transmission Control Protocol|TCP]]-Daten oder TCP-Empfangsbestätigungen erhält, weiß man, dass der Knoten noch erreichbar ist | ||
Wenn ein Eintrag seine Lebenszeit überschreitet, ohne durch Verkehr bestätigt zu werden, wird er als veraltet markiert | |||
* Sobald ein Paket versendet werden will, wird der Eintrag als verzögert markiert und für kurze Zeit versucht, ihn durch Verkehr zu bestätigen | * Sobald ein Paket versendet werden will, wird der Eintrag als verzögert markiert und für kurze Zeit versucht, ihn durch Verkehr zu bestätigen | ||
* Wenn dies nicht passiert, wird erneut eine ''Neighbor-Solicitation''-Nachricht gesendet, um den Knoten aktiv zu testen | * Wenn dies nicht passiert, wird erneut eine ''Neighbor-Solicitation''-Nachricht gesendet, um den Knoten aktiv zu testen | ||
* Wenn er nicht antwortet, wird er aus dem ''Neighbor Cache'' gelöscht | * Wenn er nicht antwortet, wird er aus dem ''Neighbor Cache'' gelöscht | ||
== Erkennung doppelter Adressen == | |||
; Mit diesem Verfahren ermitteln Netzknoten, ob die Adresse, die sie sich bei der Autokonfiguration gegeben haben, eindeutig ist | ; Mit diesem Verfahren ermitteln Netzknoten, ob die Adresse, die sie sich bei der Autokonfiguration gegeben haben, eindeutig ist | ||
== Umleitung == | |||
''Redirect''-Nachrichten | |||
Werden vom Router verschickt, um andere Knoten über einen besseren ersten Hop für eine Zieladresse zu informieren | |||
* Beim Empfangen einer solchen Nachricht wird der ''Destination Cache'' aktualisiert | * Beim Empfangen einer solchen Nachricht wird der ''Destination Cache'' aktualisiert | ||
* Wenn kein passender Eintrag im ''Destination Cache'' gefunden wird, wird ein neuer erstellt | * Wenn kein passender Eintrag im ''Destination Cache'' gefunden wird, wird ein neuer erstellt | ||
Zeile 137: | Zeile 140: | ||
=== Linux === | === Linux === | ||
Unter den meisten [[Linux-Distribution]]en erhält man mit dem [[iproute2]]-Werkzeug Einsicht in den Neighbor Cache | Unter den meisten [[Linux-Distribution]]en erhält man mit dem [[iproute2]]-Werkzeug Einsicht in den Neighbor Cache | ||
<syntaxhighlight lang="bash" highlight="1" line copy> | |||
ip -6 neigh | |||
2001:470:1f0b:2f2:5cad:a77f:aaff:849 dev wlan0 lladdr 00:11:25:32:10:ab REACHABLE | |||
fe80::2a10:7bff:fe65:58a dev wlan0 lladdr 28:10:7b:65:ab:cd router REACHABLE | |||
2001:470:1f0b:2f2::cafe dev wlan0 lladdr 00:11:25:32:10:ab REACHABLE | |||
</syntaxhighlight> | |||
=== Windows === | === Windows === | ||
<syntaxhighlight lang="PowerShell" highlight="1" copy line copy> | |||
netsh interface ipv6 show neighbors level=verbose | |||
</syntaxhighlight> | |||
=== BSD-Unix === | === BSD-Unix === | ||
Auf vielen [[Berkeley Software Distribution|BSD]]-basierten Systemen wie [[FreeBSD]] und [[OpenBSD]] hilft hierbei das Werkzeug ''ndp'', wobei die Optionen '-an' bedeuten, dass ''alle'' Hosts ''numerisch'' angezeigt werden sollen; hier bei FreeBSD 9 (die Kommentare rechts wurden nachträglich eingefügt): | Auf vielen [[Berkeley Software Distribution|BSD]]-basierten Systemen wie [[FreeBSD]] und [[OpenBSD]] hilft hierbei das Werkzeug ''ndp'', wobei die Optionen '-an' bedeuten, dass ''alle'' Hosts ''numerisch'' angezeigt werden sollen; hier bei FreeBSD 9 (die Kommentare rechts wurden nachträglich eingefügt): | ||
<syntaxhighlight lang="bash" highlight="1" line copy> | |||
ndp -an | |||
Neighbor Linklayer Address Netif Expire S Flags | |||
2001:475:abcd:2f2:3189:67c1:b550:9400 c6:ab:27:56:b5:30 em0 14s R R # <-- Ein anderer Rechner im Netzwerk, mit Privacy Extensions | |||
2001:475:abcd:2f2:211:25ff:fe32:10ab 00:11:25:32:10:ab em0 permanent R | |||
fe80::211:25ff:fe32:10ab%em0 00:11:25:32:10:ab em0 permanent R | |||
2001:475:abcd:2f2::cafe 00:11:25:32:10:ab em0 permanent R # <-- Alias-Adresse | |||
fe80::2a10:7bff:fe65:58a%em0 28:10:7b:65:ab:cd em0 23h59m25s S R # <-- Das ist der Router | |||
2001:475:abcd:2f2:5cad:a77f:aaff:849 00:11:25:32:10:ab em0 permanent R | |||
fe80::c6ab:27ff:fe56:b530%em0 c6:ab:27:56:b5:30 em0 24s R R # <-- Derselbe Rechner wie in der ersten Zeile mit seiner link-local address | |||
</syntaxhighlight> | |||
Hierbei ist insbesondere die Spalte ''Expire'' zu beachten | Hierbei ist insbesondere die Spalte ''Expire'' zu beachten | ||
Zeile 165: | Zeile 172: | ||
== Anhang == | == Anhang == | ||
=== Siehe auch === | === Siehe auch === | ||
{{Special:PrefixIndex/IPv6/Neighbor/}} | |||
---- | |||
{{Special:PrefixIndex/Neigh}} | {{Special:PrefixIndex/Neigh}} | ||
=== Dokumentation === | |||
===== RFC ===== | ===== RFC ===== | ||
{| class="wikitable | {| class="wikitable big options col1center col3center" | ||
|- | |- | ||
! RFC !! Titel | ! RFC !! Titel !! Date !! Status | ||
|- | |- | ||
| [https://www.rfc-editor.org/ | | [https://www.rfc-editor.org/info/rfc4861 4861] || Neighbor Discovery for IP Version 6 (IPv6) || 2007 || Draft Standard | ||
|- | |- | ||
| [https://www.rfc-editor.org/ | | [https://www.rfc-editor.org/info/rfc3122 3122] || Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification || 2001 || [[Proposed Standard]] | ||
|} | |} | ||
=== Links === | === Links === | ||
==== Projekt ==== | |||
==== Weblinks ==== | |||
# https://de.wikipedia.org/wiki/Neighbor_Discovery_Protocol | # https://de.wikipedia.org/wiki/Neighbor_Discovery_Protocol | ||
[[Kategorie:IPv6/ICMP]] | [[Kategorie:IPv6/ICMP]] | ||
[[Kategorie:IPv6/ | [[Kategorie:IPv6/Neighbor]] | ||
</noinclude> | </noinclude> |
Aktuelle Version vom 30. Mai 2025, 15:24 Uhr
Neighbor Discovery Protocol - Address Resolution mit IPv6 (NDP)
Beschreibung
Nachfolger des Address Resolution Protocol (ARP) bei IPv6
- IPv6/Adressen in Link-Layer-Adressen auflösen
- Familie Internetprotokolle
- Einsatzfeld Netzwerkadressenzuordnung
- aufbauend auf Netzzugangsschicht
- Verwendung
NDP wird von den am IPv6-Netzwerk beteiligten Knoten benutzt, um die Link-Layer-Adresse von anderen am selben Netzwerk hängenden Knoten ausfindig zu machen und zum Aktualisieren der gecachten Adressen
- Für alle nicht am selben Netzwerk hängenden Knoten wird NDP benutzt, um einen/den Router zu finden, der die Pakete weiterleiten kann
Informationen
NDP-Knoten verwalten für jedes Interface folgende Informationen
- Die Informationen zum Erstellen dieser Listen werden per ICMPv6 (Internet Control Message Protocol Version 6) ausgetauscht
Information | Beschreibung |
---|---|
Neighbor Cache | Adressen, an die etwas gesendet wurde und die sich im selben Netzwerk befinden
|
Destination Cache | Adressen, an die etwas gesendet wurde
|
Prefix List | Präfixe, die auf demselben Netz gültig sind
|
Default Router List | Router, die für das Interface bekannt sind
|
Nachrichtentypen
- NDP ICMPv6-Nachrichtentypen
Type | Bezeichnung |
---|---|
133 | Router Solicitation |
134 | Router Advertisement |
135 | Neighbor Solicitation |
136 | Neighbor Advertisement |
137 | Redirect |
Funktionen
Router- und Präfix-Ermittlung
- Router versenden in gewissen Zeitabständen Router-Advertisement-Nachrichten per Multicast
Die Informationen in diesen Nachrichten werden verwendet, um die Default Router List und die Prefix List zu erstellen
- Nach Ablauf der angegebenen Lebenszeit werden die Einträge wieder aus den Listen gelöscht
- Dadurch bleiben nur Router eingetragen, die aktiv sind und ihre Anwesenheit periodisch kundtun
Um nicht auf das nächste geplante Router Advertisement warten zu müssen, kann ein Knoten per Router-Solicitation-Nachricht an die Router-Multicast-Adresse ein Router Advertisement erzwingen
- Dies ist besonders beim Aktivieren eines neuen Interfaces von Vorteil, um mit der Konfiguration nicht warten zu müssen
Parameterermittlung
Mit diesem Mechanismus ermitteln Knoten relevante Parameter für den Link (beispielsweise die für den Link verwendete MTU), an dem sie angeschlossen sind, oder Internet Parameter (wie zum Beispiel den Wert für den Hop Limit), die für ausgehende Pakete verwendet werden müssen
Adress-Autokonfiguration
Mit diesem Verfahren konfigurieren Netzknoten IPv6-Adressen für ihre Interfaces ohne einen DHCP-Dienst zu nutzen
Nächste Hop
- Bestimmung des nächsten Hops
Wenn ein Paket versendet werden soll, wird im Destination Cache nachgeschaut, ob für dieses Ziel schon ein Eintrag vorhanden ist
- Wenn kein Eintrag existiert, wird anhand der Prefix List und der Default Router List der nächste Hop für das Paket ermittelt
- Diese Information wird dann im Destination Cache gespeichert, um dies nicht jedes Mal ermitteln zu müssen
Wenn der neue Eintrag auf einen nichtvorhandenen Eintrag im Neighbor Cache zeigt, wird dieser ebenfalls erzeugt, als unfertig markiert und die Adressauflösung (engl. Address resolution) angestoßen
- Das Paket wird in die Queue gestellt und im Neighbor Cache ein Pointer darauf gesetzt
Adressauflösung
Um die Link-Layer-Adresse eines Knotens zu ermitteln, wird eine Neighbor-Solicitation-Nachricht per IPv6-Multicast an die sog. Solicited Nodes-Adresse des Ziels versendet
- Anzumerken ist, dass auf Link-Layer-Ebene ebenfalls Multicast genutzt wird - jeder IPv6-Knoten muss also auf Link-Layer-Ebene nicht nur auf seine originäre feste MAC-Adresse (beispielsweise Ethernet) hören, sondern auch auf eine spezifische Multicast-Adresse, die auf seiner IPv6-Adresse beruht
- Im Neighbor-Solicitation-Paket ist dann die vollständige gesuchte IPv6-Adresse in den Nutzdaten enthalten, und nur der Knoten mit der gleichen Adresse antwortet darauf
- Er verschickt eine Neighbor-Advertisement-Nachricht
- Die darin enthaltenen Informationen werden im Neighbor Cache gespeichert
- Wenn ein Eintrag noch unfertig war, kann er nun als erreichbar markiert werden und die Pakete, auf die er verweist, können ausgelöst werden
- Beispiel
Ein IPv6-Host in einem Ethernet-Netzwerk mit einer MAC-Adresse 00:1d:e0:2a:42:42 bekommt über EUI-64 eine link-lokale IPv6-Adresse fe80::021d:e0ff:fe2a:4242
- Die zugehörige Solicitated Node Multicast Adresse, an welche Neighbor-Solicitation-Paket auf IPv6-Ebene versendet werden, lautet FF02::1:FF2a:4242
- Der Host hört auf der Link-Layer-Ebene nicht nur auf seine MAC-Adresse 00:1d:e0:2a:42:42, sondern auch auf die (der Solicitated Node Multicast Adresse zugeordneten) Ethernet-Multicast-Adresse 33:33:ff:2a:42:42. 33:33 ist dabei der Teil, der ein IPv6 Multicast-Paket im Ethernet kennzeichnet, ff:2a:42:42 identifiziert die eigentliche Gruppe (Multicast)
Erkennung der Nichterreichbarkeit
- Erkennung der Nichterreichbarkeit des Nachbarn
Um den Neighbor Cache aktuell zu halten, wird versucht herauszufinden, ob die Einträge darin noch aktuell sind
- Es gibt dabei verschiedene Wege festzustellen, ob ein Knoten nicht aktiv ist
- Solange man TCP-Daten oder TCP-Empfangsbestätigungen erhält, weiß man, dass der Knoten noch erreichbar ist
Wenn ein Eintrag seine Lebenszeit überschreitet, ohne durch Verkehr bestätigt zu werden, wird er als veraltet markiert
- Sobald ein Paket versendet werden will, wird der Eintrag als verzögert markiert und für kurze Zeit versucht, ihn durch Verkehr zu bestätigen
- Wenn dies nicht passiert, wird erneut eine Neighbor-Solicitation-Nachricht gesendet, um den Knoten aktiv zu testen
- Wenn er nicht antwortet, wird er aus dem Neighbor Cache gelöscht
Erkennung doppelter Adressen
- Mit diesem Verfahren ermitteln Netzknoten, ob die Adresse, die sie sich bei der Autokonfiguration gegeben haben, eindeutig ist
Umleitung
Redirect-Nachrichten Werden vom Router verschickt, um andere Knoten über einen besseren ersten Hop für eine Zieladresse zu informieren
- Beim Empfangen einer solchen Nachricht wird der Destination Cache aktualisiert
- Wenn kein passender Eintrag im Destination Cache gefunden wird, wird ein neuer erstellt
Anwendungen
- Implementierungen
Alle IPv6-fähigen Betriebssysteme, die in Ethernet-basierten Netzwerken betrieben werden, sind in der Lage, mittels NDP Adressen aufzulösen
Linux
Unter den meisten Linux-Distributionen erhält man mit dem iproute2-Werkzeug Einsicht in den Neighbor Cache
ip -6 neigh
2001:470:1f0b:2f2:5cad:a77f:aaff:849 dev wlan0 lladdr 00:11:25:32:10:ab REACHABLE
fe80::2a10:7bff:fe65:58a dev wlan0 lladdr 28:10:7b:65:ab:cd router REACHABLE
2001:470:1f0b:2f2::cafe dev wlan0 lladdr 00:11:25:32:10:ab REACHABLE
Windows
netsh interface ipv6 show neighbors level=verbose
BSD-Unix
Auf vielen BSD-basierten Systemen wie FreeBSD und OpenBSD hilft hierbei das Werkzeug ndp, wobei die Optionen '-an' bedeuten, dass alle Hosts numerisch angezeigt werden sollen; hier bei FreeBSD 9 (die Kommentare rechts wurden nachträglich eingefügt):
ndp -an
Neighbor Linklayer Address Netif Expire S Flags
2001:475:abcd:2f2:3189:67c1:b550:9400 c6:ab:27:56:b5:30 em0 14s R R # <-- Ein anderer Rechner im Netzwerk, mit Privacy Extensions
2001:475:abcd:2f2:211:25ff:fe32:10ab 00:11:25:32:10:ab em0 permanent R
fe80::211:25ff:fe32:10ab%em0 00:11:25:32:10:ab em0 permanent R
2001:475:abcd:2f2::cafe 00:11:25:32:10:ab em0 permanent R # <-- Alias-Adresse
fe80::2a10:7bff:fe65:58a%em0 28:10:7b:65:ab:cd em0 23h59m25s S R # <-- Das ist der Router
2001:475:abcd:2f2:5cad:a77f:aaff:849 00:11:25:32:10:ab em0 permanent R
fe80::c6ab:27ff:fe56:b530%em0 c6:ab:27:56:b5:30 em0 24s R R # <-- Derselbe Rechner wie in der ersten Zeile mit seiner link-local address
Hierbei ist insbesondere die Spalte Expire zu beachten
- Sie legt fest, wann ein Namenseintrag als veraltet einzustufen ist
- Die Adressen des Rechners selbst sind dabei permanent, der Router liegt hier bei fast 24 Stunden und die Nachbargeräte im Netzwerk liegen zumeist bei unter einer Minute, bis der Eintrag wieder aufgefrischt wird
Anhang
Siehe auch
Dokumentation
RFC
RFC | Titel | Date | Status |
---|---|---|---|
4861 | Neighbor Discovery for IP Version 6 (IPv6) | 2007 | Draft Standard |
3122 | Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification | 2001 | Proposed Standard |
Links
Projekt
Weblinks