IPv6 经历过两代私有寻址方案：已废弃的站点本地地址和当前的唯一本地单播地址（ULA）。早期站点本地地址因“站点”定义模糊及网络合并时子网冲突问题被弃用，ULA 旨在解决这些缺陷，但工程实践中常被误作 IPv4 RFC 1918 的直接对应物，导致部署偏差。
站点本地地址为何被废弃：
站点本地地址使用 IANA 分配的 fec0::/10 前缀，最早见于 1995 年 RFC 1884 及其后续版本 RFC 4291。IETF IPv6 工作组在 2002 年前后发现两个核心问题：一是“站点”术语过于固定且带地理属性，通常指代建筑、园区或办公室，无法覆盖广域网、移动网络（如飞机、船舶、汽车网络）等跨站点或非固定场景的私有寻址需求；二是两个独立站点本地网络合并时，因人为配置易产生重复子网，IPv6 转发优先匹配最近实例导致远端重复网段不可达，解决冲突往往依赖 NAT，引入额外复杂性。
ULA 如何应对上述问题：
ULA 作为站点本地地址的替代方案，不再绑定“站点”概念，支持跨越多个地理位置的广域私有网络及移动网络拓扑。其设计目标是使不同管理域独立生成的前缀极低概率冲突，网络合并时无需重新编址或 NAT 即可保持可达性，从根本上避免了站点本地地址依赖 NAT 解决重叠的弊端。原文未给出 ULA 具体前缀生成算法与位长度细节。
运维常见误区与取舍：
工程实践中仍常将 ULA 等同于 IPv4 RFC 1918 地址直接套用，忽略 ULA 具备全局唯一性概率保障、不依赖 NAT 即可互联的特性。若将 ULA 视作纯粹本地隔离前缀，在跨域互联、云专线接入、移动网络漫游等场景会引入可达性风险；正确做法是遵循 IETF 后续标准生成全局唯一 ULA 前缀，并在路由策略中明确区分 ULA 与全球单播地址的转发边界。
对网络工程师而言，理解 ULA 非 RFC 1918 简单映射、掌握其全局唯一生成机制与无 NAT 互联特性，是构建可扩展 IPv6 私有网络、避免合并重编址与 NAT 依赖的关键。部署时应严格遵循随机前缀生成规范，在边界路由器实施显式路由控制而非依赖地址语义假设。
原文: APNIC Blog（2020-05-20）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog