我使用的是 Linux，我想要 pingfe80::1234:56ff:fe12:3456%eth0與我的介面連接到同一乙太網路交換器的裝置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。
我知道它ff02::1:ff12:3456是由 MAC 位址的低 24 位元構成的，並且共享相同位元的節點都偵聽該多播位址。但為什麼要這樣指定呢？為什麼不直接將 ICMP 封包傳送到目標 IPv6 位址，讓多播 MAC 位址負責將其分發給可能的候選者？像這樣：
- 內部 ICMP 鄰居請求封包
fe80::1234:56ff:fe12:3456內部帶有單播目標位址的 IPv6 資料報- 具有多播目標位址的乙太網路幀
33:33:ff:12:34:56。
答案1
乙太網路雖然無所不在，但並不是唯一的第 2 層技術。
捲動瀏覽“IPv6 資料包結束”RFC將揭示不同的鏈路層，包括藍牙低功耗 ITU-T G.9959個域網,光纖通道。還有過時的替代方案，如令牌環或 FDDI。
實作多播的連結層將 IPv6 多播位址對應到其實作。那些不能解決這個問題的人。也許點對點鏈路可以讓路由器追蹤多播偵聽器。或者也許是廣播實現，儘管像 ARP 這樣發送到所有節點並不理想。
鄰居發現IP堆疊的優點是一致的抽象和程式碼重用。可以建立目標 IP 封包來取得鏈結層位址。包括在編寫第 3 層程式碼時無法想像的硬體。
也可以看看： 為什麼需要 IPv6 鄰居請求來取得 MAC 位址？
答案2
我認為回覆者沒有理解你的問題:-)。我也有這個問題，並認為，正如 Stefan van den Akker（這裡問題的作者 -https://networkengineering.stackexchange.com/questions/63841/why-not-put-unicast-address-in-ipv6-packet-containing-ndp-neighbor-soliitation）說，這可以解決不必要的路由問題：
（我可以想到這種方法的一個問題是，當我要求不在同一鏈路上的設備的全域單播位址時，路由器可能會將我的資料包路由到鏈路之外，這將是不需要的行為。
並且也是為了一致性（ipv6 多播轉換為乙太網路多播，而鄰居請求的此規則的例外會破壞一致性）。
除了上面提到的之外，我沒有其他想法，因為當然，作業系統核心的網路層可以建構他們想要的任何需要的資料包。還有一個帶有多播 mac 位址和單播 ipv6 位址的資料包。