摘要

  • DHCPv6 Reconfigure 不是配置下发包，而是要求已经表示愿意接受该机制的客户端再发起一次 Renew、Rebind 或 Information-request。新的运行状态只能由随后完成的交换和客户端执行产生。
  • RFC 6977 明确允许 Reconfigure-Reply 返回 Success，同时把全部请求客户端列为不会收到 Reconfigure 的对象。请求受理、对象选择、触发送达、认证、后续交换、状态安装和业务连续性需要分别取证。

最先变绿的是控制台

设想一个接入网络：中继获知某条链路的配置来源发生变化，于是把链路地址和若干客户端 DUID 放进 Reconfigure-Request。服务器很快回送带有 Success 的 Reconfigure-Reply，运维界面随即把任务标成完成。

此时没有任何客户端改变。

服务器可能没有足够的绑定记录，也可能发现某些客户端从未发送 Reconfigure Accept。部分触发报文可能因限速仍在队列中；已经发出的报文可能没有通过认证；某个客户端或许刚刚开始 Renew，但尚未获得 Reply。即便 DHCP 客户端已经安装了新状态，应用仍可能持有旧地址和旧连接。

如果绿色状态只表示“服务器处理了中继的请求”，它没有说谎。危险来自权限膨胀：一个边界上的确认，被拿来替之后所有参与者证明已经完成。

RFC 6977 对这一点十分直接。成功回复中的客户端列表，表示服务器不会向这些客户端发送 Reconfigure。即使全部请求对象都在列表中，服务器仍可返回 Success。这不是语义漏洞，而是有意拒绝让中继—服务器确认冒充客户端执行回执。

当前标准把它限定为触发器

RFC 9915 已成为 DHCPv6 的现行基础规范，并取代 RFC 8415。IANA 的 DHCPv6 参数登记把 RECONFIGURE 记为消息类型 10。这个公共机制承担的任务很窄：请一个特定客户端开始下一次 DHCPv6 交换。

Reconfigure 必须单播，携带服务器标识、相符的客户端标识、可接受的认证信息和 Reconfigure Message 选项。该选项只能选择 Renew、Rebind 或 Information-request。新地址、前缀、DNS 参数等普通配置不能塞进触发报文；它们属于随后交换中的 Reply。

因此，服务器拥有“请求开始对话”的权限，却没有直接改写客户端状态的权限。客户端先验证身份、认证和防重放值，再构造所要求的请求。服务器依据当时的状态生成 Reply。客户端实现决定安装什么，运行方再观察结果是否真正进入业务。

抓到一个有效 Reconfigure，只能证明某个服务器向某个标识发送了一个合法触发。它不能证明那个标识仍对应链路上的当前设备，不能证明交易完成，更不能证明应用已经迁移。

客户端是否加入，必须保持可见

客户端通过 Reconfigure Accept 表示愿意接收触发。没有该选项，服务器就不能把它当作参与者。这样的客户端仍然完全可以通过正常租期、客户端主动发起的 Renew，或普通 Information-request 获得变化。

这一设计让可选能力不会暗中变成强制要求，同时给运营带来真实约束。若只有七成终端接受 Reconfigure，网络就只有七成可被这种方式加速，另外三成需要安全的时间路径。不能只统计已经接受的终端，再宣称整支设备群已经可控。

RFC 8947 所讨论的小型设备也提醒我们：认证计算和持久状态都有成本，受限实现可以合理地省略某些功能。运营者可以偏好更快的变化，却不能把偏好伪装成协议保证。

认证界定发送者，不替执行结果背书

Reconfigure Key Authentication Protocol 在初始 Reply 中向客户端交付 128 位密钥，之后使用 HMAC-MD5 验证 Reconfigure。初次密钥交付沿 DHCPv6 路径以明文进行，这是威胁模型的一部分，不能因为后续报文“已认证”而被忽略。

防重放值需要单调递增，服务器重启后也必须维持连续性。一个故障切换节点可能恢复了租约，却丢失密钥或计数器；它知道希望联系哪些客户端，但无法生成客户端肯接受的触发。反过来，复制全部密钥虽然提高可用性，也扩大秘密暴露范围。

认证回答的是一个窄问题：该报文是否来自拥有相应密钥的服务器权限，且不像旧报文重放。它不回答中继是否选对链路、服务器是否选对客户端、后续 Reply 是否正确，也不回答应用是否安全使用新状态。

“认证通过”不能成为“端到端正确”的代名词。密码学的作用是明确一个边界，而不是消除所有边界。

中继提出候选，服务器保留决策

RFC 6977 在中继与服务器之间定义 Reconfigure-Request 和 Reconfigure-Reply。中继可以提交受影响的链路地址和客户端标识，但服务器仍决定是否信任该中继、状态是否充足、哪些客户端有资格接收，以及以多快的速度执行。

服务器默认不接受这种请求，来自未知中继的请求应被丢弃。RFC 8213 可用 IPsec 保护中继—服务器消息。安全通道能够确认通道对端和保护传输，却不能证明中继所报的人群就是正确人群。被攻陷或分类错误的中继，完全可能通过受保护通道提交一组错误对象。

