Ich verwende Linux und möchte einen Ping senden fe80::1234:56ff:fe12:3456%eth0
, der mit demselben Ethernet-Switch wie meine eth0
Schnittstelle verbunden ist. Ich habe noch nicht kommuniziert, fe80::1234:56ff:fe12:3456
daher ist die MAC-Adresse nicht im Cache gespeichert (sie befindet sich nicht in ip neigh list
). Wenn ich
ping fe80::1234:56ff:fe12:3456%eth0
ich sende
- ICMP-Nachbarschaftsanforderungspaket im Inneren
ff02::1:ff12:3456
IPv6-Datagramm mit darin enthaltener Multicast-Zieladresse- Ethernet-Frame mit Multicast-Zieladresse
33:33:ff:12:34:56
.
Ich verstehe, dass ff02::1:ff12:3456
es aus den unteren 24 Bits der MAC-Adresse aufgebaut ist und dass alle Knoten, die dieselben Bits gemeinsam nutzen, diese Multicast-Adresse abhören. Aber warum wird es so angegeben? Warum wird das ICMP-Paket nicht einfach direkt an die Ziel-IPv6-Adresse gesendet und die Multicast-MAC-Adresse kümmert sich um die Verteilung an mögliche Kandidaten? So:
- ICMP-Nachbarschaftsanforderungspaket im Inneren
fe80::1234:56ff:fe12:3456
IPv6-Datagramm mit darin enthaltener Unicast-Zieladresse- Ethernet-Frame mit Multicast-Zieladresse
33:33:ff:12:34:56
.
Antwort1
Ethernet ist zwar weit verbreitet, aber nicht die einzige Layer-2-Technologie.
Durch „IPv6-Pakete über“ blätternRFCswerden verschiedene Verbindungsebenen sichtbar, darunterBluetooth Low Energy ITU-T G.9959 persönliche Netzwerke,Glasfaserkanal. Auch veraltete Alternativen wie Token Ring oder FDDI.
Link-Layer, die Multicast implementieren, ordnen ihren Implementierungen IPv6-Multicast-Adressen zu. Diejenigen, die das nicht umgehen können. Vielleicht ermöglichen Punkt-zu-Punkt-Links einem Router, Multicast-Listener zu verfolgen. Oder vielleicht eine Broadcast-Implementierung, obwohl das Senden an alle Knoten wie ARP nicht ideal ist.
Nachbarerkennungim IP-Stack hat den Vorteil einer konsistenten Abstraktion und Code-Wiederverwendung. Es kann ein gezieltes IP-Paket erstellt werden, um die Link-Layer-Adresse zu erhalten. Auch über Hardware, die zum Zeitpunkt der Erstellung des Layer-3-Codes unvorstellbar war.
Siehe auch: Warum benötigen Sie IPv6 Neighbor Solicitation, um die MAC-Adresse zu erhalten?
Antwort2
Ich denke, die Antwortenden haben Ihre Frage nicht verstanden :-). Ich habe diese Frage auch und denke, dass, wie Stefan van den Akker (Autor der Frage hier -https://networkengineering.stackexchange.com/questions/63841/why-not-put-unicast-address-in-ipv6-packet-containing-ndp-neighbor-solicitation) gesagt, dies kann das unerwünschte Routing-Problem lösen:
(Ein Problem, das mir bei diesem Ansatz einfällt, besteht darin, dass Router mein Paket möglicherweise vom Link wegleiten, wenn ich die globale Unicast-Adresse eines Geräts anfordere, das sich nicht auf demselben Link befindet, was ein unerwünschtes Verhalten wäre.)
Und auch aus Gründen der Einheitlichkeit (IPv6-Multicast wird in Ethernet-Multicast umgewandelt und eine Ausnahme von dieser Regel für die Nachbarwerbung würde die Einheitlichkeit verletzen).
Ich habe keine anderen Ideen als die oben genannten, da die Netzwerkschicht des Betriebssystemkernels natürlich jedes gewünschte Paket erstellen kann. Und auch ein Paket mit Multicast-MAC-Adresse und Unicast-IPv6-Adresse.