摘要

  • IPv6 站点本地前缀 FEC0::/10 让网络不必申请全球前缀就能使用内部地址，但地址本身没有说明它属于哪个站点。
  • RFC 4193 改用本地生成、极可能唯一的前缀，并把可达范围交给本地路由决定。

分析

地址缺的另一半在主机里

应用记下 FEC0::1234:5678:9ABC 并尝试连接。对同时接入多个网络或会移动的主机来说，这串十六进制字符可能还不够：应用还要写明是哪一个站点，比如加上 %1 这样的范围标识。换一台主机实例，同一站点可能变成 %2。看起来可携带的地址，缺了依赖本机状态的另一半。

这就是 IPv6 站点本地单播地址的尴尬交换条件。2003 年 4 月发布的 RFC 3513 把 FEC0::/10 定义为站点内部地址，不需要全球前缀。后面是 54 位子网 ID 和 64 位接口 ID。路由器不得把这类数据包转发到站点之外。网络因此可以先在内部使用 IPv6，而不必先取得一个全球可路由的地址块。

但地址没有标出究竟是哪个站点让它变成“本地”。FEC0::1 可以同时出现在两个站点。2004 年 9 月的 RFC 3879 把后果写得很直接：应用必须管理额外的站点标识；一个文字地址不能作为与主机无关的目标被可靠记住，也不能简单地从 DNS 学到；传递 IP 地址的软件还可能把这种歧义带出本地网络。

“站点”这个词被要求同时承担太多边界。一家公司的网络、校园、地理位置、路由域、防火墙区域和行政边界，未必重合。RFC 3879 列出安全、可达性、路由、服务质量、管理与资金等边界；同一套范围很难满足所有目的。DMZ 对某项服务可能算内部，对另一项却已在外部。数据包只有一个地址，组织却有好几张边界图。

路由器也继承了这场争论。如果同一个站点本地目标会因数据包进入的接口而有不同含义，多站点路由器就需要按站点设置路由，并特殊处理转发信息库。隧道和虚拟化路由表可以承接这份工作，却不能把“站点”变成所有网络通用的单位。

这个方案的吸引力确实存在：无需全球前缀，也能在内部使用地址，而且路由器可以按边界过滤。2003 年，IPv6 工作组开始转向替代方案。RFC 3879 记录了当年 3 月形成的一定共识，以及 7 月对替代和弃用决定的确认，同时明确说共识远非一致。2004 年 9 月的 RFC 弃用了 FEC0::/10，但允许现有实现和部署继续使用，直到替代方案完成标准化；没有未来 IETF 标准行动，也不得把该前缀重新分配给其他用途。

RFC 4193 在 2005 年 10 月给出了替代方案。唯一本地 IPv6 地址使用 FC00::/7；本地分配的前缀通过伪随机方式生成 40 位 Global ID，后接 16 位子网 ID 和 64 位接口 ID。这里的“Global”说的是前缀具有高度可能的唯一性，不是能从全球互联网访问。RFC 说的是“高度可能”，并非绝对保证。这些地址用于本地通信，也可以在有限的一组站点间路由，但预期不会进入全球互联网路由。

网络合并时，这种变化就有实际意义。分别生成的 ULA 前缀不太可能碰撞，因此合并或私有互联通常可以避免重新编号；站点之间仍需配置明确路由。地址不必再编码一个普遍适用的“站点”定义，本地网络自行决定路由和过滤规则把它带到哪里。

2006 年 2 月的 RFC 4291 将弃用规则纳入 IPv6 地址架构：新实现不得继续赋予 FEC0::/10 旧的特殊行为。RFC 记录解释了设计变化，却没有统计今天还有多少系统在用这个前缀。要回答普及程度，需要采集当前主机、路由器或流量数据。

来源