摘要

  • DHCPv6 客户端发现网络信息变化后，可以发送 Confirm，询问已有地址是否仍适合当前链路。请求刻意不指定服务器，掌握本链路前缀信息的服务器都可以回答。
  • Success 只表示本次提交的全部地址通过链路适用性检查。服务器会忽略 T1、T2、preferred lifetime 和 valid lifetime，因此不会产生新的租期。
  • RFC 9915 由 Tomek Mrugalski、Bernie Volz、Michael C. Richardson、Sheng Jiang 与 Timothy Winters 共同署名。它把拓扑判断、租约权限和实际运行结果分开，运营记录也应如此。

“成功”必须带上宾语

监控界面最喜欢一个没有宾语的词：成功。

设备从一个无线接入点移到另一个接入点，仍保留先前取得的 IPv6 地址。它发出 Confirm，收到状态为 Success 的 Reply。若界面只显示“DHCPv6 成功”，读者很自然会理解为地址重新分配、租约续期、网络可达都已完成。

RFC 9915 实际回答的是一个更精确的问题：这组地址是否适合客户端现在连接的链路。

客户端只有地址、没有委派前缀，并且检测到网络信息变化时，才使用这项操作。请求必须携带 Client Identifier、相关 IA 和接口上现有的全部地址，却不得携带 Server Identifier。收到一个指定服务器的 Confirm，服务器反而必须丢弃。

这不是漏掉了“原服务器”字段，而是主动划分权限。判断本地链路允许哪些前缀，不必依赖最初发放租约的数据库；任何拥有足够链路知识的服务器都可以作答。

全部地址都合适，返回 Success；只要有一个不合适，返回 NotOnLink；若服务器不知道本链路的前缀，或者请求中没有地址，它必须不回答。于是，沉默是“没有形成判断”，不是默认通过。

被忽略的四个时间字段

Confirm 里最能说明问题的，不是状态码，而是规范要求服务器忽略的字段。

客户端应把 IA_NA 中的 T1、T2，以及 IA Address 中的 preferred lifetime、valid lifetime 设为零，因为响应者不会处理这些值。地址在消息中出现，是为了让服务器检查其前缀与链路的关系，不是为了让服务器重新核准租期。

真正延长租约的是 Renew。到 T1 时，客户端向原分配服务器发送请求；服务器查找 binding，核对 IA，并可返回新的 T1、T2 与地址生命周期。原服务器到 T2 仍不响应，客户端才通过 Rebind 向任一可用服务器请求延长。

三种消息形成清楚的权力序列：

  • Confirm 把链路判断交给掌握本地拓扑的服务器；
  • Renew 先把时间延长权留给原分配者；
  • Rebind 在原路径失效后，允许其他服务器接管时间责任。

IANA 为 Confirm、Renew、Rebind 分配了不同消息类型。注册表能证明共同语言，却不能证明某次交换真的执行、响应者拥有正确前缀，或 binding 已被更新。

地址留下，不代表沙漏翻转

收到 Success 后，客户端可以继续用这些地址。若整个 Confirm 交换到期都没有收到 Reply，RFC 9915 同样建议客户端继续使用已有租约和其他配置。两条路径眼前动作相同，证据却不同。

只看接口上地址是否还在，无法判断客户端是收到肯定答复，还是在沉默后执行连续性规则。必须保存 transaction ID、响应者 DUID、状态与时间，才能还原分支。

无论 Success 还是沉默，适用的都是“最后已知生命周期”。假设请求发出时 valid lifetime 还剩 1,200 秒，十分钟后大约只剩 600 秒；Success 不会把它恢复到 1,200。只有后续 Renew 或 Rebind Reply 中的新值才会改变时钟。

RFC 4862 说明这只时钟如何约束运行。preferred lifetime 到期，地址进入 deprecated 状态：现有通信可以维持，新通信不宜再选它。valid lifetime 到期，地址变成 invalid，不应继续作源地址或目的地址。“已确认”不是第三种地址状态，更不能覆盖失效。

这种设计保护的是有边界的连续性。服务器一时无法判断时，客户端不必立即扔掉尚未到期的配置；但协议也不会凭沉默或拓扑判断创造新的使用权。

一个肯定可以压过多个否定

