特殊前缀的意义
IPv6 把地址用途写进了前缀本身：文档示例、隧道、翻译、内网各有专属段，且由 IANA 与 RFC 统一分配。认出前缀就能立刻判断这条地址该不该出现在生产网、能不能全球路由、是否已被主流弃用。
特殊前缀全表
| 前缀 | 用途 | 依据 |
|---|---|---|
| 2001:db8::/32 | 文档示例（最常用） | RFC 3849 |
| 3fff::/20 | 文档示例（2024 年新增） | RFC 9637 |
| 2002::/16 | 6to4 隧道，已不推荐 | RFC 3056 |
| 2001::/32 | Teredo 隧道 | RFC 4380 |
| 64:ff9b::/96 | NAT64 知名前缀 | RFC 6052 |
| 64:ff9b:1::/48 | 本地使用 NAT64 前缀 | RFC 8215 |
| 2001:2::/48 | 基准测试 | RFC 5180 |
| fc00::/7 | 唯一本地地址 ULA（可用 fd00::/8） | RFC 4193 |
| fe80::/10 | 链路本地地址 LLA | RFC 4291 |
| ff00::/8 | 组播 | RFC 4291 |
| ::1/128 与 ::/128 | 回环与未指定地址 | RFC 4291 |
使用要点
- 写文档、教材、工单示例一律用 2001:db8::/32 或 3fff::/20，避免泄露真实前缀
- 内网不想用公网段时选 fd00::/8，并按 RFC 4193 随机生成 40 位全局 ID，防止与并购方网络撞车
- 做 NAT64 实验先确认前缀是 64:ff9b::/96 还是本地 64:ff9b:1::/48，两者混用会导致合成地址对不上
- 看到 2002::/16 或 2001::/32 基本可判定为历史遗留隧道配置，评估下线并改用原生双栈
- 规划表里标注每个网段的用途类别，便于审计时一眼识别“文档前缀误入生产”
程序判定前缀归属
程序判定前缀归属
python - <<'PY'
import ipaddress as ipa
for c in ['2001:db8::1', '64:ff9b::198.51.100.7', 'fd00:1234::1', 'fe80::1']:
a = ipa.IPv6Address(c)
print(c, 'private=%s' % a.is_private, 'global=%s' % a.is_global)
# 2001:db8::1 非全局；fe80::1 与 fd00::/8 均判为 private
PY段位与规模速记
| ULA 结构 | fd00::/8 内 40 位全局 ID + 16 位子网 ID，共 /48 起分 |
|---|---|
| LLA 结构 | fe80::/10 加 64 位接口标识，同一网卡每链路一个 |
| 组播结构 | ff0X 中 X 为范围，2 为链路、5 为站点、e 为全球 |
| 隧道段现状 | 2002::/16 与 2001::/32 已不被主流运营商推荐 |
| 通用规则 | 前 3 位决定地址种类：001 全球单播、111 组播、1111 1110 11 链路本地 |
现场判断口诀
- 前 3 位是 001：全球单播，但要再查是否落在文档或隧道专用段
- 以 fe80 开头：链路本地，出了本段就不可达，远程管理必须带 zone id
- 以 ff 开头：组播，看第 2 字节低 4 位判断能走多远
- 以 fd 开头：本地唯一，永远不会被互联网路由，内部规划可放心使用
- 以 2001:db8 或 3fff 开头：文档示例，生产环境出现即为配置事故
文档前缀只能出现在教材与测试中：生产网络里出现 2001:db8:: 或 3fff::，几乎一定是复制模板没改，会直接导致业务不可达。