Neighbor Solicitation: Unterschied zwischen den Versionen

Version vom 1. Juni 2025, 10:46 Uhr

Neighbor Solicitation

Neighbor Solicitation mitschneiden

Wireshark starten
Aufzeichnung erst starten, wenn der Neighbor Cache von router keinen Eintrag mehr für linux enthält
Senden eines Echo Request vom router an linux, um eine Neighbor Solicitation zu erzwingen

root@router:~# ping6 -c 3 fe80::200:ff:fe60:d1e%eth1
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 time =3.85ms
3 packets transmitted, 3 received, 0% packet loss, time 2007ms

Solicited Node Multicast Address

Ethernet- und IPv6-Header der Neighbor Solicitation

Das Feld Destination im Ethernet-Header hat den Wert 33:33:ff:60:0d:1e

Vergleichen wir den Wert mit der Zieladresse ff02::1:ff60:d1e im IPv6-Header, fallen Gemeinsamkeiten auf
Offensichtlich wird die Link-layer Multicast Address aus der IPv6 Multicast Address abgeleitet

Hier sind die letzten drei Bytes der Link-layer Multicast Address identisch mit denen der Link-layer Address des Interfaces

Hinweis

Die Link-layer Address hatte uns der Node in einem Neighbor Advertisement mitgeteilt
- siehe Abbildung 4.8 in Abschnitt 4.3 Neighbor Cache
Ein Switch müsste in diesem Fall den Frame einfach auf allen Ports aussenden, deren zugeordnete Link-layer Addresses auf die letzten drei Bytes der Link-layer Multicast Address enden
Viele werden das nicht sein
Ein simples wie effizientes Verfahren

@@ Zeile 5: / Zeile 5: @@
 # Senden eines Echo Request vom ''router'' an ''linux'', um eine Neighbor Solicitation zu erzwingen
-; Ausgabe
 <syntaxhighlight lang="bash" highlight="1" line copy>
-user@router:~$ ping6 -c 3 fe80::200:ff:fe60:d1e%eth1
+root@router:~# ping6 -c 3 fe80::200:ff:fe60:d1e%eth1
 PING fe80::200:ff:fe60:d1e%eth1 (fe80::200:ff:fe60:d1e) 56 data bytes
 bytes from fe8::2:ff:fe6:d1e: icmp_seq=1 ttl=64 time =3.85ms