接口上的IPv6地址不响应其他接口上的NDP数据包

Question

在192.168.2.0/24和2001:44b8:4112:8a02：：//64上具有enp3s0接口的给定计算机中，如果我执行以下操作：

canidae# ip link add dummy0 type dummy
canidae# ip addr add dev dummy0 2001:44b8:4112:8a02::55 
canidae# ip addr add dev dummy0 192.168.2.55
canidae# ip link set dummy0 up

ip addr的以下输出确认这两个IP地址都是全局的：

46: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 02:d1:a1:a4:7d:a6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.55/32 scope global dummy0
       valid_lft forever preferred_lft forever
    inet6 2001:44b8:4112:8a02::55/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::d1:a1ff:fea4:7da6/64 scope link 
       valid_lft forever preferred_lft forever

现在从网络上的另一台计算机上，我可以点击192.168.2.55。由于IP地址是全局的，所以数据包进入enp3s0并不重要，而不是dummy0。

但我不能平2001:44b8:4112:8a02::55来自远程主机。主机发出NDP请求来定位2001:44b8:4112:8a02::55，但没有得到响应。因此，似乎这些地址实际上并不是全局的，而是特定于接口的。

如果我手动将相同的IPv6地址添加到enp3s0中。它起作用。事实上，如果我从IPv6中删除enp3s0地址分配，它会继续工作一段时间，大概是因为NDP结果被缓存了。计算机知道如何处理数据包的地址，如果它收到，但只是喜欢保守秘密。

我的理解是，这应该与IPv6一样适用于IPv4，但它不适用。

这台计算机没有iptables或ip6tables可能阻塞了什么东西。

这台计算机是：

canidae# uname -a
Linux canidae 5.9.0-3-amd64 #1 SMP Debian 5.9.9-1 (2020-11-19) x86_64
GNU/Linux

但我也看到过类似的行为：

root@kube-node-3:~# uname -a
Linux kube-node-3 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux

有人能解释一下这种行为吗？它有可能修复它，使它像我所期望的那样工作吗？

PS。为那个不理想的测试IP地址192.168.2.55/32道歉--它是正确的，不应与255的广播地址混淆。与IPv6地址相同。

Answer 1

对于IPv4，下面是一个非常类似的问题：

https://serverfault.com/questions/834512/why-does-linux-answer-to-arp-on-incorrect-interfaces

我相信这也被称为“严格的arp”。我相信默认情况下“严格的arp”是开着的，但是默认情况下“严格的ndp”是关闭的(实际上你甚至不确定你能不能改变这一点)。

因此，虽然我找不到任何参考资料，但我怀疑这是预期的行为。