摘要

  • Provisioning Domain（PvD，配置域）是一致性边界：源地址、DNS 服务器、首跳路由等配置应在域内成套使用。PvD ID、通告标志和序列号能够标识并刷新这套信息，却都不是选路优先级。
  • 信任必须分段建立：主机从同一 PvD 内解析并获取附加信息，核验 FQDN、证书、标识符、有效期和前缀覆盖，再由本地或应用策略选择用途；最终证据来自连接实际使用的源地址、解析器、首跳与结果。

看板选中的域，浏览器没有使用

一台双栈终端接入同一链路，收到两套显式 PvD。第一套的名称来自熟悉的运营方，H 标志表明可获取附加信息，序列号也刚刚更新。第二套名称陌生，运维看板因此把第一套标成“已选择”。

但第一套经 HTTPS 验证的 JSON 明确给出 noInternet: true。它是一套只服务本地业务的受限配置域。浏览器要访问公共互联网时，主机策略选择了第二套；企业应用仍可使用第一套。

这里没有协议故障。熟悉名称说明身份线索，序列号说明该域自身的信息代际，noInternet 说明服务范围，真正的选择则属于具体连接。把四者压成一个“已选择”状态，才是看板的错误。

这种错误会遮住多宿主环境最难排查的故障：每项配置单独看都合法，组合却不合法。主机可能用网络甲分配的源地址、网络乙提供的 DNS，再把报文交给网络丙的默认路由。RFC 7556 引入 PvD，正是为了保留配置原本所属的语境。

配置域不是网卡的别名

RFC 7556 把 PvD 定义为“一致的网络配置信息集合”。集合可以包含源地址前缀、DNS 服务器、搜索后缀、代理和默认网关。传统单接口设备常把一张网卡近似当成一套配置，但这只是历史上的常见情况。

同一条链路上可以出现多个 PvD；同一个 PvD 也可能横跨多条链路。因此，PvD 的边界由配置的一致性与管理关系决定，不由物理端口决定。若系统仍把所有 DNS、地址和路由平铺为主机级资源，域名再精确也阻止不了交叉污染。

标准区分隐式域与显式域。前者由配置来源推断，后者带有明确身份。两种情况下，主机都应保存“信息来自哪个域”的关联。建立连接时，操作系统、用户或应用根据安全、成本、可达性和用途选择一个符合要求的 PvD，再在该域内完成地址与首跳选择。

因此，选择不是全机唯一冠军。受限企业 PvD 可以最适合内部系统，公共接入 PvD 可以最适合网页访问。网络发布的是可用语境，不是对所有应用的一次性裁决。

路由器通告只负责提出语境

RFC 8801 在 IPv6 Router Advertisement 中定义了类型 21 的 PvD Option。选项携带以 FQDN 表示的 PvD ID、H/L/R 标志、16 位序列号、延迟字段，并可携带嵌套的 RA 信息。

发布者应拥有并管理这个 FQDN。同一个 ID 应只用于最终服务相同的网络语境；服务实质不同，就应使用不同 ID。这让运营方获得稳定命名权，但并未让名称自动认证本地路由器。攻击者仍可能在链路上伪造一条写着熟悉名称的 RA。

三个标志的权限都很窄。H 表示存在可经 HTTPS 获取的附加信息；L 用于关联传统 DHCPv4 信息；R 表示为识别 PvD 的主机携带了内部 RA 头与选项。H 不证明主机已经获取或接受 JSON，R 不代表该域优先，L 也不能把所有 DHCP 观察无条件归入该域。

序列号同样不是排名。它改变时，主机应弃用此前缓存的附加信息并按延迟规则更新。不同 PvD 各自维护代际，数值 42 不会天然胜过另一个域的 7。Delay 字段只控制随机退避，既不是紧急度，也不是商业优先级。

附加信息必须走回自己的域