由于请求没有指定服务器，客户端可能收到多份 Reply。RFC 9915 的聚合规则并非多数票：只要有一个有效响应为 Success，客户端就可以使用地址，并忽略其他 NotOnLink；只有收到一个或多个响应且全部是 NotOnLink，才重新发现 DHCP 服务器。

这条规则把连续性置于一致性之前。一个掌握正确前缀信息的服务器足以让地址留下，但其他服务器的反对仍是配置漂移的证据。

若监控只记录最终布尔值，漂移就消失了。完整回执应保存每个响应者的 DUID、relay 路径、接口、所检查的地址集合、前缀配置版本与状态。一个 Success 压过两个 NotOnLink，不仅是成功率的一次加一，也可能是下一次事故的第一条线索。

检查对象还是整个地址集合。只要其中一个不适合，服务器就返回 NotOnLink，但状态码未必指出具体哪一个。丢掉输入集合后，红灯无法定位，绿灯也无法说明覆盖范围。

链路合适之外，仍有五套证据

地址属于本链路前缀，不证明没有其他设备占用它；Duplicate Address Detection 另有流程。

地址在拓扑上合适，不证明下一跳邻居可达；Neighbor Unreachability Detection 另有状态机。

地址本地有效，不证明上游存在可用路由；前缀知识不是数据包交付回执。

地址租约仍活着，不证明应用会话连续；配置层不能替传输层或应用层作证。

另一个服务器知道本链路前缀，也不证明原服务器仍保存同一 binding。拓扑知识与租约保管可以分属不同数据库。

把这些事实分开，并非削弱 DHCPv6。恰恰因为 Confirm 不吞并唯一性、可达性、路由和租约管理，它才可以作为最小机制与其他回执组合。

Tomek Mrugalski 的两条工作线

RFC 9915 于2026年1月成为互联网标准 STD 102，五位署名作者是 Tomek Mrugalski、Bernie Volz、Michael C. Richardson、Sheng Jiang 与 Timothy Winters。致谢名单还记录了更广泛的共同劳动。作者身份不赋予任何人对厂商实现或运营网络的控制权。

IETF Datatracker 显示 Mrugalski 长期参与 DHCP 相关 RFC。ISC 在2024年发布的书面专访，则介绍了他从研究工作中发展出的 Dibbler，以及后来参与开发 Kea 的经历。两份资料把规范与运行代码连在同一个人物身上，但不能证明全世界的 DHCPv6 实现都合规。

这正是本文选择他的原因。RFC 的文字把 Confirm 限定为链路判断；真正运行的客户端还必须留下自己走过哪条分支的证据。Success、全是 NotOnLink、无人回答，短时间内都可能让接口上继续显示原地址，后续结果却完全不同。

Heng Lu 的“最小初始规范”适合解释这种克制：共享满足互操作所需的最小事实，把后续决定交还给拥有上下文的参与者。“运行代码优先”则要求检验实际执行路径，而不是把消息名称当作结果。

代理问题出现在成本分配上。客户端厂商很容易上报“Confirm 成功率”；接入运营者承担保存 relay 与前缀版本的成本；租约服务维护 binding；地址到期导致的中断由用户承担。若最便宜的指标替其他层说话，报告者获得叙事权，风险却留给别人。

地址继续运行所需的六张回执

第一张记录网络变化：接口、旧新路由或链路信息、触发原因、客户端状态与时间。

第二张冻结原租约：分配服务器 DUID、IAID、地址、取得时间、T1、T2、preferred/valid lifetime 与 Confirm 前剩余秒数。

第三张记录请求：客户端 DUID、transaction ID、完整地址集合、接口、relay，以及刻意不存在的 Server Identifier。

第四张记录每一份响应：服务器 DUID、链路上下文、前缀配置版本和状态。无人回答必须记作交换超时，不能补写成 Success。

第五张记录决策分支：至少一个肯定、全部已收响应都否定，或没有有效响应；客户端继续使用还是重新发现服务器。

第六张保存后续权限证据：Renew/Rebind、新生命周期、deprecated/invalid 转换，以及独立的 DAD、邻居和路由观察。

最后可以给出一句不夸张的结论：“服务器 S 在时间 T 判断这组地址适合当前链路；原租期未变。”它比“DHCPv6 成功”多几个字，却少了一个危险的误会。

来源