为什么不在包含NDP邻居请求的IPv6数据包中放置单播地址而不是请求节点多播地址？

Question

这是为什么NDP邻居请求消息被发送到请求的节点地址？的后续问题.

摘要:假设我将发送一个IPv6数据包，并将我想知道的主机的单播地址作为目标地址。然后，我将此数据包放在以太网帧中，并将多播MAC地址33:33:xx:xx:xx:xx作为目标。接收主机的NIC将接受该帧并将其发送到进一步处理。内核将根据(IPv6单播)目标地址接受或拒绝数据包，而不需要查看包含在其中的ICMPv6数据包。这看起来会更有效率。为什么邻居发现不像这样？

这个问题似乎在评论中得到了解决: IPv6请求节点组播地址是组播MAC地址的基础，因此IPv6数据包中的目标字段需要被请求的节点多播地址。但是协议设计者是否认为ND应该像这样工作，还是有必要让ND像这样工作呢？

(使用这种方法，我可以想到的一个问题是，当我请求一个设备的全局单播地址时，路由器可能会将我的数据包从链路上路由出去，这将是不需要的行为。)

Answer 1

IPv6邻居发现的目的是在附加子网上获取已知的IPv6地址，并获得相应的IPv6地址。这使您能够将L3 IPv6数据包封装在L2帧中，并将其发送到L2介质中。

这非常类似于IPv4 ARP，其中您在附加的子网上获取一个已知的IPv4地址，并获得相应的IPv4地址。

诀窍是，您需要通过发送L2帧来获取您的信息。您需要为该帧拥有一个有效的L2目标地址。但是，您还没有该帧的L2单播目的地。

让我们看一下IPv4 ARP示例：

以下是192.168.0.19和192.168.0.10之间的IPv4 ARP：

For reference:
192.168.0.10 = c0a8 000a
192.168.0.19 = c0a8 0013
My ethernet = 685b 3589 0a04

[iMac:~] droot% sudo tcpdump arp -x
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
18:58:01.528290 ARP, Request who-has 192.168.0.19 tell 192.168.0.10, length 28
    0x0000:  ffff ffff ffff 685b 3589 0a04 0806 0001
    0x0010:  0800 0604 0001 685b 3589 0a04 c0a8 000a
    0x0020:  0000 0000 0000 c0a8 0013

在上述情况下，为了保证帧被具有未知L2 MAC地址的目的地解码，ARP将L2以太网帧发送到目的ff.ff，即以太网广播地址。

1982年设计的ARP协议(RFC 826)效率低下。每个ARP请求都会导致子网上的每个主机中断。

，IPv6的设计者想做得更好。他们只想让预定的目的地“监听”邻居发现包。他们会希望以太网帧的目的地成为IPv6目的地.

。

一个问题:目标MAC地址是48位。IPv6地址为128位。

以下是IPv6邻居发现/请求链路本地地址fe80：：aaaa:aaaa从fe80::c0e:acdb:30a3:482c

[iMac:~] droot% sudo tcpdump -x -v icmp6 && ip6 == 135
Password:
tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
19:33:58.748554 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) imac.local > ff02::1:ffaa:aaaa: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::aaaa:aaaa:aaaa:aaaa
      source link-address option (1), length 8 (1): 68:5b:35:89:0a:04
    0x0000:  3333 ffaa aaaa 685b 3589 0a04 86dd 6000
    0x0010:  0000 0020 3aff fe80 0000 0000 0000 0c0e
    0x0020:  acdb 30a3 482c ff02 0000 0000 0000 0000
    0x0030:  0001 ffaa aaaa 8700 4cfc 0000 0000 fe80
    0x0040:  0000 0000 0000 aaaa aaaa aaaa aaaa 0101
    0x0050:  685b 3589 0a04

第一个改进是，这实际上是一个发送给ICMPv6组播地址ff02::1:ffaa:aaaa的IPv6数据包。我们不需要为每一层2技术定义一个单独的类似ARP的协议.我们使用L3-组播，并在L2-多播协议中定义了L3-组播。IPv6邻居发现使用ICMPv6消息类型135。

