摘要

  • 只有当客户端先前从 Reply 获得某配置选项、随后在 Renew、Rebind 或 Information-Request 中再次请求它，而有效的对应 Reply 又将其省略时，RFC 9915 的撤回语义才成立。
  • 该 Reply 能证明服务器这次没有再提供旧值，也规定客户端应采取的动作；它不能单独证明本机配置、使用该值的进程和实际流量已经完成切换。
  • IA 地址与前缀不适用这条规则；相同配置还可能来自路由器通告或本地策略，因此审计必须追踪来源，而不能只比较数值。

把三个包连起来，缺席才成为证据

“字段不存在”很容易被自动化系统当成布尔值，RFC 9915 第 18.2.10.5 节却要求一个有时间顺序的链条。第一份 Reply 交付过旧选项；客户端后来明确再次请求；第三份、经过验证并与交易对应的 Reply 没有携带它。缺少其中任一环，所谓撤回都可能只是观察窗口不完整。

链条成立后，客户端 SHOULD 停止使用旧配置，表现得像从未收到过该选项，并回到相关默认状态。这是明确的协议要求，却不是客户端执行回执。服务器日志可以证明发送内容，无法从远端证明配置管理器写盘成功、守护进程完成重载，或者旧连接已经消失。

因此，审计表至少需要两列。左列保存控制面的因果关系：旧 Reply、后续请求、有效的新 Reply。右列保存运行面的变化：本机配置版本、消费者进程、值的当前来源、最后一次使用旧端点的流量。只填左列就宣布“已退役”，是把规范动作误报成运营结果。

RFC 特意保留了一个很窄的例外

如果没有可行办法停止使用某值、没有其他来源，而且保留它不会产生外部影响，该值 MAY 继续存在。三个条件必须同时审查。RFC 9915 用 Client FQDN 设置的主机名举例：节点若没有合理的“取消主机名”动作，并且继续保留不影响外部主体，就可以不强行清空。RFC 4704 提供了该选项及其 DNS 更新协作背景。

NTP 是相反案例。此前由 DHCPv6 配置的 NTP 服务器地址若在符合条件的新 Reply 中消失，客户端 MUST 停止使用该地址。RFC 5908 说明该选项承载的是时间服务器位置。此时继续向旧地址发包，确实构成高价值异常信号，但仍要回答一个问题：这个地址现在是否由另一个合法来源重新提供？

RFC 9915 明确要求客户端对同类信息的其他来源保持开放。DNS 展示了这种来源并存：RFC 3646 可以通过 DHCPv6 下发递归解析器，RFC 8106 则可以通过 Router Advertisement 下发 RDNSS，并各自维护寿命。两个机制给出同一个地址，并不表示它们是同一授权。值没有变化，来源却可能已经改变。

IA 不是普通选项撤回

第 18.2.10.5 节明确排除 IA。IA_NA 地址和 IA_PD 前缀依照第 18.2.10.1 节的独立状态机处理。若监控器把“Reply 中没有某 IA”套入普通配置选项的撤回逻辑，就会制造不存在的结论，也可能忽略租约与前缀的真正时钟。

Reconfigure 也只是触发器。客户端收到并验证后，仍须进行 Renew、Rebind 或 Information-Request 交换。RFC 9915 建议记录这一事件，并允许通过实现专用接口通知应用，因为重配置可能影响应用层。但“收到触发器”“完成交换”“应用新状态”“恢复服务”仍是四件事。

退役证明必须走到运行层

完整记录应能重放：旧值何时由哪份 Reply 授予；客户端何时再次请求；哪份有效 Reply 省略了它；本机何时修改配置；哪些进程接受变化；仍存在的相同值来自哪里；旧端点流量何时终止；应用指标是否达到目标。每一步都有不同的控制者和失败方式。

RFC 8415 已包含实质相同的规则，RFC 9915 将其整理为独立小节并取代旧基础规范。文章的价值不在于宣称 2026 年突然发明了撤回能力，而在于利用更清晰的规范位置，迫使运营记录停止跨越证据层。

来源