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