只有 H 置位时，主机才可请求 https://<PvD-ID>/.well-known/pvd；H 未置位时不得按此机制获取。响应使用 application/pvd+json，承载不适合塞进 RA 的网络属性。

真正关键的是获取路径。PvD ID 的 DNS 解析、证书状态检查、HTTPS 请求、源地址选择和首跳选择，都必须只使用正在审查的那个 PvD 的配置。不能借网络乙的 DNS 找网络甲的服务，再从网络丙发出请求，最后仍声称验证了网络甲的完整语境。

这一约束同时保护正确性与隐私。分割 DNS 可能让同一名称在不同域得到不同答案；源前缀会影响回程与首跳；运营方专属的 PvD 名称若经另一网络查询，还会暴露主机曾连接过什么环境。审计若只保存最终 URL，就丢失了最重要的证明链。

TLS 证书中的 DNS-ID 必须等于 PvD ID。验证失败时，主机关闭连接，并把该 PvD 视为没有附加信息。这证明 FQDN 控制者认可该信息服务，却不能单独证明链路上的 RA 真实，也不能证明其中每个前缀都属于该域。

JSON 完成第二次绑定

有效对象必须包含 identifier、expires 和 prefixes。标识符要与 RA 中的 PvD ID 相符；到期时间必须在未来；RA 关联的所有 Prefix Information Option 还要被 JSON 中的前缀覆盖。缺项、值无效或前缀不一致，都会使对象失去可用性。

这套检查把两个独立表面连接起来：本地路由器声称“这组配置属于某个名称”，经认证的信息服务声称“这个名称认可这些前缀”。只控制其中一面的攻击者，不能轻易伪造完整绑定。

可选的 dnsZones 描述该域能够解析或访问的命名空间；noInternet: true 表示受限网络，而不是配置损坏。工厂控制网、医院内部网或企业专网可能根本不需要通往公共互联网。选择是否合适，应由发起连接的应用需求判断。

未知键会被忽略，以保留扩展空间。IANA 维护通用键与标志的登记；厂商实验应放入组织命名空间或 vendor-* 子字典。登记能够统一语义，却不能证明某个通告诚实，更不能证明所有主机都实现了它。

新鲜度也有边界

序列号变化或 JSON 到期后，已取回的信息应被弃用。随机延迟和刷新窗口避免大量终端同时击中服务端。协议还建议，同一网络中对同一 PvD 的请求至少间隔十秒，十秒内所有 PvD 请求总数不超过五次。

绝对时间不能充当安全根。主机时钟可能偏移，所以到期时间不得用于安全敏感的单独裁决。若证书、HTTP 或 JSON 失败，主机在本次网络连接期间不再请求该 ID；累计十次以上此类失败后，应停止该连接期间全部 PvD 附加信息请求。这是防止恶意 RA 把终端变成 DNS、TLS 与 HTTP 放大器的硬边界。

运营方设置 H 也承担可达性义务。即使有 captive portal，登录前仍必须放行该 PvD 所需的 DNS、证书校验与 HTTPS。终端则应优先使用该域内的 IPv6 临时地址，并避免 Cookie 或可识别的请求头，防止可选元数据请求变成长期关联点。

路径选择最终发生在主机

当各 PvD 的配置与附加信息通过验证后，主机仍要按具体连接做判断。操作系统可以考虑安全和成本，用户可以表达偏好，应用也可以要求只能访问某个受限域。RFC 7556 提供的是不混配的框架，而不是一条全球统一排序公式。

权力因此被清楚拆分：路由器发布本地语境；FQDN 控制者认证附加信息服务；JSON 描述域的范围；主机判断该范围是否满足当前用途；运行中的连接再留下实际源地址、解析器、首跳、目的地和结果。

“运行代码优先”在这里不是反对规范。恰恰相反，最小公共规范负责保护关联，实际实现负责执行本地决策。若只看到 RA 中有一个名称就宣告选路完成，既夸大了运营方权力，也抹去了主机必须承担的判断责任。

来源