IPv6文档新前缀：简化网络配置与培训示例

如果您曾经使用过IPv6，很可能在某些时候需要记录或描述网络设计或配置。如果您的组织已经拥有IPv6全局单播分配（GUA），您可能会倾向于直接使用该范围内的前缀和/或地址进行文档编写。毕竟，这些地址和前缀范围对您和您的团队来说已经很熟悉了。而且，如果该设计或配置将投入生产，确定实际要分配和使用的前缀和地址已经是必要步骤。

但在许多描述场景中，使用来自您的全局单播分配的前缀或地址并不理想。您可能正在构建一个仅用于初步审查和讨论的提议设计。在这种情况下使用GUA地址可能会让不知情的审阅者误以为该设计是已分配生产地址的计划或现有部署。尽管近年来许多企业的GUA分配足够大，或许可以分配一个专用的前缀用于内部文档，但您可能会在未来某个时候（可以说是遥远的未来）面临前缀空间受限的情况，导致您的文档与所需的生产地址重叠。

另一种情况可能是为培训材料或供应商文档开发示例，这些示例通常包括IPv6网络和协议的更通用描述。为此类示例使用GUA地址并没有太大意义——特别是如果这些示例要在组织外部或由供应商更广泛地分发。大多数组织不希望分享超出必要范围的IP空间信息（对于一些政府机构来说，此类信息即使不一定是机密的，也被视为敏感信息）。

因此，如果出于这些和其他原因使用您自己的IPv6 GUA空间不是最佳选择，为什么不干脆随意占用一些随机的GUA IPv6空间呢？如果您有任何良心上的不安，您甚至可以使用Whois来确保它尚未分配给其他组织。甚至还有大约75%的IPv6前缀空间尚未由IANA分配：您可以通过您谦逊的IPv6网络示例向世界首次展示这片广阔、未探索空间的一小部分！/讽刺

开个玩笑，拥有一个（或两个）专门用于文档的IPv6前缀有助于避免上述一些不理想的结果。使用正式的文档范围更清楚地传达给（知情的）审阅者，这些地址不打算在生产网络中配置和使用。

第一个也是最古老的IPv6文档前缀是IANA定义的前缀：

2001:db8::/32

IANA，如果您不熟悉的话，是互联网号码分配机构。他们负责分配和维护“用于驱动互联网的技术标准（‘协议’）中的唯一代码和编号系统”。这些包括——除其他特殊的IPv4和IPv6地址外——为文档目的保留的范围。

如果您忘记或从未了解过IPv4文档范围，它们定义在RFC 5737：IPv4地址块保留用于文档中，包括：

192.0.2.0/24
198.51.100.0/24
203.0.113.0/24

我承认，直到我了解了2001:db8::/32之后，我才完全意识到所有IPv4的专用文档范围。我怀疑这些范围对我来说不太熟悉的部分原因与供应商文档和培训材料实际使用它们的频率有关（至少就我注意到的而言）。进一步考虑，它们的不频繁使用或许是可以理解的。它们并没有提供足够多的地址空间来描述更大的部署。正如我们将要探讨的，这正是困扰第一个IPv6文档范围2001:db8::/32的问题。但在二十年前该前缀最初定义时，这一点远不明显，当时是在RFC 3849：IPv6地址前缀保留用于文档中。

在IPv6部署非常有限的早期，关于应使用多少IPv6空间的标准有些模糊。2001年，RFC 3177：IAB/IESG关于IPv6地址分配给站点的建议，推荐“在一般情况下分配/48，当已知只需要一个子网时分配/64，当绝对已知只有一个设备连接时分配/128”。快进到2011年，RFC 6177 IPv6地址分配给终端站点承认“一刀切的/48推荐对于广泛的终端站点来说不够细致，不再推荐作为单一默认值”。

但为了我们的分析，如果我们从/32的文档空间开始，并假设每个站点使用/48，我们似乎可以覆盖多达65,536个站点的任何网络。换句话说，可用的文档空间似乎绰绰有余。但这种明显的充足性取决于还假设一个有些过于简化的网络——可能是一个包含在单个自治系统内或作为单个自治系统一部分的网络。

从专注于地址规划的角度来看，IPv6前缀空间和地址的丰富性带来的最强大好处之一是在易于识别的半字节对齐前缀边界上汇总（并执行安全策略）的能力。