我们不能使用IPv6单播目的地作为邻居发现目的地，因为我们不知道如何将128位IPv6单播地址编码为48位以太网单播地址。

但是，我们可以定义一条规则，从我们的L3单播目的地选择特定的L3组播删除。来自RFC4291 https://www.rfc-editor.org/rfc/rfc4291#section-2.7.1

   Solicited-Node multicast address are computed as a function of a
   node's unicast and anycast addresses.  A Solicited-Node multicast
   address is formed by taking the low-order 24 bits of an address
   (unicast or anycast) and appending those bits to the prefix
   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
   range

         FF02:0:0:0:0:1:FF00:0000

   to

         FF02:0:0:0:0:1:FFFF:FFFF

因此，我们对fe80：：aaaa:aaaa的IPv6单播请求变成了ICMPv6邻居请求，用于ff02::1:ffaa:aaaa，这是一个IPv6多播地址。

我们有一个IPv6 L3多播地址的规则:它们可以在有线上传输，L2目的地为33:33:xx:xx，其中L3地址的最后32位被转换为L2地址的最后32位！

这将导致目标mac地址：

fe80::aaaa:aaaa:aaaa:aaaa -> ff02::1:ffaa:aaaa  -> 3333.ffaa.aaaa

酷的是，这并不会对网络上的每一个主机造成中断。只有正在监听L2多播的主机才能收听3333.ffaa.aaaa。假设最后的24位是“随机的”(不是真的)，那将是1/1600万(2^24)主机。

有一些复杂性，但仅仅是因为我们有一些规则：

1. 将IPv6 L3单播地址转换为用于邻居请求的IPv6 L3多播地址的规则
2. 一种将IPv6 L3多播地址转换为L2多播地址以进行传输的规则。

我们不能这样做：

fe80::aaaa:aaaa:aaaa:aaaa (IPv6 unicast)
-> fe80::aaaa:aaaa:aaaa:aaaa (ICMPv6 multicast?)
-> ??

我们只是不知道如何将IPv6单播地址转换为L2地址。因为我们从128位到48位，所以在某一时刻，我们必须使用多个->一个映射。在IPv4中，我们使用以太网广播(所有->一).在IPv6中，我们使用L3组播/L2组播(多->一种)。

Answer 2

NDP将在源主机中填充一个表，这样源主机只需要在开始时发现目标层-2地址，然后就可以向目标发送单播层-2帧。

如果目标主机不为源主机提供其单播层2地址(响应NDP请求)，而不是简单地通过向网络堆栈发送有效负载来处理IPv6数据包，则源主机将始终需要使用多播层2地址将所有帧发送到目标主机(主机之间的大多数通信由多个多帧组成)。这将是低效的，因为交换机需要将所有多播帧转发到所有交换机接口，将流量放置在不需要或不需要的链路上。

效率的提高是因为源只需要请求目标层-2地址(发送到所有交换机链接)一次，而它发送的其余帧则可以使用单播层-2目标地址(然后交换机将只将帧发送到能够找到目标的单个接口)。

Answer 3

这里的分离是，第三层没有指定第二层信息，也不一定知道涉及哪一层-2。因此，虽然在逻辑上可能有可能使用发送到多播地址的以太网帧(想必)中包含的单播L2信息来构建包(实际上是帧，因为我们正在钻研L2)，但是您将跨越许多行并打破几条规则来实现它。任何执行这些规则的安全策略都会破坏您的“创新优化”。

(提示:这并不像你想的那样是一种优化。查看要删除的L3头，与查看NS请求相比，只需要稍微少一些处理。因为它被发送到第二层多播目标，所以当只有一个系统需要时，多个系统可能会看到它。组播的重点是减少从所有-- IPv4 ARP广播到一些-- IPv6 ND.的足迹。