摘要

  • 6rd 通过运营商的 IPv6 前缀和客户 IPv4 地址的一部分，推导客户的 IPv6 前缀。旧网络不仅运送新协议的数据，也参与决定新服务的地址空间和有效期。
  • 运营商自己的 6rd 域不等于“所有客户流量都经过中继”。同域客户设备之间可以直接建立 IPv4 封装路径，安全边界必须包含这条路径。
  • 无须维护逐流映射，不等于没有配置和退出成本。迁往原生 IPv6 时可以保留推导出的客户前缀，但需要把它们纳入原生路由，不能把“不改号”理解为“不做事”。

从谁有权改地址说起

假如 IPv4 地址管理团队准备调整客户地址的租期，这项工作通常会被理解为旧网络的运维决定。对采用 6rd 的服务而言，这个理解不够完整。客户的 IPv6 前缀来自 IPv4 地址；一个地址重新分配的动作，可能穿过协议边界，影响客户内部已经使用 IPv6 的网络。

这里的重点不是某次已经发生的事故。本篇没有测量一家运营商的现网，也不声称地址变动必然造成中断。重点在于，RFC 5969 明确规定了这种推导关系，并提醒 IPv4 地址变化可能导致客户侧 IPv6 前缀变化和服务扰动。这是一项可以从协议设计中确认的依赖。

6rd 的吸引力也正在于此。运营商不必先让整张接入网原生支持 IPv6，就可以用 IPv4 网络承载 IPv6 数据包。边界中继不需要为每条流量维护一份转换映射，转发所需的信息可以从地址中计算出来。这是实在的工程收益，不是宣传措辞。

但收益来自复用，复用就有继承。把 IPv6 服务上线与摆脱 IPv4 地址规划画上等号，会把最重要的那笔账划掉。旧地址规划没有消失，只是从前台变成了新服务的一个输入。真正需要审视的，是谁仍然能够修改这个输入，以及谁负责处理它带来的后果。

位数分配，其实也是产品分配

6rd 客户端设备称为 CE，即客户边缘路由器。它得到的 IPv6 委派前缀，由运营商的 6rd 前缀和自身 IPv4 地址的有关后缀拼接而成。共同的 IPv4 高位可以省略，省略多少由 IPv4MaskLen 参数表示。

委派前缀的长度等于 6rdPrefixLen 加上 32，再减去 IPv4MaskLen。RFC 给出的一个例子是，运营商使用 10/8 范围内的 IPv4 地址，前八位相同，不必重复写入每个客户的 IPv6 前缀。若运营商的 6rd 前缀为 /32，再加入剩余的 24 位，就得到 /56 的客户前缀。

这不是只有工程师才需要关心的算术。用于区分客户设备的位越多，留给客户内部划分子网的空间就越少。地址规划实际上参与定义了产品：客户可以在多少个内部网络上使用这项服务，并不是营销页面上线之后才独立决定的。

还必须分清两个门槛。DHCP 选项要求相关长度相加不得超过 128 位，这是格式成立的边界。地址规划部分则建议，委派前缀应为 /64 或更短，以便支持无状态地址自动配置。满足前一个边界，不代表已经给客户提供了合理的组网空间。一个数值可以被协议字段接受，却仍然不适合作为某种客户产品的设计。

使用私有 IPv4 地址也不会让边界问题自动消失。不同 6rd 域可以采用重叠的私有 IPv4 地址空间，但需要不同的 6rd 前缀来区分。在一个域内可以解释的地址，不能脱离域的上下文，直接作为另一个域内的身份凭证。这也不是通过端口范围把一个共享 IPv4 地址变成多个独立 6rd 前缀的机制。

因此，运营商日后“优化 IPv4 地址使用”的决定，可能同时重写 IPv6 产品的条件。地址团队看见的是池子和分配规则，客户看见的却可能是前缀及其内部网络。两种视角必须在变更发生前连接起来。

五周上线，不能脱离它的前提

早期部署记录 RFC 5569 报告，Free/Iliad 从 2007 年 11 月 7 日作出决定，到 12 月 11 日运行服务，用了五周。文件称，当时超过 150 万客户具备启用 IPv6 的条件，只要他们激活这项功能。

