RFC 5158：6to4 自助反向委派把授权推回本地边界

摘要

6to4 的便利来自一条确定公式。路由器把公网 IPv4 地址放进 IPv6 前缀，形成一个站点 /48；反向区域也随之可以机械计算。登记服务看到来自该 6to4 地址的请求，就能把它限制在同一个 IPv4 所推导的区域，避免一个客户直接申请另一个客户的空间。

这条约束很有价值，却只回答“最多可以操作哪一段”。它没有回答机器背后的自然人是谁、这个人代表什么组织、是否获得 DNS 管理员同意，也没有回答公网 IPv4 会在何时被运营商重新分配。一个正确的数学映射不能自动长出组织授权。

传统 IPv4 反向树也无法直接补上这层能力。单个 /32 的使用者通常没有独立的 in-addr.arpa 委派，而 6to4 又让站点绕开常规 IPv6 上游关系。RFC 5158 因此用登记服务把两者接起来：它发布真实 DNS 委派，但只赋予来源地址一项狭窄的技术能力。

请求通过 HTTPS 发出。加密和服务端认证保护表单内容，避免简单中间人篡改，也减少代理错误缓存对操作的干扰。服务再检查请求的 6to4 来源与申请区域是否一致。这些措施让无人值守的登记在当时具备可操作性。

然而，RFC 5158 并未把这种安排包装成强身份认证。它明确指出地址认证很粗略，存在欺骗可能。更现实的风险发生在合法来源内部：站点中的任意终端都可能拥有属于该 /48 的地址，却没有修改全站 DNS 委派的职责。

规范把防范责任交给本地 ACL、防火墙和管理制度。于是，登记服务的低摩擦以责任转移为代价。远端系统只能证明请求来自边界之内；谁有权使用这条出口，则必须由站点自己控制并留下记录。若本地没有这份记录，远端的“成功”回执不能补造管理员同意。

委派生效前，登记服务要查询所提名的主服务器和至少一台从服务器。它们必须可达、对该区域给出权威回答、呈现相同 SOA，并发布完全一致的 NS RRset。该流程能阻止明显未配置完成的区域进入父区。

但检查对象是 DNS 运行状态，而不是组织决定。两台服务器可以稳定地重复同一条错误 PTR，也可以由未经授权的内部用户配置得完全一致。SOA 相同说明它们对区域版本有共同认识；NS 相同说明它们对委派集合一致；两者都没有识别批准者。

因此，证据模型至少要保留两张收据。一张是“这些服务器在某时刻为该区正常工作”，另一张是“有权代表站点的人批准了这些服务器”。把前者当成后者，会让高可用性掩盖授权缺口。

区域名称看似稳定，底层 IPv4 保管却可能很短。前一个用户归还动态地址，后一个用户拿到同一个值，就会推导出完全相同的 6to4 /48。父区委派、权威服务器或解析器缓存可能仍讲述前一个站点的故事。

RFC 5158 用低 TTL 减少缓存寿命，并建议每三十天检查委派服务器。第一次失败后发送通知，十四天后再试；第二次仍失败则删除委派。IPv4 控制者还可从另一条渠道要求阻止该地址的自助登记。

这些机制各自有用，却观察不同事实。TTL 控制缓存，复查观察服务器活性，删除清理父区，阻止请求体现地址资源控制者的更高权限。任何一个步骤都不等同于实时检测地址重新分配。旧服务器若持续在线，复查甚至会顺利通过。

文档对反向解析的证明力十分克制。PTR 存在并不能可靠确认某域名与地址之间的真实关系，PTR 缺失也不能否认这种关系。即使再做正向解析核对，也只是验证两组 DNS 配置能否互相指回，并不证明法律身份、运营责任或管理授权。

这一点在日志、访问控制和事件调查中尤其重要。反向名称可以帮助人阅读地址、形成搜索线索，却不应被升级为证书。可辩护的陈述应很窄：在某个时间，父区按照公开策略把一个推导区域委派给一组通过检查的服务器。

若系统还要判断谁负责该地址，就必须额外连接地址分配时间、本地批准人、服务器变更历史和独立网络证据。缺少这些连接时，最诚实的状态不是“已验证”，而是“DNS 配置可见，主体未证实”。

后续 RFC 记录了 6to4 的操作困难，并弃用其 anycast 中继机制。RFC 5158 引用的旧 TLS 依赖也被 RFC 8996 的现代要求更新。规范中出现的历史服务名称不能当成今天仍可用或仍被采用的证据。

但这个授权结构并未消失。云平台、自动证书、网络注册和设备接入仍经常根据来源位置授予临时能力，再用健康检查决定是否启用。RFC 5158 提醒决策者：自动化可以安全地缩小范围、检查准备程度、设置回收时钟，却不能在没有本地治理的地方替组织指定合法代理人。