我在 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 个人区域网，光纤通道. 还有像 Token Ring 或 FDDI 这样的过时的替代方案。
实现多播的链路层将 IPv6 多播地址映射到其实现。那些不解决这个问题的链路层。也许点对点链路让路由器跟踪多播侦听器。或者也许是广播实现，尽管像 ARP 那样发送到所有节点并不理想。
邻居发现在 IP 堆栈中实现 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-solicitation）说，这可以解决不必要的路由问题：
（我认为这种方法的一个问题是，当我请求不在同一链路上的设备的全局单播地址时，路由器可能会将我的数据包路由出链路，这是不受欢迎的行为。）
并且也为了统一性（IPv6 多播转换为以太网多播并且邻居请求的此规则的例外会破坏统一性）。
除了上面提到的，我没有其他想法，因为当然，OS 内核的网络层可以构造他们想要的任何数据包。还有具有多播 mac 地址和单播 ipv6 地址的数据包。