prefix ::/64 seems no longer work (Gentoo, radvd 2.19 r7) as it used to work?

[joanandk]

Hi,
Systems:
Server: Gentoo with radvd 2.19-r7, kea 2.4.1, IPv6 address for illustration: A:B:C:D::1/64
Client: Gentoo with dhcpcd 10.0.10, IPv6 address for illustration: A:B:C:D:n:m::190

I have been using radvd with the prefix ::/64 since around starting of this year. It worked fine until today (reboot after updating radvd to 2.19-r7 on a Gentoo server). All clients with dhcpcd on the network report DAD with the IP address which was assigned to the interface on the server. As soon as I change the prefix to A:B:C:D::/64 in the radvd.conf, the problem seems to be solved.

Why this is an issue: The client seems to loose connectivity for a short time and some applications do no longer work.

One of the clients has NetworkManager. This seems not to be affected by the issue.

So for those who see this in dmesg:
"IPv6: eno1: IPv6 duplicate address A:B:C:D::1 used by xx:yy:zz:aa:bb:cc detected!"
where the MAC address changes if there are many clients on the network. You should fix the prefix to your prefix instead of ::/64 in the radvd.conf.

BR

[robbat2]

Is that the exact error message? I ask because I cannot find that string in radvd itself, or the Linux kernel.

