摘要

  • Reconfigure 是要求客户端发起 Renew、Rebind 或 Information-request 的认证触发；服务器已发送并不证明客户端已有新配置。
  • 服务器收到被要求的后续请求，只表明其 Reconfigure 请求得到该类消息的回应；Reply、本地安装和网络或业务效果仍是不同事实。

最容易被放大的词是“已发送”。服务器记录了一次 Reconfigure，运维面板就可能把它显示为完成。RFC 9915 没有这样写。它把 Reconfigure 定义为服务器要求客户端开始后续交换的消息。这个要求与后来可能得到的配置内容，更与系统是否真正采用这些内容，不能合并成一条事实。

第一道界线是接受意愿和消息有效性。客户端用 Reconfigure Accept 选项告诉服务器自己是否愿意接受 Reconfigure；没有该选项时，默认是不愿意。RFC 9915 还规定：不是单播、缺少必要的服务器或客户端标识、缺少 Reconfigure Message 选项、请求类型无效，或认证缺失/校验失败的 Reconfigure，客户端都必须丢弃。因此，服务器的发送记录只证明它做出了协议规定的尝试，不能证明消息被有效接收。

即使客户端收到有效消息，下一步的结论仍然有限。Reconfigure Message 选项选择 Renew、Rebind 或 Information-request；客户端据此开始交换，并在交易进行期间丢弃额外的 Reconfigure。RFC 把原始消息称为 trigger，恰好说明它的作用是启动后续事务。它本身并没有把新的地址、前缀、解析器或其他配置值变成已生效状态。

服务器随后可以拥有一份有价值但较窄的回执。RFC 9915 说，服务器将收到所要求的 Renew、Rebind 或 Information-request 视为其 Reconfigure 请求已获满足。由此可以报告“服务器收到了所要求类型的客户端消息”。不能把它改写成“客户端已重新配置”：这份客户端消息仍是另一个交换中的请求，Reply 及其处理另有语义和记录。

三种后续交换也不能混写。Renew 和 Rebind 各自涉及自己的绑定和服务器规则；Information-request 请求的是不含地址和前缀的配置资料。它们的 Reply 才是可承载相应配置资料的对象。若要断言某个值已改变，需要关联的 Reply 与相关 option 或 IA；若要断言操作系统已安装、路由已选择、DNS 已使用、流量已到达或应用已完成，则还需要在相应位置取得独立观察。

Reconfigure 的认证并不会自动覆盖后面的边界。RFC 9915 因拒绝服务风险而要求 DHCP 认证；同样由 Volz 参与署名的 RFC 9096 提供 DHCPv6 安全与隐私改进的背景。它们证明的是特定消息边的验证条件，不是端到端安全、可用性或业务成功的总证明。

可审计的记录应保留连接键：客户端 DUID、服务器标识、Reconfigure 的发送和认证/验证结果、被要求的 msg-type、服务器收到的匹配客户端请求、Reply 及相关 option/IA 值；若主张运行结果，再附加本地安装、路由、解析、报文或应用观察。IANA 注册表可以帮助识别 DHCPv6 代码点，却不能把一条代码记录升级为后续各阶段都已发生的证据。

这正符合 Heng Lu 关于最小初始说明和运行代码优先的证据纪律：只报告真正观察到的最小事实。“服务器发出 Reconfigure”与“服务器收到被要求的客户端请求”都很有用；把它们替换为“客户端已配置”则抹去了仍须验证的环节。

Volz 是该集体标准的五位作者之一，而不是某个客户端、服务器、厂商网络或部署的所有者。RFC 的价值不在于给出成功口号，而在于拒绝让因果链中相邻的记录假装是同一份结果。

来源