当我连接网络上的设备时，Windows Server 2012 上运行的 DHCP 服务器有时会正确报告其 MAC 地址（12 个字符），但有时会报告带有随机前缀的 36 个字符长的 MAC 地址。
为什么会发生这种情况？我该如何解决？
正如评论中提到的，可能是 ID，但它的最后 12 位数字始终等于机器的 MAC 地址。在这种情况下：为什么同一台设备有时显示其 MAC 地址，有时显示此 ID（以其 MAC 地址作为后缀）？
答案1
DHCP 请求的主要标识符实际上不是“MAC 地址”字段，而是“客户端 ID”字段。（它是可选的，但大多数设备都包含它。）
DHCP 客户端 ID 可以有多种类型。大多数设备都会生成类型 1 的客户端 ID，该 ID 只使用相同的 MAC 地址，不包含其他任何内容。（例如，您不会将客户端绑定到 MAC 地址 AA-BB-CC-DD-EE-FF，而是将其绑定到客户端 ID“01:aa:bb:cc:dd:ee:ff”。）通常，这种情况也会反过来发生 - 每当 DHCP 服务器看到类型 1 的客户端 ID 时，它只会显示 MAC 地址。
但是，还有其他客户端 ID 类型不是基于 MAC，例如包含 DNS 域名的类型 0，或包含 DHCPv6 IAID+DUID（RFC4361 格式）的类型 255。Systemd-networkd 就是这样一种 DHCP 客户端，它默认发送类型 255 的客户端 ID，一些 DHCP 服务器会将其显示为具有前缀ff:。
（同样重要的是，即使客户端 ID 是基于 MAC 的，它也不必与客户端的实际 MAC 地址相匹配。一些 DHCP 服务器强制执行此操作，但据我所知，大多数服务器都不会这样做。如果设备 A 发送了属于设备 B 的客户端 ID，它很可能也会收到设备 B 的 IP 地址分配。）
DHCPv6 DUID 本身有子类型，其中一些基于 MAC，而另一些则不是。碰巧的是，systemd-networkd 使用类型 1 (DUID-LLT)，它在末尾包含 MAC 地址 - 与 IAID 结合时确实有 18 个字节（或 36 个十六进制数字）长。
虽然不常见，但这仍然是完全标准的，没有什么需要“解决”的。但如果它在 DHCP 服务器中分配静态租约（预留）时造成困难，那么设备所有者可以使用以下选项告诉 systemd-networkd 使用传统的基于 MAC 的客户端 ID：
[DHCPv4]
ClientIdentifier=mac