摘要

  • RFC 9762 把一个正向、按前缀生效的偏好放进 IPv6 路由器通告：支持该机制的主机应先尝试 DHCPv6-PD，而不是马上从同时允许 SLAAC 的 PIO 中生成新地址。
  • P=1 不是租约。严谨的结果链必须分别证明 RA 到达、客户端启动 DHCP、服务器返回合适前缀、中继安装绑定与路由、主机选择正确源地址和首跳，最后才是业务流量完成。
  • P 的缺席没有反向含义；它不能证明 DHCPv6-PD 不存在。相反，收到 P 也继承 RA 的信任边界，伪造或振荡的通告可能延迟配置并制造 REBIND 负载。

无线接入网切换策略后的第一张截图很好看：抓包里，PIO 的 P 位已经是 1；新接入的主机也没有再从共享前缀生成 SLAAC 地址。配置、报文和客户端行为似乎完全一致。

故障单却写着：主机没有可用的全局 IPv6 地址。

这不是 RFC 9762 自相矛盾，而是一个证据边界被跨越了。该 RFC 让网络在主机作出地址选择之前表达“优先走 DHCPv6 前缀委派”的意图。它并没有把后续的 DHCP 会话、前缀池、中继绑定、路由安装和实际转发塞进这一个比特。

如果监控平台把 P=1 翻译成“前缀委派可用”，下一步往往会把这个绿色状态继续借给“前缀已交付”和“业务已恢复”。真正从链路上看到的事实要窄得多：某个接口收到一份 RA，其中某个 PIO 描述一个前缀并设置了一个标志；一类支持该机制的客户端因此获得了启动另一个协议的理由。

它必须比 SLAAC 地址更早到达

P 标志解决的首先是时间问题。主机若先依据共享链路前缀生成 SLAAC 地址，应用很快就会使用它。稍后若又取得独享的委派前缀，主机只能在两种并不理想的结果之间选择：保留两套地址，削弱每设备一个前缀带来的扩展性；或者撤销先前地址，让已经建立的连接承受中断。

RFC 9762 因而把偏好放在 PIO 内。对于实现 DHCPv6-PD 的客户端，P=1 表示：在这个具体的前缀语境里，应优先采用 RFC 9663 所描述的每客户端委派前缀模式，而不是从共享前缀再取得一个独立地址。偏好按 PIO 生效，并非接口上的永久总开关。同一个 RA 可以让全局前缀走 PD，让另一个 ULA 前缀继续使用 SLAAC；多宿主环境里的不同上游也可以表达不同选择。

P 位与 RA 中的 M、O 位独立。一些不认识 P 的既有设备只有在 M 或 O 置位时才会启动 DHCPv6-PD，因此要服务这些设备，网络可能还需要设置 M 或 O。路由器必须让操作者分别配置 P 和 PIO 的 Autonomous A 位；启用 P 不能暗中替操作者改写 A。

这种独立性保留了退路。网络可以同时通告 P=1 与 A=1。支持 RFC 9762 的主机在执行偏好时应把 A 当作未设置，不从该 PIO 生成新地址；如果后来得不到适合 SLAAC 的委派前缀，客户端又可以在本地策略允许时停用该接口上的 P 处理，回到 SLAAC 或 IA_NA。RFC 4862 提供被更新的无状态地址自动配置规则，RFC 4861 提供 RA 与邻居发现的基础。新比特改变其中一个选择，却没有废除旧机制。

客户端保存的是一张有寿命的偏好表

实现不能只看“最后收到的一个 P 值”。每个接口都要维护一张列表：所有从 P=1 的 PIO 中收到、且首选寿命仍非零的前缀都在其中。当列表长度从零变成一时，客户端应开始请求 DHCPv6 前缀，除非请求早已进行。首选寿命自然到期，或同一前缀收到首选寿命为零的新 PIO，都会将它移出列表。

列表从非空降到零时，规则留有条件：只有在没有其他理由继续 PD 时，客户端才应停止请求或续租。已经取得的委派前缀不会因为 RA 偏好消失而被立刻删除。RA 可以撤回邀请，却没有权限改写 DHCP 服务器已经授予且仍在寿命内的租约。

如果主机已有委派前缀，而 P 列表又发生增删，该变化通常被视为新的配置信息并触发 REBIND；列表变空是例外。RFC 8415 定义真正的 DHCPv6 状态机。随后发生的 Rebind/Reply 有自己的服务器、事务、IA_PD、状态码和寿命，不能由先前 RA 代签。

因此，第一组运维记录至少要拆成两行。第一行写 RA 源、接口、PIO 前缀、P/A/L 位、首选寿命以及列表世代。第二行写客户端是否真的发出 Solicit 或 Rebind、何时发出、由什么本地策略触发。“看到了标志”和“状态机已经行动”紧邻，却不是同一事实。

Reply 到达也不自动成为可用地址

按该模式请求 PD 时，客户端必须给出足够短、可以用来形成 SLAAC 地址的前缀长度提示。服务器的回答依然可能不合适。若委派前缀长到无法用于 SLAAC，客户端必须忽略；若前缀更短，则可以接受并在内部划分出适当的更长前缀。

原始 RA 无法预言这些结果。DHCP 服务器可能不可达，地址池可能耗尽，策略可能拒绝客户端，Reply 可能只带失败状态，返回的长度或寿命也可能无法接受。客户端还可能在一次有界但失败的尝试后禁用 P 处理，并按允许的方式退回 SLAAC 或 IA_NA。

