NetworkConfiguration
Don't configure an IPv6 link-local address if noipv6rs is set
The configuration I'm using uses the noipv6rs option to allow the Linux kernel to do router discovery, slaac, etc. I'm seeing dhcpcd configuring an EUI64 format link-local address unnecessarily. This change stops dhcpcd from doing that.
This is a demo of what I'm seeing. Our product is a Linux-based system with a custom network manager daemon, so I'm just using dhcpcd as a DHCP/DHCPv6 client. If I want to use stable-privacy addresses, managed by the kernel, dhcpcd interferes with that when it starts up:
/home/root# cat /tmp/dhcpcd.conf allowinterfaces nic1 interface nic1 noup noipv4 ipv6ra_noautoconf noipv6rs inform6 /home/root# cat /proc/sys/net/ipv6/conf/nic1/addr_gen_mode 2 /home/root# ip addr show nic1 12: nic1@eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 6c:3c:8c:85:23:59 brd ff:ff:ff:ff:ff:ff /home/root# /tmp/dhcpcd -f /tmp/dhcpcd.conf dhcpcd-10.1.0 starting dev: loaded udev DUID 00:01:00:01:2e:90:6e:ee:6c:3c:8c:85:23:59 Dropped protocol specifier '.link' from 'nic1.link'. Using 'nic1' (ifindex=12). no interfaces have a carrier /home/root# cat /proc/sys/net/ipv6/conf/nic1/addr_gen_mode 1
So now if I bring up nic1, it comes up with an EUI64 link-local instead of stable-privacy. I've also seen the interface have both, but I think it's timing dependent.
/home/root# ip link set dev nic1 up /home/root# ip addr show nic1 12: nic1@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 6c:3c:8c:85:23:59 brd ff:ff:ff:ff:ff:ff inet6 fe80::6e3c:8cff:fe85:2359/64 scope link valid_lft forever preferred_lft forever
With my patch, addr_gen_mode remains set to 2, and I don't have any conflicts between the network manager and dhcpcd.
Need to think about this because you can use DHCPv6 without RS/RA and DHCPv6 still requires a LL address.
I think we need a new option, noipv6ll, but we're also out of options for unsigned long long.
Might need to create a new option group for inet6 and move all INET6 options into it (apart from DHCPCD_IPV6).
I won't be around much this week so I'll think it over some.
It kinda is related to #343 since it's about not touching the interface's flags unless explicitly asked to do so.
However, what this bug wants is more akin to having a configuration option for disabling DHCPv6 and letting RS do its thing without dhcpcd's intervention.
What it instead reminds me of is something I reported a long time ago (I cannot remember the bug number): in some circumstances, a superflous LL6 address that uses EUI64 gets added in addition to a LL6 address that uses dhcpcd's pseudo-privacy.
