NetworkManager supports two DHCP plugins: "dhclient" and "internal". Both are fully supported for the customer on RHEL. This is configurable via "main.dhcp" setting in `man NetworkManager.conf`.


On RHEL-7, the default was "dhclient".

On RHEL-8, the default changed to "internal" (bug 1571655).


"dhclient" plugin allows the user to configure dhclient outside of NetworkManager via /etc/dhcp directory. Thereby bypassing NetworkManager API. In particular this means, if the user leaves "ipv4.dhcp-client-id" unspecified, the default depends on whatever dhclient has configured, which in turn is "hardware" (see bug 1579768).

"internal" plugin does not accept external configuration (from /etc/dhcp), so the question of which DHCP client identifier to use by default becomes important. This is a distinction from "dhclient", where the default is not determiend by NetworkManager.

Note, that the default only matters if
  - the per-profile value ipv4.dhcp-client-id is left unspecified
  - the default is not explicitly configured via NetworkManager.conf (see "CONNECTION SECTION" in `man NetworkManager.conf`).


Anyway, the default is important. Also, we cannot change it after rhel-8 GA, because changing the default client-id on a minor release changes behavior.



Now, currently the default is "duid". This is a RFC4361 client-id. Note that the DUID is not randomly generated and persisted value, but deterministically hashed from the interface name and /etc/machine-id. See [1].

Note that RFC4361 recommends using such client-identifiers over hardware based ones. Such a client-id has conflicting goals from a hardware based one (RFC2132), but there are reasons to prefer one or the other.

This already met objections (bug 1640494), so as compromise the package "NetworkManager-config-server" would install a configuration snippet [3] which changes the default from "duid" to "mac". Note that the "NetworkManager-config-server" package is commonly installed on server variants, as such a default is deemed more sensible for servers, where the admin may need to have a predictable DHCP client-id when configuring the server in the data center.


I propose now, to change the default to "mac" everywhere. That means, drop the configuration snippet [3] and change the build-in default.



Reasons:

- differentiating behavior based on NetworkManager-config-server is ugly and should be avoided.

- "mac" arguably makes sense it lots of scenarios, in particular server and cloud scenarios (yay, RHEL).

- the "duid" mode itself has ugliness, making it unfit for a default value which we need to stick to.

  - "duid" hashes a 32 bit IAID value from the interface name [1]. This doesn't have a high entropy to avoid duplicate client-ids on different interfaces of the same host. Note, that all other fields of the client-id are the same per-host.
  - the DUID part consists of a fixed 6 bytes (00:02:00:00:ab:11), leaving only 8 bytes entropy for the per-host part. Not a lot either.
  - Maybe I am wrong about this (it's only my feeling), but there is very little entropy here. I'd prefer to just hash all 18 bytes and not trying to encode values inside the DUID. Anyway, what wouldn't be RFC compliant, and we already have a mode "stable" that does something comparable. But it's not clear to me, that the used algorithm for "duid" is really the best default. On the other hand, with "mac" mode no such questions arise because the approach is straight forward.

- nobody actually asked for this change to use "duid". But people do care about "mac".

- We don't support RFC 7844 (Anonymity Profiles for DHCP Clients) yet (bug 1337581). However, choosing a client-id which makes the host identifiable by default seems a very bad choice and conflicts with RFC 7844. "mac" would be a better default choice here, because it doesn't reveal any information that is not already exposed on the network.

- "mac" by default would be what also "dhclient" does. Being consistent here for both plugins is already a good thing. Also, presumably "dhclient" maintainers had to make similar trade-offs and came to the conclusion that "hardware" is preferable [4].



We should do this change before rhel-8.0, and also upstream (for the same reasons). If another downstream dislikes the change in behavior, they can install a configuration snippet like [3] (only to reset it to "duid"), or patch their sources.


[1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-core-utils.c?id=abe22689bd6d76cfe0f12dd2476b7b02929bc696#n3579
[2] https://tools.ietf.org/html/rfc4361#section-4
[3] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/00-server-dhcp-client-id.conf?id=abe22689bd6d76cfe0f12dd2476b7b02929bc696
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1579768#c42