IPv4 地址空间分为 A、B、C、D 和 E 类，其中 E 类地址空间（240.0.0.0 至 255.255.255.255）最初是为实验和研究目的保留的，并没有分配给公共互联网使用。随着 IPv4 地址耗尽问题的加剧，回收和重新分配 E 类地址空间是否还有意义？本文作者进行了深入的分享。

原文链接：https://blog.benjojo.co.uk/post/class-e-addresses-in-the-real-world

作者 | Ben Cox       

责编 | 夏萌

译者 | 弯月

出品 | CSDN（ID：CSDNnews）

自从IPv4地址块的供应耗尽以来，市场发生了许多有趣的变化，主要是获取或租赁IPv4地址块的成本。由于IPv4寻址的需求并没有发生太大变化，价格上涨了，因此AWS、Hetzner、OVH等提供商以前将IPv4的成本纳入了产品定价中，现在则单独收费。

对于一些人来说，这笔支出很小，但如果你在2016年分配到了一个地址块，那么你将得到4个/24（当今互联网构建于BGP技术上，可以合理路由的最小单位是/24），然而，如果你的业务建立于2000年前后，则一个地址块可以轻松获得256个/24。

目前这些地址块的出售价格为：每个/24大约为1万美元。

然而，对于一些网络公司来说，这种价格的变化对业务成本的影响是灾难性的，一些行业以前习惯于为每个用户分配一个IPv4地址（或更多），如今却发现这种模式是不可持续的，而且除了部署运营商级NAT之外，他们别无选择。

如果说我们仍有相当于524288个/24的IPv4未被使用，情况会怎样？这类地址块被称为“E类空间”（即保留地址）。

IPv4 E类的起源故事

根据RFC1112的定义，E类空间位于IPv4地址空间的末尾，介于240.0.0.0~255.255.255.254之间，恰好在IPv4多播之后。这个空间始于1989年，但直到如今IPv4单播空间的大部分地址都已被分配，而E类空间一直被大多数人忽视，成为时代的遗物。

实际上，E类空间并不是现今人们正在考虑的唯一空间。在确定IPv4块标准化的过程中，由于当时的技术限制，进行了几次不必要的大量分配。代表性的例子包括0.0.0.0/8（如今看来0.0.0.0/24就足够了），还有127.0.0.0/8（本地回环块，127.0.0.0/16足以满足当时的需求）。

互联网自投入使用以来，地址块的最小分配单位为/8，后来又出现的“类”分配转而采用/16（这就是为什么我们经常看到大学或类似年龄的机构分配到了/16），后来又进一步演变为分配/24，直到最后互联网开始采用CIDR以更好地满足各种寻址需求。然而，0.0.0.0/8、127.0.0.0/8以及240.0.0.0/4等旧的分配从未被重新审查。

根据我的理解，240.0.0.0/4有望发展成为单播或多播之外的第三种类型的路由（目前仅限于想象）。

虽然有人正在努力将0.0.0.0/8、127.0.0.0/8变成可路由的单播空间，但本文其余部分将集中讨论240.0.0.0/4，因为这个话题最大且从技术的角度来看最有趣，而且将E类重新实现成单播空间，也能解决其他块所面临的问题。

现实的期望

归根结底，解决IPv4枯竭及其对获得IPv4空间的更广泛影响的答案是部署IPv6。然而，由于采用IPv6，所有网络也需要相应的实现，因此即使IPv4空间的速度越来越慢，可靠性很差，至少在很长一段时间互联网仍然离不开IPv4空间。

至于E类空间，我们不太可能看到这类空间被互联网路由表广泛接受。这是因为已有的设备和端点不兼容性，虽然这些问题如今已显现，但全球必须设法克服，而且全球范围内的升级行动几乎是不可能的。因此，即使提供E类空间，我们也不确定谁想要仅部分用户可用的IP地址。

E类空间作为本地单播空间

然而，全球路由并不是 IP 地址的唯一用途，如今本地网络和网络基础设施本身也消耗了大量的地址！由于这些用例倾向于使用RFC1918（例如10.0.0.0、192.168.0.0等空间），因此这些技术不太可能在家用领域得到应用。

但是，一些地方很容易“用完”本地地址。对于这种情况，E类空间是一个很好的补充，因为E类空间的大小以及与世界其他部分的不兼容。你可以利用这些地址构建一个庞大的网络，并保存与其他网络或客户设备交互的地址空间。

如今，我们已经看到了一些这样的用例，例如：

• AWS的一些网络设备使用了240.0.0.0/4。

• 一些家庭和中小型企业使用了E类空间。

• 一些非AWS网络也使用了E类空间。

• Canonical的“扇”网络使用了E类空间。

此外，Cloudflare有一个选项，可以将IPv6地址散列到E类地址中，作为不支持IPv6地址的系统访问IPv6的方式。这实际上是一种非常取巧的做法，目前尚不清楚是否有人真的在使用这个功能。

供应商的支持情况

如果没有能够处理此类地址的设备，那么部署的讨论仅限于学术层面。在撰写本文之际，对此类地址的支持依然非常罕见。

支持此类地址的端点（即用户）软件：

• 2008年之后的Linux发行版

• Android 2009

• 2009年之后的MacOS/OSX（包括苹果iOS）

• 2022年10月之后的 OpenBSD

不支持的端点：

• 所有已知Windows版本

• NetBSD/FreeBSD

而对于实际的网络设备，情况则更加复杂。为了测试兼容性，我建立了一个虚拟网络供应商测试实验室：