“具备启用条件”不能改写为“有 150 万活跃 IPv6 用户”，更不能拿来推算今天的使用率或体验。报告说明的是一次特定部署的覆盖资格，而不是当前的流量测量。它是一份 2010 年发表的说明性文件，也不是对所有运营商的交付承诺。

这次速度有清楚的组织基础：运营商能够调整客户设备的软件，部署中继，并利用已有接入网络。文章记录的地址安排也曾改变：早期采用 /32 分配、给客户 /64 前缀，后来取得 /26 分配，并为客户提供 /60 前缀，可供 16 个局域网使用。这是报告中的历史安排，不能把 /26 与 32 直接相加，声称算术结果就是 /60。

RFC 5569 的勘误页 进一步澄清了时间关系。已验证的编辑性勘误 2023，将相关段落从将来时修正为过去时：后来的地址安排已经发生，不再只是预期。另两条已验证记录同样是编辑性修正，不是新增的性能测试。

对管理层真正有用的，不是“五周”这个可复制的口号，而是五周背后的控制能力。能够推动设备软件、地址配置和中继部署的同一个组织，才有机会把算法迅速变成服务。若另一家运营商无法同样控制客户设备，或拥有不同的地址条件，引用部署时长并不能填补这些差异。

DHCP 的时钟走进了客户内网

RFC 5969 对有效期的要求，把这种继承关系写得很具体。知道 IPv4 租约时长时，向客户内网主机通告的相关生命周期，以及通过 DHCPv6 委派出去的前缀生命周期，都不得超过 IPv4 租约的时间。若无法获知 IPv4 地址的生命周期，文件建议采用 RFC 4861 的默认值，而不是把未知解释为永久稳定。

这里的“租约”是地址分配协议中的租约，不是企业在市场上租用 IPv4 资产的商业合同。两者混为一谈，反而会遮住故障机制。一个地址块仍然在运营商手中，不妨碍其中某个地址从一个客户重新分配给另一个客户；6rd 关心的是参与推导的那次客户分配是否改变。

文件因而建议让 IPv4 地址保持较长的使用期限。这不等于要求所有客户永久持有固定地址，也不能据此宣布动态分配不成立。它指出的是，地址分配周期越短，另一边越需要承受相应变化。省下的逐流映射管理，不代表协调工作也一同消失。

这种协调很容易落在部门之间。IPv4 团队可能希望提升地址周转效率，IPv6 服务团队希望保持前缀稳定，客户支持团队则在变化发生后接到电话。每个团队都可能在完成自己合理的目标，但整个服务没有人负责把收益与后果相抵。这是组织上的责任断层，不需要先假设任何人不称职或有恶意。

中继不是域内所有路径的中心

6rd 使用运营商自身的 IPv6 前缀和受控域，与依赖固定全球前缀的 6to4 不同。把这个区别说清楚很重要。但“由运营商控制”不能顺势画成一个过于简单的拓扑：所有客户都只向中间一台设备收发数据。

在同一个 6rd 域内，CE 可以把 IPv6 流量直接封装到发往另一台 CE 的 IPv4 数据包中。只有跨越 6rd 域与外部 IPv6 网络的流量，才需要边界中继 BR。域内直达不是绕过协议的意外路径，而是设计的一部分。

一条已验证的技术勘误揭示了这个细节的重要性。RFC 5969 勘误 3049 修正了安全章节中的表述：CE 不仅要接收已知边界中继的流量，也要接收同域其他 CE 的流量。如果按照未经修正的“只接收中继”来制定规则，可能阻断合法的同域通信。

同一页面上的技术勘误 3869 则被拒绝，不能当成已经采纳的修正。相关检查比较的是内层 IPv6 源地址中嵌入的 IPv4 地址与外层 IPv4 源地址，而不是把整个 IPv6 地址当成 IPv4 地址比较。匹配不成立时丢弃并计数，表示可能存在源地址伪造；计数器本身不能完成攻击归因。

一个域还需要一致的共同配置，包括 IPv4 掩码长度、6rd 前缀及长度、中继 IPv4 地址。DHCP 选项 212 为这套参数提供了分发方式，覆盖的是一个域的一组前缀配置。收到有效选项的 CE 默认可以自动配置，但规范同时要求，设备必须能够关闭这种行为，并在关闭后忽略选项。

