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