2

From a given computer that has a enp3s0 interface on 192.168.2.0/24 and 2001:44b8:4112:8a02::/64, if I do the following:

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

The following output from ip addr confirms that both IP addresses are global:

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

Now from another computer on the network, I can ping 192.168.2.55. It does not matter that the packets are coming in on enp3s0, not dummy0 because the IP address is global.

But I cannot ping 2001:44b8:4112:8a02::55 from a remote host. The host sends out NDP requests to locate 2001:44b8:4112:8a02::55 but gets no response. So it seems like the addresses aren't actually global but specific to an interface.

If I manually add the same IPv6 address to enp3s0. The it works. In fact it continues to work for a while if I delete the IPv6 address assignment from enp3s0, presumably because the NDP result was cached. The computer knows how to deal with packets for the address if it receives them, but just likes to keep it a secret.

My understanding is that this is suppose to work for IPv6 the same as IPv4, but it doesn't.

This computer has no iptables or ip6tables that might be blocking something.

This computer is:

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

But I have seen similar behavior with:

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

Can anybody explain this behavior? Is it possible to fix it so it works as I would expect?

PS. apologies for that non-ideal test IP address 192.168.2.55/32 - it is correct as written, and not to be confused with the broadcast address of 255. Same with the IPv6 address.

Improve this question
6
  • 1
    I don't know nearly enough to write an answer, but I do know that it is supposed to work this way for IPv6 for multihoming purposes, differently from IPv4. (Roughly the same reason why IPv6 routes can match by source as well as by destination.) Commented Dec 7, 2020 at 14:38
  • Have I found a bug? If so where should I report it? How can I get into contact with somebody who might be able to help? Commented Dec 13, 2020 at 9:46
  • 1
    Bug? No, like I said, this is how it's supposed to work. Commented Dec 13, 2020 at 10:13
  • Oh sorry, I thought you meant the behavior I expected was how it was suppose work. As opposed to the behavior I observed. My dual stack Kubernetes install appears to be relying on this to work. Do you have any references to back you on this? Commented Dec 14, 2020 at 0:17
  • Wait, Kubernetes actually uses dummy interfaces? For what part of Kubernetes? Commented Dec 14, 2020 at 22:15

1 Answer 1

Reset to default
1

Here is a very similar question asked for IPv4:

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

I believe this is also known as "strict arp". I believe "strict arp" is on by default but "strict ndp" is off by default (actually not even sure you can change this).

So while I can't find any references, I suspect this is the intended behavior.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.