Skip to content

Conversation

jvfranklin
Copy link
Contributor

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.

@jvfranklin
Copy link
Contributor Author

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.

@rsmarples
Copy link
Member

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.

@rsmarples
Copy link
Member

#343 is related to this I guess.

@rsmarples rsmarples closed this Oct 14, 2024
@rsmarples rsmarples reopened this Oct 14, 2024
@perkelix
Copy link
Contributor

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.

@perkelix
Copy link
Contributor

Have we reached a consensus on this MR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants