摘要

  • 多前缀不等于多宿可用；源地址、第一跳和 DNS 递归语境分别有效，也可能组合成一条必然失败的路径。
  • 可核验的连接回执应把三项选择绑定到同一次尝试，同时保留配置、采用、上游接受与业务结果各自的证据边界。

故障记录常常是一排互不相识的绿灯。DNS 团队说名字已经解析，终端团队说地址已经配置，网络团队说默认路由器可达。应用仍然超时。真正的问题不是缺少哪一盏灯，而是三盏灯照向不同的网络：名字来自企业 VPN，源地址属于家庭宽带，下一跳却指向移动备份链路。

RFC 7157《IPv6 Multihoming without Network Address Translation》把这种错配写进了协议讨论。它在 2014 年 3 月以 IETF 共识形成的信息类 RFC 发布，作者栏首先列出主编 O. Troan，随后是 David Miles、Satoru Matsushima、Takashi Okimoto 与 Dan Wing。Ole Trøan 的 IETF 档案记录了这项工作。这只能证明他参与主编一份集体文档，不能证明他独自发明多宿、控制任何部署，或拥有后续 RFC 的作者身份。

这份文档首先提醒读者，IPv4 的 NAPT 不只改写地址。边界设备往往同时完成三件事：挑选对外源地址，决定下一跳，并在某些部署中代理或决定 DNS。内侧主机只看见一个私有地址和一个出口，提供商地址、上游路径与命名语境被集中在同一个盒子里。集中让组合显得自然，也让决策来源变得不透明。

IPv6 允许小型站点从不同提供商分别取得全局前缀。终端可以同时保持 Wi‑Fi、蜂窝网络与企业隧道。它不必让每条流都经过不可见的转换器，却会同时收到多组地址、路由器和递归服务器。地址足够多，不代表系统已经知道哪些信息属于同一个供应语境。

RFC 7157 因而把第一包之前的工作分成三项。第一，选择与目标和上游相配的源地址。第二，选择能够承载这个源地址的下一跳。第三，选择理解目标命名空间的 DNS 递归服务器。许多运营商执行入口过滤；属于运营商 A 的合法源前缀若从运营商 B 出口送出，仍可能被丢弃。单项合法不是组合合法。

源地址首先是一组候选。RFC 6724 规定 IPv6 默认源地址与目标地址选择算法，并允许管理员用策略表覆盖默认行为。RFC 7157 指出，在多前缀环境里，默认规则未必能确定与特定上游匹配的源地址。RFC 7078 提供通过 DHCPv6 分发地址选择策略表的方式。但收到 DHCPv6 选项，只能证明某些字节抵达终端；它不能证明策略被安装、仍在有效期内，或这一个包确实按该版本作出选择。

第一跳是另一项决定。多个 Router Advertisement 可以让多个默认路由器同时有效。随意选一个，可能把正确源地址交给不接受它的上游。后来成为标准轨 RFC 的 RFC 8028 把顺序说得更明确：先选源地址，再从曾公告该源前缀的路由器中选择第一跳。RFC 8028 的作者是 Fred Baker 与 Brian Carpenter，文中感谢 Ole Troan 提供重要文字。贡献记录不应被夸大成作者转移。

DNS 也不是路由表的附属品。企业 VPN 可能独有内部名称；接入运营商也可能依据查询来源返回不同地址。向所有递归服务器提问并采用最快答案，可能得到语法正确、却只能在另一个网络使用的地址。RFC 7157 讨论按域名空间选择递归服务，并引用 RFC 6731 的 DHCPv6 DNS 选择机制。DNS 回答必须携带它的查询接口、源地址、递归服务器与供应语境，才能在之后解释结果。

三项决定有先后，却没有单一所有者。应用提出名称与意图；DNS 策略选择语境并返回候选目标；主机策略选择源；路由逻辑选择门；网关和上游过滤器继续决定是否接受；远端服务最后给出响应或沉默。若监控只留下“IPv6 成功”或“IPv6 失败”，下一次事故就只能由各团队拿着各自的绿灯争论。

RFC 7157 对替代方案也保持了边界。它主张在可能时避免 NAT 与 NPTv6，以维护端到端透明性；结论同时承认，针对文中问题，基于 DHCPv6 的办法适用，而 NPTv6 可能仍是过渡方案。前者是架构方向，后者是迁移现实，两者可以同时成立。RFC 6296 对无状态 IPv6 前缀转换的定义，也不是要求所有网络采用或拒绝它的凭证。

后续文档给“不要混用不同语境的配置”提供了更清楚的对象。RFC 7556 把 Provisioning Domain（PvD）定义为一组一致的网络配置，典型内容包括源前缀、DNS 服务器、DNS 后缀和默认网关。RFC 8801 又允许路由器公告携带基于 FQDN 的 PvD 标识，并提供可选 JSON 附加信息。标识有助于关联，却不会自动证明配置可信、网络当前可达或应用一定成功。

因此，运营上真正值得保存的不是“已连接”图标，而是一次连接尝试的回执。它至少应关联：目标名称与应用意图；DNS 所属 PvD、递归服务器、查询源与接口；回答集合、TTL 与时间；选定目标；候选源与最终源；策略版本和过期点；候选路由器与第一跳；公告前缀和寿命；邻居状态、本地路由查询、过滤决定；重试时改变的变量；以及可获得的上游或远端观测。用同一尝试编号和单调时钟保存顺序，避免校时破坏因果链。

每个字段只回答有限问题。地址已配置不等于已选择；源已选择不等于上游接受；收到路由器公告不等于该设备转发过本包；DNS 有回答不等于服务可达；一次应用成功也只证明那个时刻的一组组合，而不能证明备用路径、其他命名空间或全部目标都正确。

这正是 Trøan 主编工作的长期价值：它没有把复杂性包装成产品口号，而是指出旧盒子曾经集中哪些决定。端到端透明不是取消控制，而是让控制的输入、选择、期限、责任人与撤销路径重新可见。

来源