摘要

  • RFC 4193 通过本地生成的 40 位伪随机全局 ID，使两个独立 ULA 前缀极可能不同；这不是中央分配、登记或认证。
  • “全局”说的是唯一性所面向的范围，并不表示全球可达。ULA 只应留在站点内，或进入明确约定的站点间路由。
  • 企业合并或建立 VPN 时，概率只能支持初始信心；真正的放行依据仍是完整前缀比对、精确路由与 DNS 边界、独立安全控制以及可执行的重编号或回退条件。

收购交割前，两张网络图被摊在同一张桌上。双方都使用以 fd 开头的 IPv6 地址，完整前缀看起来也不一样。项目组很容易由此写下结论：地址无冲突，可以开通隧道。

这个结论大体可能是对的，证据却还没有完成。

2005 年 10 月发布的 RFC 4193，由 Robert Hinden 与 Brian Haberman 共同署名，是一份标准轨 RFC。它在 FC00::/7 中定义 IPv6 唯一本地地址（Unique Local Address，ULA）。格式包含一位 L 标志、40 位全局 ID、16 位子网 ID 与 64 位接口 ID。规范把 L=1 定义为本地分配，因此实际使用的本地生成形式落在 FD00::/8。

“本地分配”意味着运营者不必向中央登记机构申请。规范要求全局 ID 采用伪随机方式生成，不得顺序编号，也不得反复使用众所周知的值。建议算法把当前时间与某个系统专属标识组合，计算 SHA-1，再取最低 40 位。

这里的 SHA-1 不是安全承诺。它没有签署前缀，没有证明操作者身份，也没有提供保密性或所有权。它只是把各自独立的选择尽量均匀地散布到一个足够大的空间里。

RFC 给出的概率恰好说明这种设计的边界。两个独立生成的全局 ID 发生碰撞的估算概率约为 1.81 × 10^-12；当数量达到一万个时，估算约为 4.54 × 10^-5。这是一套模型中的计算结果，并不是对当下互联网部署的测量。它证明冲突很罕见，不能证明冲突不可能。

“全局 ID”这个名字还会制造第二个误读。这里的全局，是指它试图在不同管理域之间保持唯一；并不是说对应路由拥有全球传播资格。IANA 当前的 IPv6 特殊用途地址登记表把 fc00::/7 标为可作为源地址、目的地址并可被转发，但不是全球可达。IANA 同时提醒，进入特殊用途登记表本身，并不保证任何具体环境中的可路由性。

地址格式不会自动造出边界

RFC 4193 预期 ULA 留在一个站点内，或只在明确同意互联的站点之间传播。互联网路由默认应忽略整个 FC00::/7。站点边界通常应双向过滤 ULA 路由与数据包。确需跨站点通信时，例外应写明具体 /48 或更长的前缀，而不是笼统放开整段地址空间。

这说明“私有 IPv6 地址”只能算方便的简称。路由器完全能够转发 ULA，VPN 也能承载它；错误的重分发策略同样能把它带出预期范围。边界来自路由政策、过滤器与拓扑，不是来自地址第一字节的一道无形墙。

DNS 也要单独设界。由于唯一性并非绝对保证，RFC 4193 不建议把 ULA 的 AAAA 或 PTR 记录发布到全球 DNS。相关反向查询不得流向全球 DNS 基础设施。因此，合并检查不仅要收集路由表，还要收集内部权威区、分割视图、转发路径、反向区与应用命名依赖。

一个 /48 也不会自动给终端编号。路由器通告、DHCPv6、手工配置、子网规划与名称登记仍是不同控制面。RFC 5375 指出，ULA 可以与全球地址并存；这不等于建议 IPv6 使用网络地址转换。

更不能把地址类别当作安全产品。服务仍须认证身份，策略仍须授权流量，防火墙仍须限定路径，运营团队仍须验证路由来源。RFC 4193 明确说 ULA 不提供内在安全。一个数据包来自本地地址空间，并不能说明发起者是谁或是否获准访问。

