36 chars MAC addresses on Windows Server 2012 DHCP server

The primary identifier for DHCP requests isn't actually the "MAC address" field – it's the "Client ID" field. (It's optional, but most devices include it.)

DHCP Client IDs can have several types. Most devices generate a Client ID of type 1, which just uses the same MAC address and nothing else. (So for example, instead of binding a client to MAC address AA-BB-CC-DD-EE-FF, you would bind it to Client ID "01:aa:bb:cc:dd:ee:ff".) Often this also happens in reverse – whenever a DHCP server sees a Client ID of type 1, it just shows a MAC address.

However, there are other Client ID types which are not MAC-based, for example type 0 which contains a DNS domain name, or type 255 which contains a DHCPv6 IAID+DUID (RFC4361 format). Systemd-networkd is one such DHCP client which by default sends a type-255 client ID, which some DHCP servers will show as having a ff: prefix.

(And also importantly, even if the Client ID is MAC-based, it doesn't have to match the client's actual MAC address. Some DHCP servers enforce this, but as far as I know, most do not. It's quite likely that if device A sent a client ID belonging to device B, it would receive device B's IP address assignment too.)

The DHCPv6 DUID in itself has subtypes, some of which are MAC-based and others aren't. It so happens that systemd-networkd uses type 1 (DUID-LLT), which includes the MAC address at the end – and is indeed 18 bytes (or 36 hex digits) long when combined with the IAID.

Although uncommon, this is still fully standard and nothing to be "solved". But if it creates difficulties when assigning static leases (reservations) in your DHCP server, then the device's owner can tell systemd-networkd to use a traditional MAC-based Client ID using the option:

[DHCPv4]
ClientIdentifier=mac