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.

Penguin Brian
  • 131
  • 2
  • 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.) – u1686_grawity Dec 07 '20 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? – Penguin Brian Dec 13 '20 at 09:46
  • 1
    Bug? No, like I said, this is how it's supposed to work. – u1686_grawity Dec 13 '20 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?

     – Penguin Brian Dec 14 '20 at 00:17
  • Wait, Kubernetes actually uses dummy interfaces? For what part of Kubernetes? – dirkt Dec 14 '20 at 22:15
  • When configured with ipvs, and you have a service that defines an external address, it will add that address to kube-ipvs0 for every node. Which is advertised for IPv4 and not IPv6. But I have been told that IPv4 is doing the wrong thing here. These addresses should not be advertised externally, as you end up with conflicting addresses. See my bug report https://github.com/kubernetes/kubernetes/issues/97275 for further details.

    While it makes sense now (I think!), better documentation would have avoided my confusion :-)

     – Penguin Brian Dec 14 '20 at 22:28

1 Answers1

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.

Penguin Brian
  • 131
  • 2