摘要

  • IETF 于 2026 年 8 月发布 Standards Track RFC 10038，为 DHCPv6 定义了 SRv6 Locator 身份关联选项 149、单个 Locator 选项 150，以及无可用资源时的状态码 23。
  • 成功的 Reply 证明服务器按本地政策建立了绑定；它不证明客户端已配置、路由已安装和传播、远端 RIB/FIB 已收敛、SID 行为正确、过滤器放行、数据包成功，也不证明释放后已经可以安全复用。

先看释放，而不是申请。凌晨两点，租约系统把一段 Locator 标记为可用；两点零一分，骨干仍保留覆盖它的聚合路由；两点零二分，边缘设备还没有删除旧 SID；两点零三分，新的客户拿到了同一段空间。每个单独系统都可能按照自己的规则正常工作，合在一起却制造了两套并存的权威。

RFC 10038处理的正是这条链路的起点。规范在一个受信任的 SR 域内，用 DHCPv6 向 SRv6 Segment Endpoint Node 分发 Locator；位于客户场所但由运营者管理的 CPE 也可包含在这个边界内。相应的新选项和状态码已经列入 IANA DHCPv6 参数注册表。

选项 149 OPTION_IA_SRV6_LOCATOR 是容器，携带 IAID、T1、T2 和嵌套选项。同一报文可出现多个实例，各自 IAID 唯一，而且与其他 IA 类型使用不同的编号空间。选项 150 OPTION_IALOCATOR 必须嵌套其中，携带 preferred lifetime、valid lifetime、Algorithm、LB-Len、LN-Len、Fun-Len、Arg-Len、按最小长度编码的 Locator 以及后续选项。

LB-Len 与 LN-Len 之和是 Locator 长度；四个长度之和不得超过 128，Locator 长度也不能为零。违规会使该 Locator 选项无效，却不会把一份配置交易变成整张网络的状态证明。

客户端可以表达偏好，不能支配资源池

客户端通常把 T1、T2、preferred lifetime 和 valid lifetime 置零，服务器忽略客户端在这些字段里提交的值，自行决定计时。客户端也可以用非零 LB-Len、LN-Len 加 :: 表达长度偏好，但这只是提示，不是对前缀、结构或期限的权利主张。

服务器按照政策、配置和资源池决定是否分配、是否允许多个 Locator，也可以返回 NoSRv6LocatorAvail（状态码 23）。客户端发现 preferred lifetime 大于 valid lifetime 时必须丢弃该项，并且不能根据多个 Locator 的排列顺序推断生产、备用、优先级或服务类别。

RFC 9915提供 DHCPv6 的 Solicit、Advertise、Request、Reply、Renew、Rebind 与 Release 机制。它能证明一场带身份关联的交易，不能替 IGP 签收路由。运维系统若把“绑定已建立”显示成“节点已上线”，就把证据从一个权责域擅自搬到了另一个权责域。

Locator 也不是普通主机地址，更不是完整服务。RFC 8402定义 Segment Routing 架构，RFC 8986描述 SRv6 的 SID 结构和终端行为。RFC 10038 明确不处理本地 SID 分配、多个 Locator 的使用方式和单个 SID 的发布。终端节点仍要按自己的本地政策决定生成哪些行为。

Reply 之后，路由权力才开始逐级分散

DHCPv6 relay 或 server 可以为已分配 Locator 安装本地路由，下一跳应指向申请节点；它还可以通过传统路由协议发布这条路由。“可以安装”和“可以发布”是两个独立动作，不是 Reply 中已经完成的隐含步骤。

路由源发出通告后，邻居仍会执行认证、导入政策和拓扑计算；各自 RIB 可以接受、拒绝或选择不同路径；平台再把选择结果写进 FIB。控制面成功不保证每台设备的数据面成功，一台 relay 上的路由也不能代表远端设备的转发表。

Algorithm 为零时，可以采用普通 IPv6 前缀可达性；非零时必须使用 RFC 10038 指定的 Locator TLV。RFC 9350说明 IGP Flexible Algorithm 如何承载受约束的拓扑计算。如果自动化只保留前缀而丢掉算法标识，地址看似不变，路径语义已经被削掉。

数据包到达终端仍不是终点。RFC 8754定义 IPv6 Segment Routing Header，RFC 8986 定义终端行为。节点可能没有实例化目标 SID，可能执行另一种函数，也可能由过滤策略拒绝数据包。分配说明“谁取得地址空间”，路由说明“网络愿意往哪里送”，SID 与过滤说明“到达后允许做什么”。

Release 不是一条数据库更新语句

有效 Release 到来后，分配方必须释放绑定、删除本地路由，并撤回此前发布的路由。这三个结果分布在不同组件中，不能假定原子完成。资源池显示 free，不代表所有 IGP 邻居已撤销路由、所有 FIB 已清空，也不代表旧终端不再识别该 Locator 下的 SID。

IA 自身没有独立租期，内部所有 Locator 过期后它才过期。T1 让客户端先回到原服务器续约，T2 才扩展到可用服务器。preferred 与 valid lifetime 是剩余秒数，0xffffffff 代表无限。这些时钟管理绑定资格，不记录最后一个数据包何时消失。

聚合路由会改变撤回证据。即使更具体 Locator 已撤回，覆盖前缀仍可能把流量送到分配边缘。边缘必须在面向客户的接口上丢弃已经不再委派的前缀，否则“租约已释放”与“旧流量仍到达”会长期并存。

安全复用至少要经过一段可审计隔离：绑定关闭、本地路由删除、发布撤回、多个位置的 RIB/FIB 观察清除、旧 SID 移除、允许与禁止的数据包探针符合预期、最后流量时间已知，然后才把 Locator 放回池中。

“受信任 SR 域”不是万能安全标签

RFC 10038 的信任假设限定了部署环境，并未给 DHCPv6 增加普遍的端到端加密，也不自动认证每个配置事件和每个数据包。缺少额外保护时，劫持、篡改和窃听仍可能发生。边界 CPE 需要在内外接口实施过滤；基础设施 Locator 空间也应与普通终端地址可区分。

若 DHCPv6 与另一套分配系统没有隔离资源池，同一 Locator 可能被分配两次。按单一客户端限额，也挡不住伪装成多个客户端的行为者。RFC 7227与 RFC 8168分别提醒新 DHCPv6 选项和 IPv6 地址特殊语义需要谨慎治理；RFC 8987补充 SRv6 网络编程的运维条件。IANA 注册解决协议编号与共同词汇，不为某个生产环境的身份、池边界和过滤结果背书。

一条证据账要跨过所有平面

每个 Locator 应保存客户端 DUID、IAID、接入端口或 relay 上下文、授权与政策版本、请求偏好与实际授予结构、交易时间、lifetimes、T1/T2、绑定与资源池所有者、本地 SID、源端 RIB/FIB 路由与下一跳、IGP 类型/算法/版本、远端 RIB/FIB 观察、过滤结果、允许与禁止行为的探针，以及释放或过期、路由撤回、最后数据包、隔离期和再分配。

Heng Lu 的运行代码优先原则要求以这条真实执行链为准，而不是让请求记录替结果盖章。他对数据主权技术形式与实际控制的区分，解释了为何服务器掌握租约库，却无法单方面控制分散在路由器中的副本。他关于最小初始规范与本地后续决策的框架则说明：共同协议提供窄而稳定的语言，本地运营者仍为路由、过滤和后果负责。

RFC 10038 让“分配完成”有了准确含义。运营纪律是拒绝把它改写成“可达性完成”。