摘要

  • 包含 IA_PD 和 IAPREFIX 的有效 Reply 证明前缀绑定及其生命周期，不会直接观测路由表、转发表或客户 LAN 的可用性。
  • 验收证据应把 DHCPv6 事务、接入侧 RIB/FIB、CE 状态、LAN 前缀通告和针对当前前缀的双向探测绑定到同一代状态。

设备页面一片绿色：运营商下发了 /56，租约计时器正常，DHCPv6 客户端报告成功。与此同时，局域网终端无法建立 IPv6 连接，外部探针发往该地址块的流量也到不了客户边缘。Reply 本身无法指出断点发生在哪里。

RFC 8415 对 Reply 的定义很具体。服务器用它在多类交换中返回租约和配置。对于前缀委派，IA_PD 带有一个或多个前缀以及 T1、T2；每个 IA Prefix 还带有首选生命周期和有效生命周期。这些字段回答“客户可以在多长时间内使用哪个前缀”。

它们没有回答“报文是否已经能够转发”。

委派之后还有两条链

RFC 8415 明确说明，前缀委派机制本身并不要求客户端转发目的地址不是自身的报文。服务器返回前缀后，客户端才负责把它划分成更长的子网、分配到下游接口，并在相应链路发送路由器通告。这些动作发生在 Reply 之后。

运营商接入侧也需要独立完成路由编程。服务器通过 relay 与客户端通信时，RFC 8415 指出，可能需要其他协议或带外方式，为客户端流量经过的路由器配置委派前缀的路由。因此，完全合规的 DHCPv6 交换可以与缺失、陈旧或指向错误会话的路由同时存在。

RFC 7084 又把 CE 的职责拆开：支持前缀委派、接受与提示长度不同的前缀、维持 WAN 路由、为 LAN 选择 /64 并通告它。它们有关联，却不是一个原子事务。规范还要求未分配到 LAN 的委派地址范围指向空目的地并被丢弃；获得 /56 不能被解释为其中任意地址都可达。

证据必须跟随当前一代状态

第一段记录应保存客户端和服务器标识、事务上下文、IAID、前缀、长度、状态、T1、T2、两种有效期和接收时间。第二段保存负责接入路由的设备、下一跳、RIB/FIB 代次以及绑定的用户会话。第三段保存 CE 的 WAN 默认路由、选定的 LAN /64、转发代次和 RA 中的前缀生命周期。

最后才是业务观测。探测地址必须位于实际分配的 LAN 子网，测点必须具名，并分别记录去程和回程。脱离当前前缀和代次的一次 ping，可能只命中了旧状态或缓存。

RFC 9096 说明了为什么收据必须过期：WAN 侧 IAID 默认应跨重启保持稳定，下游通告的生命周期不得超过委派前缀的剩余生命周期，陈旧配置必须被显式处理。Renew、Rebind、重启、前缀变化、路由替换或有效期边界都会使上一代证据失效。

来源