因此，组织内部（可能是一个单独的AS）的网络结构倾向于使用分配中更多可用的整体前缀空间。在IPv6的早期，只有最大的组织收到/32，所有内部规划和文档可能都可以用2001:db8::/32前缀完成。但随着组织认识到半字节对齐规划和汇总的好处，此类分配已经有机增长。区域互联网注册机构（RIR）的政策也随之调整，最具影响力的可能是RIPE最初转向为大多数组织分配最小/29。这种大小的前缀立即超出了原始/32文档范围的能力。当然，描述多个AS的服务提供商WAN文档和培训示例始终受限于这种有限的文档空间，因为每个AS可能至少使用/32或更大。

幸运的是，在IETF内部经过大量讨论后，一个新的IPv6文档范围请求最近在RFC中正式化，IANA随后很快分配了它：RFC 9637：扩展IPv6文档空间。

新的文档范围是：

3fff::/20

请注意，在发布时，RIR向请求者分配的/20或更大的分配只有30个（即1个/16，1个/17，3个/19和25个/20）。鉴于剩余99.96%的RIR分配是/21或更小，这个文档范围应该足以满足大多数示例——尤其是AS内部的示例。

如果您负责记录或建模具有现有GUA空间较大端前缀大小的AS间示例，您可能最终不得不在可用的/20之外发挥一点创意（并稍微违反一些规则）。

一个警示故事

在我兴奋地使用新文档前缀时，我立即从中构建了几个示例，用于我当时正在处理的一些培训材料。我想模拟一个具有/32分配的企业，并使用了以下示例前缀：3fff:9d00::/32。

看到我做了什么吗？好吧，直到我完成一个视频的一半以上后我才注意到，随后我不得不重新录制。😬

如果我更仔细地注意适当的半字节对齐，我会更早注意到我想要的前缀是3fff:9d0::/32。这不是第一次（也不会是最后一次）删除前导零的地址连接规则让我吃亏。

所以请始终记住，3fff::/20前缀包括第二个十六进制组的第一个半字节。额外强调前缀的重要半字节可以帮助视觉上强化这一点：

3fff:0000::/20

以下是来自/20的第一个半字节对齐前缀列表：

3fff:0000::/24
3fff:0100::/24
3fff:0200::/24
3fff:0300::/24
3fff:0400::/24
3fff:0500::/24
3fff:0600::/24
3fff:0700::/24
3fff:0800::/24
3fff:0900::/24
3fff:0a00::/24
3fff:0b00::/24
3fff:0c00::/24
3fff:0d00::/24
3fff:0e00::/24
3fff:0f00::/24

以下是这些前缀根据IPv6地址表示标准进行“零压缩”后的样子：

3fff::/24
3fff:100::/24
3fff:200::/24
3fff:300::/24
3fff:400::/24
3fff:500::/24
3fff:600::/24
3fff:700::/24
3fff:800::/24
3fff:900::/24
3fff:a00::/24
3fff:b00::/24
3fff:c00::/24
3fff:d00::/24
3fff:e00::/24
3fff:f00::/24

奇怪的供应商文档示例

请注意，使用IPv6地址的供应商文档、配置和示例经常使用无效地址。如果仅使用供应商示例来逆向工程有效文档范围的定义，即使不是不可能，也会很困难。

最近一个来自主要供应商的示例使用了以下前缀：

2001:1000::/64
2001:2000::/64

这些范围是整体全局单播分配（GUA）2000::/3的一部分，但当然落在实际可用的文档范围2001:db8::/32或3fff::/20之外。

同一个示例还包括似乎来自ULA范围的前缀（RFC 4193 唯一本地IPv6单播地址）：

fde0:1000::/64
fde1:1000::/64

但这些前缀没有遵循RFC关于正确ULA前缀和地址构建的指导。虽然前缀的第八位设置为1以指示前缀是本地分配的，但接下来的40位（由e0:1000:0000:和e1:1000:0000:表示）应该是随机生成的。这当然与许多人配置和使用ULA的方式非常常见（fd00:1::/48等，甚至fc00:1::/48，其中“c”是第八位，未设置为1，根据RFC表示当前未定义的IPv6地址空间）。

示例中的接下来两个前缀甚至更严重：

ffea:0000::/64
ffeb:0000::/64

这些占用了IPv6多播范围，但在示例中却被用作单播前缀！更不用说文档范围了：这些甚至不符合基本的有效IPv6地址架构。

希望供应商努力清理他们的文档，并在此过程中利用新的文档范围。同时，下次您需要记录IPv6网络时，试试这个新范围吧！