测试的目标是验证以下两个问题：

• 路由器之间是否可以使用E类地址？

• E类地址是否可以与OSPF和BGP等路由协议一起使用？

一些路由器供应商可以直接设置E类地址，而有一些则需特殊配置。例如，JunOS需要在配置中设置routing-options martians 240/4 orlonger allow，然后才能设置这些地址；与之类似，Arista EOS需要在配置中设置use ipv4 routable 240.0.0.0/4，才能接受E类地址。

还有一些供应商的接口则坚决拒绝设置E类地址。

还有一个问题是，在使用E类CIDR时，动态路由协议是否能正确运行？答案：有时可以。

然而，如果你计划在环境中部署此类地址空间，那么在使用OSPF/IS-IS等协议时，需要注意一些非常棘手的问题。

OSPF 的一些意外情况

在下面的例子中，假设我们有两个路由，一个支持将E类空间安装到数据（转发）平面中，另一个（诺基亚）则不支持。然而，由于OSPF的工作方式，路由将通过诺基亚路由器传递，就好像诺基亚可以路由这些地址，但由于诺基亚从未安装这些路由，因此可能丢弃或使用默认路由来传输流量。

如果让MikroTik跟踪路由到位于诺基亚路由器后面的E类地址，它会设法将E类地址发送到诺基亚路由器，但是流量会丢失；而尝试使用“常规”的单播地址（例如 6.6.6.6）时，流量会被转发：

这意味着，如果你想在这样的环境中部署E类空间，则必须确保路径中的所有设备（以及可能的备用路径）都支持E类空间，否则可能会丢失流量。

令人惊讶的真实测试

鉴于前面提到的问题，我本以为没必要进行真实的测试，然而几天后我收到了互联网交换邮件列表的如下电子邮件：

看到这封邮件，我非常惊讶。Quantcom的工作人员决定尝试使用E类，由于他们的客户使用了RIPE Atlas探针，我们可以进行“最佳案例”测试，检查真实的“SOHO”硬件如何处理E类空间：

大约为50%，并不算太糟糕，但距离我们的期望还有很大差距。Quantcom还有使用了RIPE Atlas 探针的BGP下游连接，因此我也做了测试：

结果也是50%！由于大多数RIPE Atlas硬件都部署在家庭和小型企业内部，因此我们可以预见，如果我们部署了E类空间，则最终设备的最大接受率约为50%。

我联系了Quantcom ，他们同意在前面提到的E类空间内进行一次IPv4网络扫描。如此，我们就能够确定Quantcom的哪些BGP接受了前缀，以及其基础设施能否路由E类IP地址。

扫描结果为，184,496 个 IP 地址响应了 ping，根据bgp.tools的地图数据，预计在所有网络前缀中会有380,286,307 个响应，也就是说Quantcom在全部网络前缀上的测试结果为可达性0.04％。

可达性如此之低，无疑是因为Quantcom只能通过互联网交换节点将测试网络前缀提供给其下游和直连的BGP对象，因为传输提供商和互联网交换路由服务器会自动过滤掉这些请求，防止其他网络知道这个网络前缀。

接受此网络前缀的网络包括：

• AS2686 AT&T 欧洲中东非

• AS3216 VEON / Beeline / VimpelCom

• AS5416 巴林电信公司

• AS6740 InterneXt 2000

• AS8926 Moldtelecom

• AS9050 Orange Romania

• AS13335 Cloudflare（仅限布拉格 PoP）

• AS16625 Akamai

• AS19281 Quad9

• AS20485 TransTeleKom（以及一些下游）

• AS25424 InterneXt

• AS28725 CETIN

其中一些结果让我感到有些惊讶，因为这意味着对于使用了这些网络的地方（有时候还包括它们的供应商），你可以宣布任何东西（也许不包括 RPKI 无效，但不确定），而它们会接受并在其网络中传播，包括它们的下游网络！

对于AS20485 TransTeleKom，184,496个IP中的大部分都能够响应。我只列出了互联网交换点接受了路由的网络。

在实践中，我们在BGP过滤方面仍有很长的路要走。如果更多的网络直接与Quantcom进行对等连接，如果供应商能够更好地支持这一路由，那么可能会有更多的网络接受这一路由。

你应该使用E类空间吗？

简单来说，一般情况下不应该使用。除非你对网络供应商的决定有超自然的控制，而且无法将所有工作负载迁移到 IPv6。但是，如果你有整个网络有控制权，那么E类空间在本地/私有寻址方面会提供很大的帮助。

那么，是否全球都可以访问E类空间？很明显，E类空间的采用面临着重重障碍。不仅需要修改10亿安装数量的用户软件，而且还需要在IANA和IETF内创建一个政策来改变该空间的用途。

现阶段，IETF正在进行的工作不涉及E类空间，我只能假设如果这一提议被接受，那将是一场旷日持久的斗争。而这也将引发第二场争论，即新创建的地址空间应该分配给哪个区域的RIR。虽然我们有5个RIR，但E空间内有8个/8的地址空间可供分配。目前尚不清楚如何分配。

最后，修改软件是非常困难的，使用E类空间将引发一系列极其困难的软件部署挑战。因为RIR的客户/成员肯定不愿意接受所有用户都不适用的地址空间。如果我们打算使用不适用于所有用户的地址空间，选择已经取得了很大进步并已被接收的地址空间IPv6更为明智。

————————————————

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

原文链接：https://blog.csdn.net/csdnnews/article/details/139847136