摘要

  • DHCPv6 前缀委派把一段前缀的使用责任交给请求路由器，却不会描述其后的网络拓扑。
  • 请求路由器必须把租约变成稳定的子前缀和受约束的生命周期；CE 则必须让每份租约与正确下一跳路由保持一致。
  • 运营团队应以“委派到路由”回执，把协议状态同双向报文证据连接起来。

租约显示绿色，局域网却一片黑暗

设想客服控制台显示 IA_PD 交换成功：下游路由器拿到了前缀，首选和有效生命周期正常递减，也没有 DHCPv6 错误。然而，发往该路由器后方服务器的报文在客户边缘设备处消失。CE 从未把委派前缀指向下游路由器，或者在客户端停止使用前缀之前就过早删除了路由。

两个界面都可能如实反映各自状态。DHCPv6 可以维持一份有效委派，而转发路径依然不完整。错误不在租约格式，而在于把租约成功误当成地址池预留、链路分配、路由通告、转发编程和可达性的共同证明。

RFC 8415 清楚划出了边界。前缀委派适用于委派路由器不了解请求路由器后方拓扑的场景。服务器选择前缀并返回，客户端随后对它负责，可以再划分子网、分配给接口并在链路上通告。这些都是委派之后的动作，不是 IA_PD 成功状态本身携带的事实。

这是一项有时间边界的责任转移

有用的运营单位不是“前缀存在”，而是客户端身份、IAID、精确前缀与长度、服务器、T1、T2、首选生命周期、有效生命周期和观察时间组成的元组。Renew 可能延长时间，RFC 8415 也允许服务器改变返回的前缀集合，或以零生命周期收回不再合适的前缀。因此，应保存完整响应内容，而不是一个绿色标签。

生命周期还具有上下级约束。由委派前缀派生的地址或子前缀，其通告的剩余生命周期不能超过父前缀。否则，上游授权已经结束，局域网中的主机仍会把地址视作可用。用户看到的像是路由故障，真正破裂的却是时间边界。

RFC 9818 为在 LAN 侧继续委派的 CE 增加了要求：内部接口必须支持 IA_PD，从可用前缀池进行分配，容量不足时记录管理错误；没有策略或拓扑变化时，不得随意改变链路前缀。尤其重要的是，CE 必须用租约及其下一跳动态更新本地路由表，并在租约释放或到期时删除相应路由。

这条链上仍有多个独立故障点：上游块不足、子前缀预留不一致、下游未通告、租约没有对应下一跳、子生命周期过长，以及去程与回程经过不同策略。只重新查看 DHCP Reply，无法关闭任何一个缺口。

从边界两侧建立回执

委派侧记录服务器身份、客户端 DUID、IAID、前缀、事务时间、T1/T2、两种生命周期，以及事件属于首次分配、Renew、Rebind、Release 还是到期。请求侧记录实际分配给各链路或路由器的子前缀、继承时间和做出决定的配置版本。

随后附上转发证据：CE 上每个子前缀的路由、下一跳、接口、安装时间、可能抑制它的策略，以及删除它的事件。下游则记录本地路由、路由器通告和预期地址选择状态。最后，从业务边界执行双向报文测试。CE 自己发出的一个 ping 无法覆盖 DNS、有状态过滤、源地址选择或非对称回程。

回执应在四个时刻重新核验：首次委派、续租、策略或拓扑变化、释放或到期。两个时间点出现相同前缀字符串，并不意味着下一跳、地址池、生命周期、通告和过滤状态相同。

不扩张协议的事实边界

这份回执不会把 DHCPv6 变成拓扑协议，而是尊重协议分工，把不同系统掌握的证据拼接起来。它也不解决多运营商网络的源地址选择和路由策略。RFC 9818 因路由、配置和策略的复杂性而明确排除了多前缀、多提供商场景；这样的网络必须另外提供出口、回程和故障域证据。

来源