中继重传请求时可以移除客户端，不能新增客户端。这种不对称性防止活动中的请求悄悄扩大，但它没有替服务器完成链路、DUID、绑定和来源权限的核验。

多服务器环境更复杂。同一请求可能进入拥有不同状态或政策的服务器，得到不同选择。多条 Success 不能相加成统一事实；每一次触发都要与发送它的服务器、目标客户端和后续交易建立关联。

至少保留六层事实

可信的操作记录不应只有“成功/失败”一栏，至少应分别保留：

  1. 中继观察到了哪个来源变化，并提出哪些候选客户端；
  2. 哪个服务器接受或拒绝了中继请求；
  3. 服务器选择了哪些客户端，并实际发出多少触发；
  4. 哪些客户端通过认证并发起指定请求；
  5. 哪些交易获得并接受了新的 Reply；
  6. 哪些状态已安装，哪些应用路径已验证。

每层证据来自不同位置：中继日志、Reconfigure-Reply、选择记录、发包计数、认证结果、交易标识、客户端状态与业务探测。相邻两层之间的差值不是需要隐藏的噪声，而是故障位置。

如果 Success 把所有客户端都列为排除对象，说明请求处理成功、覆盖率为零。触发后看见 Renew 却没有 Reply，说明启动有效、交易失败。客户端报告安装完成而应用仍绑定旧地址，则说明 DHCP 状态改变、业务迁移没有完成。只有分层记录才能让这些事实同时成立而不互相冲突。

限速是语义的一部分

一次来源事件可能扇出成大量单播触发，再产生同样规模的 DHCPv6 交换。RFC 6977 要求服务器能够限制这项工作，避免 Reconfigure 挤压正常分配、更新和恢复流量。

服务器现在接受请求，不意味着现在已经向所有客户端发包。队列使时间本身成为证据：需要分别记录来源变化、选择、排队、发送、客户端请求、Reply 和安装的时间。只监控 Reconfigure-Reply 延迟，相当于只测量序列的开头。

安全政策应规定每个来源事件、每次请求、每个服务器时间窗和每个变更窗口的上限，还要限制重试。无限重试会把离线人群变成永久负载，并可能扩大原本试图修复的事件。

限速还必须与旧配置的安全重叠期相匹配。若队列耗时超过旧状态仍可使用的时间，合规的延迟也会变成故障。容量预算与回退窗口不能由不同团队各自假设。

恢复的租约不是此刻的终端

RFC 5007、RFC 5460 和 RFC 7653 的 Leasequery、Bulk Leasequery、Active Leasequery 能帮助服务器恢复或持续同步租约视图。它们降低故障切换后的无知，却不能把历史观察变成实时真相。

恢复记录中的客户端可能已经离开链路；活动流可能发生延迟、乱序或需要重新同步；绑定得到恢复时，Reconfigure 密钥与防重放状态不一定随之恢复。每一份状态都应携带来源、时间和完整性说明，广泛触发前还要用运行证据确认对象。

RFC 9243 的 YANG 模型提高了 DHCPv6 服务配置的可见性。这种控制面描述能解释服务器意图，却仍不是终端执行结果。模型、记录和现场状态分别回答不同问题。

重新编号把误判代价放大

RFC 6879 描述企业 IPv6 网络的重新编号场景。Reconfigure 可以让部分客户端更早回到服务器，却不会消除新旧前缀共存的必要，也不会让未接受该能力的终端或保留旧地址的应用突然消失。

可逆计划应保留明确的新旧重叠时间，持续寻找被排除、延迟和应用未迁移的人群，只有观察满足条件后才撤去旧状态。如果因为看到中继—服务器 Success 就提前缩短重叠期，那么限速、丢包和自愿不参与都会被转换成中断。

Reconfigure 是迁移计划中的可选加速器，不是立即切断旧配置的许可证。

公共机制应当知道自己不知道什么

公共规范适合定义报文格式、标识、加入信号、认证、防重放与三种可互操作的后续请求。它不掌握触发变化的商业事件，不知道某条应用路径的风险，也不能替部署方决定信任哪个中继、一次触发多少客户端或何时撤销旧状态。

中继决定什么现场事件值得提出请求；服务器决定来源信任、状态匹配、对象选择和负载预算；客户端按照自身实现执行；运营者决定变更窗口、业务保护、证据保留和回退。公共层保持最小，各参与方保留未来选择。

这正是 Heng Lu 所强调的运行代码优先。规范、建议、记录和确认可以描述现实，却不能凭自身创造现实。只有代码完成、运行者验证并在实际使用中观察到的变化，才是下一状态。

Minimum Initial Specification 给出最小可互操作触发；Localized Future Decision 把中继信任、选择策略、实现与业务安全留给本地；Voluntary Adoption 则在客户端可以不发送 Reconfigure Accept 这一点上保持清晰。标准负责提供触发，运行系统负责决定它是否成为事实。

来源