fe80::1234:56ff:fe12:3456%eth0私はLinuxを使っていて、同じイーサネットスイッチに接続されている にpingを実行したいのですeth0が、まだ通信していないfe80::1234:56ff:fe12:3456のでMACアドレスがキャッシュされていません（ にはありませんip neigh list）。
ping fe80::1234:56ff:fe12:3456%eth0
私は送る
- ICMP近隣要請パケット内部
- マルチキャスト宛先アドレスを
ff02::1:ff12:3456内部に持つ IPv6 データグラム - マルチキャスト宛先アドレスを持つイーサネット フレーム
33:33:ff:12:34:56。
これは MAC アドレスの下位 24 ビットで構成され、同じビットを共有するノードはすべてこのマルチキャスト アドレスをリッスンすることがわかりますff02::1:ff12:3456。しかし、なぜこのように指定されているのでしょうか。ICMP パケットを宛先 IPv6 アドレスに直接送信し、マルチキャスト MAC アドレスがそれを候補に配布するようにすればよいのではないでしょうか。次のようになります。
- ICMP近隣要請パケット内部
fe80::1234:56ff:fe12:3456ユニキャスト宛先アドレスを内部に持つ IPv6 データグラム- マルチキャスト宛先アドレスを持つイーサネット フレーム
33:33:ff:12:34:56。
答え1
イーサネットはどこにでも存在しますが、唯一のレイヤー 2 テクノロジーではありません。
「IPv6パケットオーバー」をスクロールするRFC多様なリンク層を明らかにしますBluetooth 低エネルギー ITU-T G.9959 パーソナルエリアネットワーク、ファイバーチャネルトークン リングや FDDI などの時代遅れの代替手段もあります。
マルチキャストを実装するリンク層は、IPv6 マルチキャスト アドレスをその実装にマップします。これを回避できないリンク層。おそらく、ポイントツーポイント リンクにより、ルーターはマルチキャスト リスナーを追跡できます。または、ブロードキャスト実装ですが、ARP のようにすべてのノードに送信するのは理想的ではありません。
近隣探索IP スタックには、一貫した抽象化とコードの再利用という利点があります。ターゲットを絞った IP パケットを作成して、リンク層アドレスを取得できます。レイヤー 3 コードが作成された時点では想像もできなかったハードウェアも含まれています。
答え2
回答者はあなたの質問を理解していないと思います:-)。私もこの質問を持っていますが、Stefan van den Akker（ここでの質問の著者 -https://networkengineering.stackexchange.com/questions/63841/why-not-put-unicast-address-in-ipv6-packet-containing-ndp-neighbor-solicitation) は、これにより不要なルーティングの問題を解決できると述べています。
(このアプローチで考えられる 1 つの問題は、同じリンク上にないデバイスのグローバル ユニキャスト アドレスを要求したときに、ルータがパケットをリンク外にルーティングする可能性があることです。これは望ましくない動作です。)
また、統一性のためでもあります (IPv6 マルチキャストはイーサネット マルチキャストに変換され、ネイバー要請のこのルールの例外により統一性が損なわれます)。
もちろん、OS カーネルのネットワーク層は必要なパケットを自由に構築できるため、上記以外にアイデアはありません。また、マルチキャスト MAC アドレスとユニキャスト IPv6 アドレスを含むパケットも構築できます。