Commit cfd696cc authored by Thomas Haller's avatar Thomas Haller

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

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:


The reason to change from the previous default "duid" to "mac" are the

- "duid" is an RFC 4361 compatible client-id ([1]) 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

- 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.

parent 2ef9a089
......@@ -239,7 +239,7 @@ client_start (NMDhcpManager *self,
* - for IPv4, the calling code may determine a client-id (from NM's connection profile).
* If present, it is taken. If not present, the DHCP plugin uses a plugin specific default.
* - for "internal" plugin, the default is just "duid".
* - for "internal" plugin, the default is just "mac".
* - for "dhclient", we try to get the configuration from dhclient's /etc/dhcp or fallback
* to whatever dhclient uses by default.
* We do it this way, because for dhclient the user may configure a default
......@@ -725,8 +725,7 @@ ip4_start (NMDhcpClient *client,
client_id = nm_dhcp_client_get_client_id (client);
if (!client_id) {
client_id_new = nm_utils_dhcp_client_id_systemd_node_specific (TRUE,
nm_dhcp_client_get_iface (client));
client_id_new = nm_utils_dhcp_client_id_mac (arp_type, hwaddr_arr, hwaddr_len);
client_id = client_id_new;
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment