Description of problem:

NetworkManager permits to configure different possible
"client-identifier" values via dhcp-client-id option: "mac",
"perm-mac", "duid", "stable", or a fixed value. However there's no
option to avoid sending the "client-identifier" at all when using
the `internal` DHCP client.

I'm requesting to add a special option 'none' as valid dhcp-client-id
value, which would instruct NetworkManager to send the DHCP request
message without including a "client-identifier" option.

• Background:

On RHEL7, NetworkManager defaults to `dhclient`. dhclient by default
is installed with an empty configuration. This results in the OS
sending a DHCP DISCOVER with no "client-identifier" (option 61) for
any network interface configured with DHCP.

On RHEL8, NetworkManager switches to the `internal` DHCP client by
default. The `internal` DHCP client can be configured with different
options to manipulate the "client-identifier", but there's no option
to avoid sending it.

When a machine that was previously running RHEL7 is reinstalled with
RHEL8+, it will now send a "client-identifier" by default where
RHEL7 didn't send any "client-identifier" at all.

Some DHCP servers will interpret this as a completely different client.
As result, the machine (same NIC, same MAC) will receive a different IP
address even when there's a previous non-expired lease for the same MAC
address on the DHCP server.

• Current workaround:

On RHEL8+, it's still possible to force `dhclient` as DHCP client,
instead of the default `internal`.

The following configuration produces that the system mimics the RHEL7
behavior (no option 61/client-identifier is sent):

• Setting "dhcp=dhclient" in NetworkManager.conf
• Adding the following to dhclient.conf:

send dhcp-client-identifier = "";

While `dhclient` seems still available on RHEL9, according to [1] the
ISC DHCP client development as ended as of 2022, so I understand that
it will be eventually removed from RHEL.

See "Additional info" below and the RFE notes for further details.

[1] https://www.isc.org/dhcp/

Version-Release number of selected component (if applicable):

No specific version.

How reproducible:

Always.

Steps to Reproduce:

1. Run a DHCP server with a basic configuration
$ sudo ip link add link enp7s0 name vlan1234 type vlan id 1234
$ sudo ip add add 10.23.4.1/24 dev vlan1234
$ sudo ip link set dev vlan1234 up
$ sudo stdbuf -o0 tshark -i vlan1234 -Y "dhcp.option.dhcp eq 1" -V -O dhcp 2>/dev/null| egrep --line-buffered "Message type|Option" -A 2 &
$ sudo dnsmasq dC <<EOF
interface=vlan1234
port=0
dhcp-range=10.23.4.100,10.23.4.200,255.255.255.0,infinite
dhcp-option=3,10.23.4.1
EOF

2. Configure a RHEL7 host with DHCP

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.9 (Maipo)

$ ip l show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 56:6f:c1:3e:00:0c brd ff:ff:ff:ff:ff:ff

$ sudo nmcli con add type vlan con-name vlan1234 ifname vlan1234 dev eth0 id 1234 connection.autoconnect no
Connection 'vlan1234' (50da750d-dc73-4440-824a-fc8fba7cfe92) successfully added.

$ sudo nmcli con up vlan1234

sudo $ ip l show dev vlan1234
8: vlan1234@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 56:6f:c1:3e:00:0c brd ff:ff:ff:ff:ff:ff

DHCP Discover details:

Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Option: (53) DHCP Message Type (Discover)
Length: 1
DHCP: Discover (1)
Option: (12) Host Name
Length: 3
Host Name: v79
Option: (55) Parameter Request List
Length: 19
Parameter Request List Item: (1) Subnet Mask
Option: (255) End
Option End: 255
Padding: 000000000000000000000000000000000000000000000000000000000000

3. Recreate the interface, or install RHEL8 on the same machine:

DHCP Discover details:

Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Option: (53) DHCP Message Type (Discover)
Length: 1
DHCP: Discover (1)
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Option: (55) Parameter Request List
Length: 18
Parameter Request List Item: (1) Subnet Mask
Option: (57) Maximum DHCP Message Size
Length: 2
Maximum DHCP Message Size: 576
Option: (12) Host Name
Length: 3
Host Name: v81
Option: (255) End
Option End: 255

NOTE: dnsmasq in this case seems smart (or buggy?) enough to provide
the same lease for the same MAC address even when the second request
includes a client-identifier.

Actual results:

Option 61 / client identifier is always sent

Expected results:

The `internal` DHCP client should have an option to avoid sending Option
61 / client identifier.

Additional info:

The ISC DHCP client development has ended as of 2022 [1]:

ISC has ended development on the ISC DHCP client as of early 2022. This
client implementation is no longer maintained and should not be used in
production any longer.

While I see `dhclient` still available on RHEL9, my understanding is
that it will be eventually deprecated and removed.

While this behavior of the DHCP server doesn't seem to reproduce on
all DHCP servers, I think it's reasonable to have an option to
instruct the `internal` DHCP client to avoid sending option 61.

According to RFC2131 [2], a "client-identifier" is not mandatory:

DHCP defines a new 'client identifier' option that is used to pass an
explicit client identifier to a DHCP server. This change eliminates
the overloading of the 'chaddr' field in BOOTP messages, where
'chaddr' is used both as a hardware address for transmission of BOOTP
reply messages and as a client identifier. The 'client identifier'
is an opaque key, not to be interpreted by the server; for example,
the 'client identifier' may contain a hardware address, identical to
the contents of the 'chaddr' field, or it may contain another type of
identifier, such as a DNS name. The 'client identifier' chosen by a
DHCP client MUST be unique to that client within the subnet to which
the client is attached. If the client uses a 'client identifier' in
one message, it MUST use that same identifier in all subsequent
messages, to ensure that all servers correctly identify the client.

However RFC4361 [3] superseding RFC2131 in section 6.1 seems to suggest
that DHCPv4 clients conforming RFC4361 must send a client-identifier:

DHCPv4 clients MUST send a 'client
identifier' option containing an Identity Association Unique
Identifier, as defined in section 10 of RFC 3315, and a DHCP Unique
Identifier, as defined in section 9 of RFC 3315. These together
constitute an RFC 3315-style binding identifier.

Later on the same document states the following change from RFC2131:

"The client MUST explicitly provide a client
identifier through the 'client identifier' option. The client MUST
use the same 'client identifier' option for all messages."

• Summary:

While it seems that DHCPv4 clients strictly following RFC4361 must
provide a "client-identifier" via option 61, this seems to
break previous leases obtained via RFC2131 DHCPv4 clients on certain
environments/DHCP servers when the DHCP client software is updated.

I think it's reasonable to have an option so the user can control
whether the "client-identifier" field is sent. This would make the
transition to more recent RHEL releases smoother.

[1] https://www.isc.org/dhcp/
[2] RFC2131 https://www.rfc-editor.org/rfc/rfc2131
[3] RFC4361 https://www.rfc-editor.org/rfc/rfc4361