正因为规范允许失败与回退，把 P 位直接显示成“委派完成”就会失真。完整证据应把请求中的 IA_PD 与长度提示，连接到实际选中的服务器或中继、Reply 状态、返回的 IAPREFIX、首选与有效寿命，以及客户端最终的接受或拒绝判断。

反方向也不能误读。RFC 9762 明确规定，P 是纯正向信号：没有任何 PIO 设置 P，并不表示 DHCPv6-PD 不可用。按显式配置运行的客户端，或 RFC 7084 所描述的一类 CE 路由器，可能完全不需要这份邀请。“没有观察到偏好”不等于“服务不存在”。

租约与路由是两个账本

RFC 9663 描述了每客户端前缀真正发挥作用的条件。服务器委派前缀后，首跳路由器应安装一条指向客户端链路本地地址的路由。基础设施把该前缀视作 off-link，不再为客户端创建的每一个全局地址维护邻居缓存。主机可拥有多个地址或把地址空间交给容器、虚拟机和下游接口，而网络主要按每台设备维护一条路由。

这个收益依赖客户端之外的状态。RFC 8987 要求委派中继维护租约、下一跳和本地路由，随 DHCP 寿命更新入口过滤，并在重启或链路抖动时遵循明确的保留和清理规则。主机抓到一份成功 Reply，不能证明中继已经装好路由；一台首跳设备上存在路由，也不能证明冗余设备拥有同一绑定；控制面的路由条目更不能证明数据面真的按预期转发。

客户端自身也承担约束。委派前缀在取得它的接口上是 off-link。主机不得把目的地址落在该委派前缀内的包重新送回取得前缀的接口，否则可能形成环路；一条高度量的丢弃路由是可选防护。客户端从该前缀形成地址后，源地址选择应按照 RFC 6724 把它们与接收委派的接口关联。

多宿主让关联更具体。主机应记录提供 Reply 的 DHCP 服务器或中继的链路本地地址；冗余设备返回同一前缀时，可能需要保留多个地址。RFC 8028 说明了多前缀环境中源前缀与首跳选择为何不能随意分开。前缀本身正确，交给不匹配的路由器，业务仍可能失败。

于是，能承担问责的链条应是：RA 收据、P 列表世代、DHCP 请求、被接受的 Reply、租约、中继绑定、下一跳路由、入口过滤、地址形成、源地址选择、首跳选择、报文送达、应用完成。任何一格变绿，都只证明这一格。

每客户端前缀也改变了同链路通信

独享前缀让其他客户端的全局地址成为 off-link。两台接在同一广播域的主机互发流量时，包起初会送到默认路由器。路由器可以用 ICMPv6 Redirect 引导更直接的路径，RFC 9762 因此建议支持该机制的主机处理 Redirect，除非本地明确禁用。不处理 Redirect 的主机或不发送它的路由器，可能承受更高的同链路时延。

这说明一次成功的上网探测不足以代表全部服务。部署可以完成委派、成功访问外部，却让局域网发现、点对点通信或受策略保护的横向流量走上意外路径。运维验证必须分别覆盖外部方向和同链路方向。

资源账本也会改变。RFC 9663 用更多前缀池空间和每设备路由状态，换取更少的逐地址 ND 状态、更清晰的设备级命运共享。大型无线网或虚拟化网络可能很划算；只得到一个较小上游前缀的家庭网络则可能迅速用完 /64。P 位表达的是操作者选择的模式，不能证明容量规划已经正确。

IANA 分配语法，不认证本地发送者

IANA 的 IPv6 邻居发现 PIO 标志注册表 把 bit 3 登记为 DHCPv6-PD Preferred Flag，并指向 RFC 9762。这解决了线上的共同解释，却不能认证某个接入网里实际发 RA 的设备。

RFC 9762 继承 RA 的安全模型。若没有 RFC 6105 所定义的 RA-Guard，本地攻击者可以复制 PIO、设置 P=1，让支持的主机忽略 A。在没有可用 PD 基础设施时，主机可能拿不到地址或经历明显延迟。RFC 7113 又提醒，简单宣称“已经启用 RA-Guard”并不等于各种扩展头和分片绕过都被正确处理。

DHCP 是另一条信任边界。缺少 RFC 7610 的 DHCPv6-Shield 时，伪造服务器还可能提供无效前缀或其他配置。即使现实中同一团队控制 RA 与 DHCP，它们在协议上仍是不同消息和不同执行点；一帧 RA 的可信度不能被借给后续 Reply。

恶意或错误设备也可能反复设置、清除 P。P 列表变化会触发 REBIND，给 DHCP 基础设施增加负载。RFC 8415 的消息速率限制能控制客户端发送，却不能证明振荡没有影响。应分别监测输入变化、状态机动作和下游资源。

一个窄信号，反而更适合长期演进

结论不是 P 位太弱。它的窄权限正是优点：解决“先决定走哪一种地址获取路径”的排序问题，同时把前缀分配、长度、路由、过滤、回退和业务结果留给真正控制这些事情的系统。

这与 Heng Lu 所写的最小初始规范、未来决策本地化与自愿采用相呼应。一个公共比特足以协调时序，却无需集中后续所有选择。运行代码优先给出了验证规则：配置意图不等于执行状态，执行状态也不等于交付结果。现实层级则要求标准语义、抓包、租约、路由与用户体验不能被压成一个笼统结论。

P 位只有在证据也保持一个比特应有的大小时，才最有价值。