40 位真正解决了什么

要理解这 40 位，可以回看 RFC 3879 废弃的站点本地地址。旧机制的问题并非只有技术格式。“站点”本身没有稳定含义：一家组织可能把办公楼、数据中心、云网络和合作伙伴划成不同范围；应用难以选择正确作用域；前缀泄漏后也难以追责；两个独立网络连接时可能发现双方使用完全一样的本地块。

伪随机全局 ID 修补的是最后这类协调缺口。各站点可以独立编号，日后相连时，前缀大概率已经不同。RFC 5375 由此强调 ULA 对泄漏与网络合并的价值：它降低立即重编号的可能性。

降低并不是消除。RFC 4193 不建议全球路由 ULA，原因之一就是没有机构保证其唯一，路由也无法有效聚合。一旦两个已连接网络真的共用同一 ID，通信可能失败，也可能误达另一系统。事件发生概率很低，不代表后果必然很小。

人物归属也应遵循同样的证据纪律。Haberman 是共同作者，不是唯一发明者；Hinden 与他共同署名，RFC 还致谢更多参与者。IETF 的 IPv6 工作组官方照片页识别了 Haberman，并把他与 Hinden 列为这个已结束工作组的主席。Internet Society 在 2026 年 8 月介绍他时，称其为董事会主席、Fastly 杰出工程师、NetDev 理事，并提到他长期参与 IETF、早期曾开发 IPv6 路由平台。这些材料说明职业脉络，技术判断仍应回到规范本身。

并网真正需要的“凭据”

缺少中央分配证明，不是拒绝 ULA 的理由；拥有一串看似随机的地址，也不是立即放行的理由。双方需要制作一份可以检查的运营凭据。

第一步是列出所有在用及预留的 /48。清单要包括生产网、实验室、云虚拟网络、灾备环境、休眠的 VPN 合作方，以及写死在应用或自动化模板中的地址。随后逐值比对两侧前缀。概率在清单未知时提供合理预期；清单已知后，概率就不能代替比对。

第二步是记录生成来历与保管责任：大致时间、采用的方法、系统标识的类别和维护团队。无需公开敏感硬件标识，却必须能区分独立生成与从同一模板复制。后者会破坏概率模型假设，即便每个业务单位都声称“本地生成”。

第三步是逐项批准路由。记录互联名称、获准前缀、下一跳、导入与导出过滤、监测责任人和撤回动作。测试边界确实拒绝其余 FC00::/7，也确认没有 ULA 路由到达互联网对等方。

第四步单测命名与地址选择。两侧全局 ID 不同，并不保证内部 DNS 区名不同；前缀不冲突，也不保证应用不会优先选择一条不可达 ULA。权威区、分割视图、解析器路径、反向查询与地址选择政策都要落入同一并网记录。

第五步把安全证据另列一栏。哪套系统认证调用者，哪条规则授权访问，哪台防火墙限制流量，哪种路由来源可信，哪份日志可以追查异常？“这是 ULA”不能回答其中任何问题。

最后，在割接前写下退出条件。发现重号时哪一侧重编号；出现外部路由泄漏时谁撤回；反向 DNS 外溢时隔离哪条解析路径；应用仍写死地址时是否推迟互联。可回退不是悲观，而是让低概率事件不至于变成不可控承诺。

Heng Lu 对运行代码优先的论述把证据重新放回系统：声明的地址表和架构图只是行政记录，真实路由表、数据包路径、DNS 应答与应用测试才说明网络如何运行。最小初始规范则提供协作尺度——只要求足以安全互联、明确责任并保留退出空间的共同信息，不替各站点决定全部内部设计。

40 位全局 ID 的价值，在于它没有把所有内部编号集中管理。它让自治选择极可能共存；一旦这些选择跨越共同边界，运营者再用可验证记录补上概率从未承诺的部分。

来源