摘要

  • 在常规地址分配中，DHCPACK 表示服务器落实绑定；客户端还须确认地址没有冲突，才进入 BOUND。它授予的是限时使用，不是所有权。
  • 租期把权限分成几个阶段：T1 先找原服务器续租，T2 可向其他服务器重绑定；若到期仍未获得新确认，客户端必须停止使用地址并返回 INIT。
  • 对 DHCPINFORM 的 DHCPACK 根本不分配地址，说明离开交换流程与字段，不能仅凭报文类型推断发生了什么。

一次确认怎样看起来像永久占有

设备刚接入网络时没有可用的 IPv4 配置。它广播发现请求，收到报价，选择其中一个方案，再等待 DHCPACK。几秒后，地址写入接口，应用开始通信，日志也把活动挂在这个地址名下。用户看到的是“网络给了我一个地址”。

RFC 2131 描述的却是客户端与配置参数之间的租约绑定。被选中的服务器提交这项绑定，客户端仍需在本地链路上检查该地址是否已经被使用；如果发现冲突，它应发送 DHCPDECLINE，并重新开始。服务器数据库里的肯定答案，并不会抹去链路现场的反证。

RFC 2131 的作者是 Ralph Droms。IETF 人物页还记载，他在 1989 年组织了设计 DHCP 的工作组。准确的说法是，他推动动态主机配置形成了具有明确状态和时间边界的标准交换；这并不意味着后续每一项扩展、实现与运营决定都可归于他一人。

租约的权限里自带一只钟

客户端可以提出想要的地址，也可以建议租期，但服务器无须照单接受。DHCPACK 传回的是服务端政策实际同意的配置。地址由谁使用、可以用到何时，是同一项决定的两个部分。

通常到租期一半的 T1，客户端进入 RENEWING，定向向原服务器发送 DHCPREQUEST。续租未果时，T2 通常位于租期的八分之七，客户端转入 REBINDING，把请求扩大到任何能够响应的服务器。T1 和 T2 都是相对时间，服务器也可以明确提供不同取值。

到期是硬边界。若租期结束前没有新的 DHCPACK 延长授权，RFC 2131 要求客户端立即停止用该地址处理网络通信，放弃配置并回到 INIT。原地址可以重新分配给别人。一个明确规定使用权何时终止的协议，很难同时被解释成永久产权登记。

“无限租期”依然不是产权证

RFC 2132 的 IP 地址租期选项允许用全一比特表示无限租期。长租期乃至无限租期确有运营价值：地址更稳定，控制报文更少，某些设备可以长期保持相同配置。在有效租期内，DHCPACK 也是管理域内真实有效的授权，不是可有可无的提示。

但“没有预定到期时刻”与“拥有地址”不是一回事。这个特殊值不会认证终端背后的人，不会建立跨网络的权利，也不会阻止管理员改变地址池或网络架构。把它叫作所有权，是给一个时间字段加入规范从未表达的法律与身份含义。

RFC 5227 保留了另一条证据边界。主机使用 IPv4 地址前会在链路上探测冲突，发现占用时还须防御或放弃。冲突检测不取代 DHCP 服务器，却提醒我们：租约数据库并不必然完整反映介质上的实际状态。控制面的允许与链路上的可用，需要合并判断。

也有完全不分配地址的 DHCPACK

DHCPINFORM 是最直接的反例。已经通过其他方式配置好地址的客户端，可以向 DHCP 请求额外的本地参数。服务器仍以 DHCPACK 作答，但 RFC 2131 明确规定：这次交换不分配地址、不检查已有绑定、不给 yiaddr 填值，也不附带租期选项。

同一报文类型因而参与两种本质不同的动作。在分配状态机里，它可以确认绑定；在 INFORM 交换里，它只是返回配置。资产系统若把抓到的每一个 DHCPACK 都记成“该服务器把该地址分给该客户端”，会凭一条看似方便的规则制造错误来源记录。

RFC 6842 针对报文对应关系作了改进，要求服务器在规定情形下，于 DHCPOFFER 与 DHCPACK 中回显客户端标识符。这让客户端更容易确认回复属于哪次交换，却没有把技术标识符变成人的身份认证，更没有让它成为所有权凭证。

服务器能证明的是自己的绑定状态

RFC 4388 的 Leasequery 把服务器视角表达得格外清楚。服务器可把地址报告为 ACTIVE、UNASSIGNED 或 UNKNOWN，并对有效租约给出剩余时长。查询只读取状态，不会改变绑定。回复对这台服务器的租约数据库具有权威性，却不一定涵盖网段上的每个设备、数据包与冲突现象。

因此，地址分配证据与网络行为归属必须分开。完整租约记录可以支持这样一项结论：某 DHCP 服务在特定时段授权某客户端标识符使用一个地址。单靠它不能证明是谁在操作设备，不能证明所有源自该地址的流量都来自同一设备，也不能把时段内的结论外推到租约前后。

这不是削弱 DHCP 证据，而是给它标出可验证的边界。服务器历史、客户端标识符、中继信息、二层观察、冲突检测和同步时钟共同使用，才能形成更强的叙述。问题不在于相信 DHCPACK，而在于让它回答设计范围之外的问题。

资料来源