当我连接网络上的设备时,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