• Can you post a ip -6 a, ip -6 ro, ip -6 neigh for a client in both states [broken and then exactly when it doesn't work].
• When you say loses connectivity: to the local network, to the internet/default route, and/or to another adjacent network [via a specific RA]

I'm wondering if there is some another RA on your network with no default route.

[Neustradamus]

@joanandk: Have you seen the @robbat2 answer?

[joanandk]

Hi,
As the bug affects all devices on the network, I have to wait this Sunday or the next weekend. I will report back as soon as I can.

Thanks for your patience

[joanandk]

So here we go:
radvd is set to prefix 2a07:d2a0:5:ed00::/64 { AdvAutonomous off; }
ip -6 a (without lo):

inet6 2a07:d2a0:5:ed00::4b/128 scope global dynamic noprefixroute
  valid_lft 6285sec preferred_lft 3585s"
inet6 fe80::1775:8b46:748a:ce1c/64 scope link
  valid_lft forever preferred_lft forever

ip -6 ro:

2a07:d2a0:5:ed00::/64 dev enp2s0 ra metric 1002 pref medium
fe80::/64 dev enp2s0 proto kernel metric 256 pref medium
default via fe80::9437:e4ff:fe8c:c38c dev enp2s0 proto ra metric 1002 pref medium

ip -6 neigh:

2a07:d2a0:5:ed00::30 dev enp2s0 lladdr <mac-address of router> router REACHABLE
fe80::9437:e4ff:fe8c:c38c dev enp2s0 lladdr <mac-address of router> router STALE

radvd is set to prefix ::/64 { AdvAutonomous off; }
ip -6 a: Same as above (two entries, global and link local).
ip -6 ro:

fe80::/64 dev enp2s0 proto kernel metric 256 pref medium
default via fe80::9437:e4ff:fe8c:c38c dev enp2s0 proto ra metric 1002 pref medium

ip -6 neigh:
fe80::9437:e4ff:fe8c:c38c dev enp2s0 lladdr <mac-address of router> router REACHABLE

The only difference is, neither route nor neigh sees the global ipv6 of the router, only the link local of the router. So, is the router advertisement not setting the values as it used to do in the prior version?

dmesg: IPv6: enp2s0: IPv6 duplicate address 2a70:d2a0:5:ed00::30 used by <mac-address> of router detected!

As the prefix assigned to me doesn't change, this issue is not very important.

Thanks and BR

[Neustradamus]

@robbat2: Have you seen the latest @joanandk comment?

[robbat2]

@joanandk I dug at this for a while.

I think we are missing something else about your configuration, that is causing the behavior you observed.
likely sysctl settings, either on the client or server.

> dmesg: `IPv6: enp2s0: IPv6 duplicate address 2a70:d2a0:5:ed00::30 used by <mac-address> of router detected!`

This is duplicate address detection - saying that the IP exists somewhere else on your network as well. Did you maybe use ip token somewhere and have a conflicting token?

Two testcases to represent what you claim, using dummy0 interface for settings.

# interface set
$ ip link add name dummy0 mtu 1500 type dummy
$ ip link set dummy0 up multicast on arp on

# test1.conf:
interface dummy0 {
  AdvSendAdvert on;
  prefix 2001:0DB8::/64 { AdvAutonomous off; };
};

# test2.conf
interface dummy0 {
  AdvSendAdvert on;
  prefix ::/64 { AdvAutonomous off; };
};

(run radvd with the configs, one at a time)

$ tcpdump -i dummy0 -n -vv -xX -p -e 'ip6' -t
e2:6a:7a:f5:2c:42 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 110: (flowlabel 0x417d0, hlim 255, next-header ICMPv6 (58) payload length: 56) fe80::e06a:7aff:fef5:2c42 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 56
	hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
	   prefix info option (3), length 32 (4): 2001:db8::/64, Flags [onlink], valid time 86400s, pref. time 14400s
	     0x0000:  4080 0001 5180 0000 3840 0000 0000 2001
	     0x0010:  0db8 0000 0000 0000 0000 0000 0000
	   source link-address option (1), length 8 (1): e2:6a:7a:f5:2c:42
	     0x0000:  e26a 7af5 2c42

Get the same output, byte-for-byte on both config files.

So here we go: radvd is set to prefix 2a07:d2a0:5:ed00::/64 { AdvAutonomous off; } ip -6 a (without lo):

inet6 2a07:d2a0:5:ed00::4b/128 scope global dynamic noprefixroute
  valid_lft 6285sec preferred_lft 3585s"
inet6 fe80::1775:8b46:748a:ce1c/64 scope link
  valid_lft forever preferred_lft forever

ip -6 ro:

2a07:d2a0:5:ed00::/64 dev enp2s0 ra metric 1002 pref medium
fe80::/64 dev enp2s0 proto kernel metric 256 pref medium
default via fe80::9437:e4ff:fe8c:c38c dev enp2s0 proto ra metric 1002 pref medium

ip -6 neigh:

2a07:d2a0:5:ed00::30 dev enp2s0 lladdr <mac-address of router> router REACHABLE
fe80::9437:e4ff:fe8c:c38c dev enp2s0 lladdr <mac-address of router> router STALE

radvd is set to prefix ::/64 { AdvAutonomous off; } ip -6 a: Same as above (two entries, global and link local). ip -6 ro:

fe80::/64 dev enp2s0 proto kernel metric 256 pref medium
default via fe80::9437:e4ff:fe8c:c38c dev enp2s0 proto ra metric 1002 pref medium

ip -6 neigh: fe80::9437:e4ff:fe8c:c38c dev enp2s0 lladdr <mac-address of router> router REACHABLE

The only difference is, neither route nor neigh sees the global ipv6 of the router, only the link local of the router. So, is the router advertisement not setting the values as it used to do in the prior version?

dmesg: IPv6: enp2s0: IPv6 duplicate address 2a70:d2a0:5:ed00::30 used by <mac-address> of router detected!

As the prefix assigned to me doesn't change, this issue is not very important.

Thanks and BR

[stappersg]

Asking @joanandk for reporting back on the above comment or on how version 2.20 is doing. Reporting on both is also fine. 😉

[joanandk]

Asking @joanandk for reporting back on the above comment or on how version 2.20 is doing. Reporting on both is also fine. 😉

Sorry, had been busy with other stuff.
As @robbat2 has written, I think I did have token set, but that did not point to the conflicting IPv6 address, that's why I did not think that was the issue. In the meantime I do no longer have the token set. I would need a free weekend to try the dummy interface testing.

Thanks and BR

[robbat2]

Thanks; i'm going to close this as can't reproduce then.