IPv6文档新前缀：3fff::/20的诞生与应用

新前缀让IPv6文档编写前所未有的简单

如果你曾参与IPv6相关工作，很可能遇到过需要记录网络设计或配置的场景。若组织已拥有IPv6全球单播地址分配（GUA），可能会直接使用这些地址进行文档编写——毕竟团队对这些前缀更熟悉。但以下场景中，使用实际GUA地址并非最佳选择：

• 设计草案评审：使用真实GUA可能导致评审者误认为这是已部署的生产配置。
• 培训材料开发：面向外部发布的示例若包含组织专属地址，可能泄露敏感信息（尤其对政府机构而言）。

为什么不随便占用未分配的GUA？

尽管可以临时占用未分配的IPv6地址（例如IANA尚未分配的75%地址空间），但规范的做法是使用专为文档设计的保留前缀。

官方文档前缀演进

1. 传统前缀：2001:db8::/32（RFC 3849定义）
   • 适用于早期小型网络（假设每个站点分配/48，最多支持65,536个站点）。
   • 但现代网络常需要更大空间（如RIPE最低分配/29），导致该前缀逐渐不够用。
2. 新前缀：3fff::/20（RFC 9637定义）
   • 覆盖99.96%的现有GUA分配需求（目前仅30个/20以上分配记录）。
   • 支持更灵活的半字节对齐规划（例如3fff:900::/24）。

实际应用示例与陷阱

• 正确用法： 3fff::/24 # 完全展开：3fff:0000::/24undefined3fff:d00::/24 # 对应3fff:0d00::/24
• 常见错误：
  • 错误使用非文档地址（如2001:1000::/64）。
  • 误用多播地址（如ffea::/64）作为单播前缀。

厂商文档的乱象

部分厂商示例中仍存在不规范地址：

• 非法ULA（唯一本地地址）配置：fde0:1000::/64（未按RFC 4193要求随机生成40位）。
• 直接占用多播范围：ffeb::/64。

建议：充分利用3fff::/20新前缀，确保文档的规范性和可读性。