[点晴永久免费OA]IPv4 地址耗尽,回收 E 类空间是否有意义?
当前位置:点晴OA办公管理信息系统
→『 经验分享&问题答疑 』
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类空间的大小以及与世界其他部分的不兼容。你可以利用这些地址构建一个庞大的网络,并保存与其他网络或客户设备交互的地址空间。 如今,我们已经看到了一些这样的用例,例如:
此外,Cloudflare有一个选项,可以将IPv6地址散列到E类地址中,作为不支持IPv6地址的系统访问IPv6的方式。这实际上是一种非常取巧的做法,目前尚不清楚是否有人真的在使用这个功能。 供应商的支持情况如果没有能够处理此类地址的设备,那么部署的讨论仅限于学术层面。在撰写本文之际,对此类地址的支持依然非常罕见。 支持此类地址的端点(即用户)软件:
不支持的端点:
而对于实际的网络设备,情况则更加复杂。为了测试兼容性,我建立了一个虚拟网络供应商测试实验室: ![]() 测试的目标是验证以下两个问题:
一些路由器供应商可以直接设置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对象,因为传输提供商和互联网交换路由服务器会自动过滤掉这些请求,防止其他网络知道这个网络前缀。 接受此网络前缀的网络包括:
其中一些结果让我感到有些惊讶,因为这意味着对于使用了这些网络的地方(有时候还包括它们的供应商),你可以宣布任何东西(也许不包括 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 该文章在 2024/6/24 8:38:28 编辑过 |
关键字查询
相关文章
正在查询... |