摘要

  • RFC 6334 定义了一项 DHCPv6 选项，把 DS-Lite 的 AFTR 名称交给 B4。名称允许设备尝试连接，但不能证明隧道、地址转换或回程数据已正常运行。
  • Tomek Mrugalski 与 David W. Hankins 共同撰写了这项规范。客户侧只需接收有限的端点指示，容量安排和服务可用性则落在运营商一侧。

收到名称，并不等于连通

在网关日志里，“已收到 AFTR”看起来像一个完整结论：DHCPv6 服务器已经回复，端点名称也出现在屏幕上。但它没有说明客户网关使用的 DNS 是否解析了这个名字，返回的 IPv6 地址是否可达，B4 是否真正建立了隧道，或者 AFTR 是否为当前流量创建了地址转换状态。它更不能证明回复包已经回到用户的应用。配置收到与服务可用，是两件不同的事。

RFC 6334 定义了 OPTION_AFTR_NAME，代码为 64，内容是完整域名，指向客户可尝试连接的 Address Family Transition Router。B4 是 DS-Lite 的客户侧隧道发起功能。这个字段不携带隧道本身，不预留 AFTR 容量，也不替应用做连通性检查。它的价值就在于把任务边界说清楚：一个配置选项只给出起点，不替后续所有环节背书。

Tomek Mrugalski 与 David W. Hankins 于 2011 年 8 月共同署名 RFC 6334。RFC 6333 则单独说明 DS-Lite 的整体架构：B4 把 IPv4 数据报封装进 IPv6；运营商网络中的 AFTR 负责解封装并执行 IPv4 地址转换。两份规范共同呈现出一条责任分界：客户设备收到一个范围有限的指示，运营商选择端点、维护共享容量并负责让服务可用。

为什么把功能放到运营商网络

DS-Lite 面向的是一种过渡情形：客户接入可以运行 IPv6，同时仍承载一些设备和服务所需的 IPv4。家庭设备可使用私有 IPv4 地址，网关里的 B4 把这些数据包封装进 IPv6，送往 AFTR。AFTR 解封装后，再用运营商共享的公网 IPv4 资源完成转换。客户设备并不需要为每个终端分别持有一个公网 IPv4 地址。

RFC 6333 描述了运营商可采用的容量安排：一些客户可以共用同一 AFTR；需要更多容量时，运营商可增加 AFTR，并把设备部署得更接近接入网络。这是规范提供的架构选项，不代表某个特定运营商已经采用，更不能据此推断其实际容量或成本。关键在于控制面：B4 收到的名称可能把客户流量导向一个由运营商安排位置和容量的共享功能。

这种简化并没有消除各方工作。B4 仍须具备可用的 IPv6 路径，验证选项，解析名称，并把隧道绑定到正确接口。运营商则要维护 AFTR、相关路由、共享 IPv4 资源，以及让返回包能够找到原流量的状态。用户只在一条接入链路上看到故障，不代表故障就位于该链路；问题也可能在 DNS、IPv6 传输、隧道、过滤规则或转换状态。

选项字段规定了什么

客户端不会自动收到 OPTION_AFTR_NAME。符合 RFC 的 B4 客户端会在 OPTION_ORO（Option Request Option）中请求代码 64。若客户端没有提出请求，服务器不会返回该选项。因此，响应里没有名称，并不能单独证明网络不支持 DS-Lite。还要看客户端请求、服务器配置和实际应答路径。

这个选项使用 DHCPv6 的域名编码格式。客户端必须先检查长度和名称结构，再使用该值。服务器不应发送多个 AFTR-Name 实例，也不应在一个字段中配置多个名称。如果 B4 收到多个实例或多个域名，规范规定只采用第一个。这条规则消除歧义，却没有定义多个 AFTR 之间的负载均衡机制。

拿到有效名称后，B4 会查询 DNS 的 AAAA 记录。如果响应包含多个 IPv6 地址，它只选择一个作为当前接口的隧道端点；同一接口上同时只能建立一个 DS-Lite 隧道。不能把 DNS 返回地址列表直接解释为自动故障切换、流量分摊或并行连接。那些能力需要其他设计，也需要运行中的实现证据。

RFC 6334 还承认 DHCPv6 客户端与 B4 可以合并，也可以由另一个软件组件连接。抓包可能证明客户端收到了选项，却无法证明配置代理把它交给了隧道进程。排障需要知道值经过哪些软件边界、被应用到哪个接口，以及设备最终选择了哪个地址。一个进程看到正确配置，不等于另一个进程已经使用它。

从 DHCP 响应到返回数据

