摘要

  • RFC 5192 为 DHCPv4 和 DHCPv6 分别定义 PAA 地址列表，并要求 PaC 按收到的顺序尝试。标准没有定义双栈竞速或合并规则，因此两份列表不能被伪装成一项共同事实。
  • 顺序只支配尝试次序，不证明候选健康、身份可信或 PANA 已完成；选项是否被请求、是否有效、每次尝试和最终结果都需要独立收据。

RFC 5192 的格式非常小，却容纳了不可随意压缩的语义。DHCPv4 的 136 号选项携带 32 位地址，长度必须是四的倍数；DHCPv6 的 40 号选项携带 128 位地址，长度必须是十六的倍数。两者都把 PAA 按偏好顺序排列，PaC 必须按列出的顺序尝试。

这里没有一个跨地址族的“总冠军”字段。RFC 5192 没有规定双栈客户端应先跑 IPv4 还是 IPv6、是否并行、等多久切换，也没有说明两份列表如何去重。这些都是本地实现策略。

本地策略可以存在，但不能冒充标准输出。只有保留两份原始列表和选择算法，运维人员才能解释实际行为。

两份顺序属于两个获取事件

每份列表都应绑定地址族、接口、DHCP 事务、服务器、relay 路径与接收时间。IPv4 的 [A,B] 与 IPv6 的 [C,A] 不是同一个集合的两种编码；它们来自不同消息，也可能服务于不同路径。

若数据库只保留 A，至少丢失三项事实：C 在 IPv6 列表中排第一；B 只存在于 IPv4；A 在两份列表中的位次不同。之后任何“客户端违反服务器偏好”的结论都无法验证。

正确模型为每个选项创建不可变版本，保存原始字节、声明长度、校验结果、地址与序号。选择器再记录它读取了哪些版本、使用什么算法、在什么时间安排了哪些尝试。

这样，合并或竞速仍可以是产品选择，但它会有名字、有版本、有因果链，而不是藏在 primary_paa 中。

偏好不是实时健康排名

“按偏好列出”规定先后，并未携带健康探测。选项里没有探测时间、负载、容量、失败原因、超时或 PANA 会话结果。排第一的地址可以已经不可达；排第二的地址可以成功。

因此不能因为 A 排第一就跳过对失败的记录，也不能因为 C 最终成功就删去 A 的尝试。每个候选需要序号、开始与结束、网络观察、PANA 消息和终态原因。

同样，IP 层有响应也不等于 PAA 服务可用。端点可能在后续 PANA 交换中失败。这里的结论只到发现与尝试链为止；RFC 5191 文章已经保留授权、执行点与数据面的后续边界，本篇不重复。

请求和收到不能互换

PaC 应在 DHCPv4 Parameter Request List 或 DHCPv6 Option Request Option 中请求 PAA 选项。但配置了 PAA 地址的服务器，即使客户端没有明确请求，也应发送选项。

所以“收到”不能证明“请求”。双栈环境更容易把两者混淆：客户端可能在一个地址族请求、在另一个没有请求，却在两个响应中都收到列表。

收据必须保存请求集合和响应集合。仪表盘可以显示“v4 请求且收到；v6 未请求但收到”，而不是用一个 discovery_enabled 掩盖差异。

这也说明选项不是协议协商。服务器交付候选，不替客户端决定是否必须使用 PANA。

缺席没有降级权力

RFC 5192 明确禁止用选项的存在或缺席判断网络是否要求 PANA。否则，能删除 DHCP 选项的攻击者就能让客户端选择更弱的安全机制，甚至完全不用安全机制。

在双栈场景中，一族缺席、另一族存在更不能被简化成共同策略。缺席只是该消息没有该选项。安全要求必须来自另一个可识别的策略源。

系统应分别存储：选项缺席、选项无效、选项有效、PANA 策略要求、后备发现方法。把前一项直接写成后一项，是把观察提升成了没有授权的决定。

长度校验发生在地址解释之前

IPv4 负载必须能完整切成四字节地址，IPv6 必须能完整切成十六字节地址。若长度不整除，解析器没有得到一份部分可信的列表，而是遇到了结构错误。

RFC 5192 没有授权解析器补零、截断或猜测。应保存原始值并报告校验失败，再执行明确的本地回退策略。不要把无效选项改写成空列表；二者具有不同证据意义。

IANA 的登记确认代码点存在。登记不证明某个包正确、某个实现支持，也不证明某个候选在线。代码点、消息与运行状态仍是三层事实。

新响应应产生新版本

DHCP 的租约、Renew 与 Rebind 给选项提供时间上下文。RFC 5192 并未规定 PAA 列表在续租时一定变化，也未规定缓存周期。但只要后续响应带来不同顺序，运维系统就应创建新版本，而非原地覆盖。

正在执行的尝试继续关联旧版本。新策略可以取消、保留或重排在途任务，但必须把这一决定单独记录。否则，回放时会看到尝试和一份它从未读取过的列表。

接口变化同样重要。来自一个接入面的列表不应无证明地迁移到另一个接入面。地址相同也不能删除获取来源。

保护状态必须来自实际交换

RFC 5192 警告，在多数网络中，接入认证之前交付选项的 DHCP 交换既没有完整性保护，也没有源认证。被修改或插入的响应可能把 PaC 引向恶意 PAA，用于截获认证请求或拒绝接入。

DHCP 相关标准存在认证机制，但标准存在不等于这个事务已使用。记录必须说明实际验证了什么机制、身份与结果。没有证据就保持未知或未保护。

即使交付经过认证，也只证明列表来源与完整性在该机制范围内成立。它仍不证明候选健康，更不证明后续 PANA 成功。

可审计的选择链

最小对象从两份原始 DHCP 事务开始。它保存请求、响应、family、interface、server、relay、保护状态和选项校验。每份列表拥有独立 hash、版本与序号。

本地选择策略明确写出：串行还是并行、地址族优先级、超时和缓存规则。每次尝试引用列表版本与序号。成功候选链接到 PANA 会话，而不是覆盖发现历史。

Heng Lu 的现实层原则要求符号记录不越权。服务器顺序是真实的执行输入；端点健康是真实的运行状态；本地双栈算法是真实的选择规则。把三者塞进一个“主地址”，只会让最方便的字段替另外两层说话。

Sources

  1. RFC 5192 HTML
  2. RFC 5192 文本
  3. RFC 5192 记录
  4. IETF Datatracker RFC 5192
  5. RFC 5192 历史
  6. RFC 5192 引用
  7. RFC 5192 勘误
  8. RFC 2131
  9. RFC 2131 记录
  10. RFC 2132
  11. RFC 8415
  12. RFC 8415 记录
  13. RFC 3315
  14. RFC 5191
  15. RFC 3748
  16. RFC 3118
  17. IANA BOOTP/DHCP 参数
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy