我想知道是否有人可以阐明在 IPv6 重复地址检测期间应该何时发送多播侦听器发现 (MLD) 消息。RFC4862 5.4.2节详细描述了执行DAD的IPv6主机应该加入哪些组播组,即全节点组播地址和请求节点组播地址。它还提到了 MLD 的使用,但是我似乎无法解释 Windows 和 Linux 的观察行为,我将在下面解释。
根据 RFC4863,我的理解是节点不应宣布其对全节点多播地址的兴趣(因为 MLD 侦听交换机无论如何都会处理全节点多播流量),但建议为被请求节点发送 MLD 消息多播地址(因为 MLD 侦听交换机不可能知道它应该侦听和转发的所有请求节点多播地址)。
到目前为止一切顺利,但是当我查看 Windows、Linux 和 FreeBSD 如何在 DAD 期间实现 MLD 消息发送时,我不明白为什么请求节点多播地址的 MLD 消息被发送两次。下面是三个跟踪显示分别在启动 Linux、Windows 和 FreeBSD 机器的以太网接口时链路本地地址的 DAD。
- Linux 中 fe80::20e:8eff:fe3b:23ad 的 DAD
- Windows 中 fe80::c14b:8228:ee4:d4aa 的 DAD
- FreeBSD 中 fe80::1234 的 DAD
一些看似奇怪的行为:
- Linux、Windows 和 FreeBSD 都发送了两次 MLD 消息。Linux 和 Windows 将它们间隔大约 300 毫秒,在 FreeBSD 中这是大约 2200 毫秒。为什么发送第二条消息,看看它是如何精确复制第一条消息的?这是某种形式的重传吗?
- Linux 将邻居请求消息 (SOL) 延迟到第二个 MLD 消息之后,而 windows 和 freebsd 立即发送 SOL 消息。
- Windows 和 freebsd 在邻居请求消息之后发送 MLD 消息。授予它在 SOL 消息之后立即发送第一个 MLD 消息。此外,当windows发送SOL消息时,它很可能已经加入了多播组;只有公告本身被延迟,而不是实际加入该组。尽管如此,首先发送 MLD 消息难道不会减少错过来自 MLD 侦听交换机后面的主机的邻居广告的机会吗?
- (请注意,windows 实际上主动通告它已在消息 #4 中分配了 fe80::c14b:8228:ee4:d4aa,但这与 MLD 无关)
到目前为止,我得出的初步结论是,没有关于 MLD 消息计时的标准化做法。有一些指导方针限制发送 MLD 消息以防止拥塞,例如在 RFC 4862 中。任何人都可以参考有关何时在 IPv6 DAD 期间发送 MLD 消息的更多材料,从而解释上述跟踪中的观察结果吗?我假设每个操作系统都在 DAD 期间选择何时发送 MLD 消息,而 Linux 和 Windows/FreeBSD 做出了不同的选择,但是为什么所有三个操作系统都选择为请求节点多播地址发送两次 MLD 消息(间隔 300/300 /2200 毫秒)?
请注意,我知道在大多数情况下 DAD 不需要 MLD 消息传递,并且 DAD 在阻止 MLD 消息时通常可以正常工作(除非某处有 MLD 侦听开关)。然而,我们的一些学生对 MLD 消息传递的不稳定行为感到困惑,我无法向他们解释观察到的行为。