审计应保存四项可关联的证据：OPTION_ORO 中是否请求代码 64，服务器实际返回的名称，B4 使用的 DNS 解析器返回了什么 AAAA 记录，以及 B4 最后选中的地址。之后还需要记录 B4 的隧道状态、AFTR 是否接受该隧道、是否建立了转换状态，以及一个可控 IPv4 测试是否收到返回包。每条记录都应带有接口和时间信息，不能把管理员电脑的 DNS 结果冒充客户网关看到的结果。

DNS 有答案，不等于 AFTR 可达；隧道已建立，不等于地址转换正常；转换状态存在，也不等于外部服务返回了数据。这种分层能帮助支持团队找出第一个停止推进的环节，而不是把所有问题都归为“DHCPv6 故障”。用户看到的症状可以一样，负责修复的团队却可能是 DHCP、DNS、CPE、接入网、AFTR 或应用团队。

高可用性体现了谁承担结果。RFC 6333 把它放在运营商侧，而不是客户设备上；RFC 6334 只规定每个接口使用一个选定地址和一条隧道，并未规定运营商如何实现冗余。运营商可以采用备份设备、重新分配端点、同步状态等方式，但这些属于实现方案。迁移是否成功，要看现有会话保留情况、实际中断时长和恢复记录，而不能从多个 DNS 地址推断出来。

RFC 6333 也建议 AFTR 记录 NAT 转换状态的创建，或保留可用于故障排查和法律请求的等效信息。单独一条公网地址记录，如果没有隧道、客户和时间上下文，未必足以说明共享资源对应哪个流量。AFTR 名称选项不是转换日志；它只告诉 B4 可以去哪里尝试建隧道。流量的可追溯性由另一层运营能力提供。

选项设计也是部署设计

2014 年，Mrugalski 又与 David Hankins、Marcin Siodelski、Sheng Jiang 和 Suresh Krishnan 共同撰写了 RFC 7227（BCP 187），讨论如何定义 DHCPv6 新选项。它要求设计者考虑现有软件能否采用，而不是只关注报文里的字节格式；文中讨论可复用格式、实例数量和顺序、校验、客户端/服务器/中继各自行为，以及通过 ORO 明确请求选项。

时间顺序很重要：RFC 6334 发布于 2011 年，RFC 7227 发布于 2014 年。后者不能被说成前者设计的原因。它提供的是后来的设计视角：一个字段要经过管理界面、服务器配置、协议报文、客户端代码以及最终应用配置的软件。抓包格式再简洁，如果现有工具难以录入该字段，或者无法把它绑定到正确接口，部署仍可能困难。

当前 DHCPv6 基础规范是 2026 年 1 月发布的 RFC 9915，它取代了 RFC 8415。新选项仍可由单独文档定义，RFC 9915 继续指向 RFC 7227 的指导，并维护 IANA 选项代码注册表。一个选项可能长期存在于不同版本的客户端和服务器中，所以应尽早明确实例数量、顺序和校验方式，避免让实现者各自猜测。

IETF Datatracker 列出了 Mrugalski 共同参与的 RFC 6334、RFC 7227、RFC 8415 和 RFC 9915 等工作；ISC 的人物介绍 则提到他早期开发 DHCPv6 服务器 Dibbler，以及后来在 ISC 从事 DHCP 工程。两者提供职业背景，不能证明软件市场份额、标准采纳规模或他个人控制了每个实现。

这条边界让人物叙述更准确。RFC 6334 没有记录 Mrugalski 的私人动机，也没有证明他单独决定设计，更没有指向特定运营商的部署。能确认的是，他与另一位作者共同撰写了一项规范，让 B4 可通过 DHCPv6 获取 AFTR 名称；后来又与多名作者参与选项设计指南。规范是集体产物，部署仍由实际运行系统的人决定。

公开规范没有给出的答案

RFC 描述架构和协议行为，却没有提供 DS-Lite 当前用户数量、设备兼容性独立测试、服务故障率或各种 IPv4 过渡技术的市场份额。IANA 注册表可以确认代码 64 属于 OPTION_AFTR_NAME、可在 ORO 中请求且为单实例选项；它不能说明今天有多少网关正在使用它。

RFC 9313 对比了多种 IPv4-as-a-Service 过渡方案，可以用来说明 DS-Lite 只是其中一种，不能据此说它一定更好、已经占主导或已经过时。选择要结合实际 CPE、IPv6 传输、共享 IPv4 容量、状态维护和应用要求。

Mrugalski 的贡献应放进一条链中理解：客户端请求一个字段；服务器决定是否返回；B4 解析名称并选定地址；AFTR 接受隧道并处理流量；用户最终收到 IPv4 响应。任一环节缺少证据，文档仍只是规范，日志也只证明配置曾经到达。

来源