(no title)
blucaz | 1 year ago
- the assertion is made that networkd creates link local addresses - it does not, the kernel does.
- the assertion is made that configuring how the _kernel_ sets up link local addresses must automatically and silently affect how userspace network managers configure global addresses. This is of course not the case, and one might ask for such a feature, but its absence most definitely does not mean that it is "utterly inadequate for IPv6 or dual-stack installations".
- the assertion is made that userspace network managers independently listening on RA packets and creating SLAAC global addresses independently of the kernel must set the stable-privacy interface flag. This is not the case, such flags are owned by the kernel and cannot be set by userspace. Being absent does not mean the the addresses are not private or stable, it just means they are not kernel managed, and thus a different (RFC 7217 compliant) algorithm is used as explained on https://www.freedesktop.org/software/systemd/man/latest/syst...
- the assertion is made that the suffixes generated by the _kernel_ to set up link local addresses must automatically and silently be copied by userspace network managers to configure global addresses on the respective interfaces. This is also of course not the case, the algorithm is described in the link above, and again asking for such a new feature is fine, but its absence does not mean that it is "utterly inadequate for IPv6 or dual-stack installations".
- the assertion is made that certain defaults must be changed to meet the OP's personal preferences. This of course cannot really be done in a project like systemd, where we try our best to keep backward compatibility, even if we don't always succeed. The desired configuration is very easy to setup, for example this should suffice:
[Network] IPv6PrivacyExtensions=yes IPv6LinkLocalAddressGenerationMode=stable-privacy
[IPv6AcceptRA] Token=prefixstable
As usual, it would be best to ask clarification questions and investigate how things actually work _before_ making definitive assertions on a blog post about a component for which one has a cursory understanding at best, but that's not nearly as much fun as a good ol' systemd bashing blog post, right?
No comments yet.