dhcp: default ipv4.dhcp-client-id of internal plugin to "mac"
The "ipv4.dhcp-client-id" is configurable per-profile and the default value can be overwritten via connection defaults in NetworkManager.conf. For "dhclient" DHCP plugin, the ultimate default for "ipv4.dhcp-client-id" is determined by dhclient itself, or possibly by user configuration from "/etc/dhcp". For the "internal" DHCP plugin, the default must be decided by NetworkManager. Also, the default here is important, as we preferably won't change it anymore. That is because a changing the client-id will result in different IP addresses after upgrade of NetworkManager version. That should be avoided. Still, change it now. If a downstream does not want this, it either needs to patch the sources or add a configuration snippet like: [connection-internal-dhcp-client-id-duid] match-device=dhcp-plugin:internal ipv4.dhcp-client-id=duid The reason to change from the previous default "duid" to "mac" are the following: - "duid" is an RFC 4361 compatible client-id () and "mac" is defined in RFC 2132. - "duid" cannot (easily) be predicated a-priori as it is a hash of the interface-name and "/etc/machine-id". In particular in cloud and server environments, admins often prefer "mac" as they do know the MAC address and pre-configure the DHCP server accordingly. - with "dhclient" plugin, the default is decided by dhclient package or user configuration in "/etc/dhcp". However, in fact the default is often "client-identifier hardware" (for example on RHEL/CentOS). - for RHEL/CentOS we require a way to select "mac" as default. That was done by installing a configuration snippet via the NetworkManager-config-server package. It's confusing to have the default depend on a package. Avoid that. Also, users required "mac" in certain scenarios, but no users explicitly asked for "duid" as default. - our "duid" implementation generates a 32 bit IAID based on a hash of the interface-name, and only 8 bytes entropy that contains a hash of "/etc/machine-id". The point is, that is not a lot of entropy to avoid conflicting client-ids. Another point is, that the choosen algorithm for "duid" is suitable for RFC 4361, but it's only one of many possibly implementations. Granted, each possibility has up and downsides but selecting one of them as default seems wrong (given that it has obvious downsides already). For "mac" there is only one straight-forward way to implement it. - RFC 7844 (Anonymity Profiles for DHCP Clients) is not yet supported by NetworkManager. But we should not select a default client-id which counteracts anonymit. Choosing "mac" does not reveal information which is not already exposed.  https://tools.ietf.org/html/rfc4361#section-4 https://bugzilla.redhat.com/show_bug.cgi?id=1661165
Showing with 2 additions and 3 deletions