摘要

  • PPP 进入网络层阶段、IPV6CP 进入 Opened，只是 IPv6 发包前必须满足的控制状态，不是全局地址和端到端可用性的收据。
  • 全局地址跳过重复地址检测，必须同时证明前缀专属于该 PPP 链路、接入路由器也不使用该前缀；Configure-Ack 不包含这两项证明。

变更窗口快结束时，监控面板亮起最后一盏绿灯：IPV6CP Opened。值班人员据此写下“IPv6 已恢复”。

真正被证明的，只是本地状态机完成了一次转换。

RFC 5072 规定 IPv6 如何承载在 PPP 上。任何 IPv6 报文能够通信之前，PPP 必须进入网络层协议阶段，IPV6CP 也必须进入打开状态。这个顺序很重要，它防止协议在链路尚未准备好时越级运行；但它没有生成全局单播地址，也没有证明路由表、远端响应或应用结果。

RFC 5072 在本文件中只定义一种 IPV6CP 选项：64 位 Interface-Identifier。每个 Configure-Request 必须带一个实例。两端提出的非零值不同，可以得到 Ack；相同就应得到 Nak 和新建议；双方都是零，则以 Reject 终止。这里的唯一性范围是这一条点到点链路。

失败路径没有隐藏的默认答案。协商不出有效标识符时，不应假设默认值，恢复程序也未由规范给出；手工配置只是可选方案之一。若设备自行生成替代值，那个行为属于实现或运维决策，不能倒写成 RFC 协商成功。

协商所得标识符用于形成本端的链路本地地址。规范随后特别提醒，不应假定全局单播地址继续使用同一个标识符。对端可以另外生成一个或多个标识符。于是，只有 IPV6CP 报文的审计记录无法回答“最后安装了哪个全局地址”。

这也是重复地址检测不能被一概省略的原因。链路本地地址由已经在两端区分开的标识符形成，在这条点到点链路上再做 DAD 属于重复验证。全局地址不同：只有两个条件同时满足，RFC 5072 才认为 DAD 可能多余。

第一，接入路由器通过 Router Advertisement 宣告的前缀必须专属于该 PPP 链路。第二，终结这条链路的接入路由器不能从这个前缀为自己生成全局地址。两项都成立时，系统管理才被建议把 DupAddrDetectTransmits 设为零。

零不是“检测通过”，而是“没有执行检测”。证明责任从邻居请求与通告报文，转移到前缀分配、拓扑隔离和路由器配置。如果自动化后来复用前缀，或者路由器开始使用同一前缀，原有 IPV6CP Ack 不会自动失效，DAD 例外的依据却已经失效。

RFC 4862 给出的常规基线更严格：单播地址在分配给接口前应执行 DAD，无论它来自 SLAAC、DHCPv6 还是手工配置，除非落入明确例外；DupAddrDetectTransmits=0 就表示不做检测。因此，选择例外时必须留下替代控制的证据。

全局地址的取得还有两条不同路径。无状态方式把路由器宣告的前缀与标识符组合；有状态方式由 DHCPv6 等服务器交付地址。前缀宣告不是租约，租约不是接口安装，接口安装也不是可达性。把这些事件写成同一个“成功”字段，会让故障定位失去层次。

标识符生成策略后来发生过正式更新。RFC 8064 更新 RFC 5072，建议稳定 SLAAC 地址采用 RFC 7217 的语义不透明方法，并反对嵌入稳定链路层地址。规范发生变化不代表每台设备都已经采用；审计需要当时实际生效的算法和软件策略。

IPV6CP 打开也不等于对端已经可靠认证。RFC 5072 把访问控制、认证和加密列为独立措施，还指出基于 MD5 的认证方法存在重放风险。控制协议状态与身份、授权、保密性从来不是同一个证明面。

一份可复核的上线凭证，应依次保存：LCP 与网络层阶段；认证授权结果；完整 IPV6CP 往返与 Ack/Nak/Reject；两端标识符及生成方法；链路本地地址；全局地址取得方式、前缀、标识符和期限；实际 DAD 结果或两项例外条件；已安装地址与路由；真实出站包的源地址；远端响应；应用结论。

这套凭证是运营建议，不是强加给 RFC 的新要求。它沿用 Heng Lu 的现实分层：配置意图、协议状态、地址状态、网络观察和业务结论可以建立证据边，但不能因为相邻就被压成同一事实。

Sources