这说明自动化并没有取消配置权。它只是把配置权集中到少量高影响参数上。参数一旦不一致，影响的不只是某条流量，而可能是设备对整个域的解释。

一次连通，不能证明所有路径正常

由于无须保持逐流状态，多个 BR 可以使用同一个 IPv4 任播地址。这有利于部署，却也要求人们谨慎解释观测结果：任播地址可达，不等于每个中继实例、每种包长和每个外部目的地都已经通过验证。

RFC 5969 提醒，大量 CE 周期性地向中继控制面发送探测，可能给中继带来额外负担。如果需要 CE 到 BR 的可达性检测，应采用无须 BR 控制面特殊处理的数据面方法。文件描述的回环方式，通过普通转发得到一次往返结果；它不能顺带证明外部 IPv6 互联网全部可达。

包长是另一层条件。发给任播 IPv4 地址的 ICMP 错误，可能到达另一台 BR，而不是原先发包的那台。动态发现路径 MTU 因而可能失效，并形成黑洞。任播 BR 在封装时必须设置不分片标志，以避免多个 BR 使用相同源地址时，分片重组发生混淆。

规范在 IPv4 路径明确支持 1500 字节的受控环境下，给出 1480 字节隧道 MTU 的例子；无法确定相关 MTU 时，则建议采用 1280。这些数字描述设计条件，不是本文测得的性能成绩。小包能够往返，只能证明小包走过的那条路径，不能自动消除较大数据包的疑问。

算得出一个地址，不等于那里就有合法端点

2011 年的说明性安全分析 RFC 6324，讨论了自动 IPv6-over-IPv4 隧道在路由状态和地址解释不一致时可能形成的循环。值得保留的核心区别是：地址可以由算法推导，并不证明对应位置确实存在一个合法、已知、适合接收隧道流量的端点。

对于 6rd，这种判断还依赖具体运营商使用的前缀，不存在一个能识别所有 6rd 流量的固定全球前缀。私有 IPv4 地址的作用域也需要纳入判断。通用检查不能脱离域配置，独自承担全部安全保证。

报告讨论运行方式上的规避，以及在适用场景下使用一致的邻居信息或有限端点集合。它针对 ISATAP 提出的特定同链路处理办法，不能不加区分地套到 6rd 上。安全建议需要保留适用范围，不能为了写出简洁结论而把不同机制揉成一条通用规则。

本文没有构造攻击数据包，也没有对运营商实施探测。循环是有条件的失效机制，IPv6 跳数限制仍然有限；不能把论文讨论改写成“所有 6rd 网络正在被攻击”。RFC 6324 勘误查询 本次未返回匹配项，但这同样不是 2026 年的安全审计结果。

RFC 5969 对限制外部访问 BR、处理域内已知其他中继等事项的讨论，进一步表明运营边界必须落实。一个域属于同一家运营商，不足以证明这些措施已经执行；反过来，仅凭协议文件，也无法判定某家运营商执行得不好。

退出时，要带走的是哪一笔依赖

从 6rd 迁到原生 IPv6，并不只有“所有客户重新编号”一条路。RFC 5969 描述了使用新前缀的方式，也描述了把原有 6rd 客户委派前缀注入原生路由、从而保留客户编号的方式。

后者的价值很清楚：客户可以少承受一次地址变化。但“不重新编号”不等于“迁移自动完成”。原来通过地址推导得到的到达关系，需要由原生路由承接。回收旧 6rd 地址块之前，还必须处理所有仍然依赖它的用户，而不是只检查主要中继是否已经下线。

卢恒在 Note 32 关于代理问题的讨论 中，强调控制权与后果承担之间的关系。把这一视角用于 6rd，可以提出一个具体问题：有权调整 IPv4 分配的人，是否同时看见客户 IPv6 的变化和退出成本？这不是声称卢恒研究过 6rd，更不是借他的论述给某家运营商贴标签。

Note 36 对 BTW 职责的说明 则要求报道保持对结构和事实边界的关注。6rd 不是需要被否定的捷径。它需要的是一份完整账目：快速上线时借用了什么，使用期间由谁维护，结束时又由谁接手。

旧地址规划继续做主，是因为它确实还在工作。负责任的服务管理，不是宣布旧协议已经不重要，而是让这份仍在发挥作用的依赖，始终有人看得见、改得动，也担得起。