讯享网

 <p class="f_center"><img src="http://dingyue.ws.126.net/2024/0620/70f86f48g00sfdd1i000dd200hs0028g00g20020.gif"/><br/></p><p id="2Q47L1E5">IPv4 地址空间分为 A、B、C、D 和 E 类，其中 E 类地址空间（240.0.0.0 至 255.255.255.255）最初是为实验和研究目的保留的，并没有分配给公共互联网使用。随着 IPv4 地址耗尽问题的加剧，回收和重新分配 E 类地址空间是否还有意义？本文作者进行了深入的分享。</p><p id="2Q47L1E6">原文链接：https://blog.benjojo.co.uk/post/class-e-addresses-in-the-real-world</p><p id="2Q47L1EA">作者 | Ben Cox 责编 | 夏萌<br/></p><p id="2Q47L1EB">译者 | 弯月</p><p id="2Q47L1EC">出品 | CSDN（ID：CSDNnews）</p><p id="2Q47L1ED">自从IPv4地址块的供应耗尽以来，市场发生了许多有趣的变化，主要是获取或租赁IPv4地址块的成本。由于IPv4寻址的需求并没有发生太大变化，价格上涨了，因此AWS、Hetzner、OVH等提供商以前将IPv4的成本纳入了产品定价中，现在则单独收费。</p><p id="2Q47L1EE">对于一些人来说，这笔支出很小，但如果你在2016年分配到了一个地址块，那么你将得到4个/24（当今互联网构建于BGP技术上，可以合理路由的最小单位是/24），然而，如果你的业务建立于2000年前后，则一个地址块可以轻松获得256个/24。</p><p id="2Q47L1EF">目前这些地址块的出售价格为：每个/24大约为1万美元。</p><p id="2Q47L1EG">然而，对于一些网络公司来说，这种价格的变化对业务成本的影响是灾难性的，一些行业以前习惯于为每个用户分配一个IPv4地址（或更多），如今却发现这种模式是不可持续的，而且除了部署运营商级NAT之外，他们别无选择。</p><p id="2Q47L1EH">如果说我们仍有相当于个/24的IPv4未被使用，情况会怎样？这类地址块被称为“E类空间”（即保留地址）。</p><p><br/><strong>IPv4 E类的起源故事</strong></p><p id="2Q47L1EI">根据RFC1112的定义，E类空间位于IPv4地址空间的末尾，介于240.0.0.0~255.255.255.254之间，恰好在IPv4多播之后。这个空间始于1989年，但直到如今IPv4单播空间的大部分地址都已被分配，而E类空间一直被大多数人忽视，成为时代的遗物。</p><p id="2Q47L1EJ">实际上，E类空间并不是现今人们正在考虑的唯一空间。在确定IPv4块标准化的过程中，由于当时的技术限制，进行了几次不必要的大量分配。代表性的例子包括0.0.0.0/8（如今看来0.0.0.0/24就足够了），还有127.0.0.0/8（本地回环块，127.0.0.0/16足以满足当时的需求）。</p><p id="2Q47L1EK">互联网自投入使用以来，地址块的最小分配单位为/8，后来又出现的“类”分配转而采用/16（这就是为什么我们经常看到大学或类似年龄的机构分配到了/16），后来又进一步演变为分配/24，直到最后互联网开始采用CIDR以更好地满足各种寻址需求。然而，0.0.0.0/8、127.0.0.0/8以及240.0.0.0/4等旧的分配从未被重新审查。</p><p id="2Q47L1EL">根据我的理解，240.0.0.0/4有望发展成为单播或多播之外的第三种类型的路由（目前仅限于想象）。</p><p id="2Q47L1EM">虽然有人正在努力将0.0.0.0/8、127.0.0.0/8变成可路由的单播空间，但本文其余部分将集中讨论240.0.0.0/4，因为这个话题最大且从技术的角度来看最有趣，而且将E类重新实现成单播空间，也能解决其他块所面临的问题。</p><p><br/><strong>现实的期望</strong></p><p id="2Q47L1EN">归根结底，解决IPv4枯竭及其对获得IPv4空间的更广泛影响的答案是部署IPv6。然而，由于采用IPv6，所有网络也需要相应的实现，因此即使IPv4空间的速度越来越慢，可靠性很差，至少在很长一段时间互联网仍然离不开IPv4空间。</p><p id="2Q47L1EO">至于E类空间，我们不太可能看到这类空间被互联网路由表广泛接受。这是因为已有的设备和端点不兼容性，虽然这些问题如今已显现，但全球必须设法克服，而且全球范围内的升级行动几乎是不可能的。因此，即使提供E类空间，我们也不确定谁想要仅部分用户可用的IP地址。</p><p><br/><strong>E类空间作为本地单播空间</strong></p><p id="2Q47L1EP">然而，全球路由并不是 IP 地址的唯一用途，如今本地网络和网络基础设施本身也消耗了大量的地址！由于这些用例倾向于使用RFC1918（例如10.0.0.0、192.168.0.0等空间），因此这些技术不太可能在家用领域得到应用。</p><p id="2Q47L1EQ">但是，一些地方很容易“用完”本地地址。对于这种情况，E类空间是一个很好的补充，因为E类空间的大小以及与世界其他部分的不兼容。你可以利用这些地址构建一个庞大的网络，并保存与其他网络或客户设备交互的地址空间。</p><p id="2Q47L1ER">如今，我们已经看到了一些这样的用例，例如：</p><p><ul><li id="2Q47L1H0"></p><p id="2Q47L1ES">AWS的一些网络设备使用了240.0.0.0/4。</p><p></li><li id="2Q47L1H1"></p><p id="2Q47L1ET">一些家庭和中小型企业使用了E类空间。</p><p></li><li id="2Q47L1H2"></p><p id="2Q47L1EU">一些非AWS网络也使用了E类空间。</p><p></li><li id="2Q47L1H3"></p><p id="2Q47L1EV">Canonical的“扇”网络使用了E类空间。</p><p></li></ul></p><p id="2Q47L1F0">此外，Cloudflare有一个选项，可以将IPv6地址散列到E类地址中，作为不支持IPv6地址的系统访问IPv6的方式。这实际上是一种非常取巧的做法，目前尚不清楚是否有人真的在使用这个功能。</p><p><br/><strong>供应商的支持情况</strong></p><p id="2Q47L1F1">如果没有能够处理此类地址的设备，那么部署的讨论仅限于学术层面。在撰写本文之际，对此类地址的支持依然非常罕见。</p><p id="2Q47L1F2">支持此类地址的端点（即用户）软件：</p><p><ul><li id="2Q47L1H4"></p><p id="2Q47L1F3">2008年之后的Linux发行版</p><p></li><li id="2Q47L1H5"></p><p id="2Q47L1F4">Android 2009</p><p></li><li id="2Q47L1H6"></p><p id="2Q47L1F5">2009年之后的MacOS/OSX（包括苹果iOS）</p><p></li><li id="2Q47L1H7"></p><p id="2Q47L1F6">2022年10月之后的 OpenBSD</p><p></li></ul></p><p id="2Q47L1F7">不支持的端点：</p><p><ul><li id="2Q47L1H8"></p><p id="2Q47L1F8">所有已知Windows版本</p><p></li><li id="2Q47L1H9"></p><p id="2Q47L1F9">NetBSD/FreeBSD</p><p></li></ul></p><p id="2Q47L1FA">而对于实际的网络设备，情况则更加复杂。为了测试兼容性，我建立了一个虚拟网络供应商测试实验室：</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F0620%2Fb97027adj00sfdd1l0030d200p000ixg00id00dw.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="2Q47L1FC">测试的目标是验证以下两个问题：</p><p><ul><li id="2Q47L1HA"></p><p id="2Q47L1FD">路由器之间是否可以使用E类地址？</p><p></li><li id="2Q47L1HB"></p><p id="2Q47L1FE">E类地址是否可以与OSPF和BGP等路由协议一起使用？</p><p></li></ul></p><p id="2Q47L1FF">一些路由器供应商可以直接设置E类地址，而有一些则需特殊配置。例如，JunOS需要在配置中设置routing-options martians 240/4 orlonger allow，然后才能设置这些地址；与之类似，Arista EOS需要在配置中设置use ipv4 routable 240.0.0.0/4，才能接受E类地址。</p><p id="2Q47L1FG">还有一些供应商的接口则坚决拒绝设置E类地址。</p><p id="2Q47L1FH">还有一个问题是，在使用E类CIDR时，动态路由协议是否能正确运行？答案：有时可以。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F0620%2F8bf8819fj00sfdd1l000cd200hm008mg00hm008m.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="2Q47L1FJ">然而，如果你计划在环境中部署此类地址空间，那么在使用OSPF/IS-IS等协议时，需要注意一些非常棘手的问题。</p><p><br/><strong>OSPF 的一些意外情况</strong></p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F0620%2F6614dd7bj00sfdd1n0016d200jg007yg00id007i.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="2Q47L1FL">在下面的例子中，假设我们有两个路由，一个支持将E类空间安装到数据（转发）平面中，另一个（诺基亚）则不支持。然而，由于OSPF的工作方式，路由将通过诺基亚路由器传递，就好像诺基亚可以路由这些地址，但由于诺基亚从未安装这些路由，因此可能丢弃或使用默认路由来传输流量。</p><p id="2Q47L1FM">如果让MikroTik跟踪路由到位于诺基亚路由器后面的E类地址，它会设法将E类地址发送到诺基亚路由器，但是流量会丢失；而尝试使用“常规”的单播地址（例如 6.6.6.6）时，流量会被转发：</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F0620%2F434ca736j00sfdd1o005dd200jg00cjg00id00bt.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="2Q47L1FO">这意味着，如果你想在这样的环境中部署E类空间，则必须确保路径中的所有设备（以及可能的备用路径）都支持E类空间，否则可能会丢失流量。</p><p><br/><strong>令人惊讶的真实测试</strong></p><p id="2Q47L1FP">鉴于前面提到的问题，我本以为没必要进行真实的测试，然而几天后我收到了互联网交换邮件列表的如下电子邮件：</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F0620%2Fj00sfdd1p001nd200hh0078g00hh0078.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="2Q47L1FR">看到这封邮件，我非常惊讶。Quantcom的工作人员决定尝试使用E类，由于他们的客户使用了RIPE Atlas探针，我们可以进行“**案例”测试，检查真实的“SOHO”硬件如何处理E类空间：</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F0620%2Fe85bb22bj00sfdd1p0068d200p000e5g00id00ad.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="2Q47L1FT">大约为50%，并不算太糟糕，但距离我们的期望还有很大差距。Quantcom还有使用了RIPE Atlas 探针的BGP下游连接，因此我也做了测试：</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F0620%2Fd0fc0518j00sfdd1q0044d200p0007vg00id005r.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="2Q47L1FV">结果也是50%！由于大多数RIPE Atlas硬件都部署在家庭和小型企业内部，因此我们可以预见，如果我们部署了E类空间，则最终设备的最大接受率约为50%。</p><p id="2Q47L1G0">我联系了Quantcom ，他们同意在前面提到的E类空间内进行一次IPv4网络扫描。如此，我们就能够确定Quantcom的哪些BGP接受了前缀，以及其基础设施能否路由E类IP地址。</p><p id="2Q47L1G1">扫描结果为，184,496 个 IP 地址响应了 ping，根据bgp.tools的地图数据，预计在所有网络前缀中会有380,286,307 个响应，也就是说Quantcom在全部网络前缀上的测试结果为可达性0.04％。</p><p id="2Q47L1G2">可达性如此之低，无疑是因为Quantcom只能通过互联网交换节点将测试网络前缀提供给其下游和直连的BGP对象，因为传输提供商和互联网交换路由服务器会自动过滤掉这些请求，防止其他网络知道这个网络前缀。</p><p id="2Q47L1G3">接受此网络前缀的网络包括：</p><p><ul><li id="2Q47L1HC"></p><p id="2Q47L1G4">AS2686 AT&amp;T 欧洲中东非</p><p></li><li id="2Q47L1HD"></p><p id="2Q47L1G5">AS3216 VEON / Beeline / VimpelCom</p><p></li><li id="2Q47L1HE"></p><p id="2Q47L1G6">AS5416 巴林电信公司</p><p></li><li id="2Q47L1HF"></p><p id="2Q47L1G7">AS6740 InterneXt 2000</p><p></li><li id="2Q47L1HG"></p><p id="2Q47L1G8">AS8926 Moldtelecom</p><p></li><li id="2Q47L1HH"></p><p id="2Q47L1G9">AS9050 Orange Romania</p><p></li><li id="2Q47L1HI"></p><p id="2Q47L1GA">AS13335 Cloudflare（仅限布拉格 PoP）</p><p></li><li id="2Q47L1HJ"></p><p id="2Q47L1GB">AS16625 Akamai</p><p></li><li id="2Q47L1HK"></p><p id="2Q47L1GC">AS19281 Quad9</p><p></li><li id="2Q47L1HL"></p><p id="2Q47L1GD">AS20485 TransTeleKom（以及一些下游）</p><p></li><li id="2Q47L1HM"></p><p id="2Q47L1GE">AS25424 InterneXt</p><p></li><li id="2Q47L1HN"></p><p id="2Q47L1GF">AS28725 CETIN</p><p></li></ul></p><p id="2Q47L1GG">其中一些结果让我感到有些惊讶，因为这意味着对于使用了这些网络的地方（有时候还包括它们的供应商），你可以宣布任何东西（也许不包括 RPKI 无效，但不确定），而它们会接受并在其网络中传播，包括它们的下游网络！</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F0620%2F9bcf09b2j00sfdd1r004hd200je00hcg00id00ge.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="2Q47L1GI">对于AS20485 TransTeleKom，184,496个IP中的大部分都能够响应。我只列出了互联网交换点接受了路由的网络。</p><p id="2Q47L1GJ">在实践中，我们在BGP过滤方面仍有很长的路要走。如果更多的网络直接与Quantcom进行对等连接，如果供应商能够更好地支持这一路由，那么可能会有更多的网络接受这一路由。</p><p><br/><strong>你应该使用E类空间吗？</strong></p><p id="2Q47L1GK">简单来说，<strong>一般情况下不应该使用。</strong>除非你对网络供应商的决定有超自然的控制，而且无法将所有工作负载迁移到 IPv6。但是，如果你有整个网络有控制权，那么E类空间在本地/私有寻址方面会提供很大的帮助。</p><p id="2Q47L1GL"><strong>那么，是否全球都可以访问E类空间？很明显，E类空间的采用面临着重重障碍。</strong>不仅需要修改10亿安装数量的用户软件，而且还需要在IANA和IETF内创建一个政策来改变该空间的用途。</p><p id="2Q47L1GM">现阶段，IETF正在进行的工作不涉及E类空间，我只能假设如果这一提议被接受，那将是一场旷日持久的斗争。而这也将引发第二场争论，即新创建的地址空间应该分配给哪个区域的RIR。虽然我们有5个RIR，但E空间内有8个/8的地址空间可供分配。目前尚不清楚如何分配。</p><p id="2Q47L1GN">最后，修改软件是非常困难的，使用E类空间将引发一系列极其困难的软件部署挑战。因为RIR的客户/成员肯定不愿意接受所有用户都不适用的地址空间。如果我们打算使用不适用于所有用户的地址空间，选择已经取得了很大进步并已被接收的地址空间IPv6更为明智。</p><p id="2Q47L1GS">由 CSDN 和 Boolan 联合主办的「2024 全球软件研发技术大会（SDCon）」将于 7 月 4 -5 日在北京威斯汀酒店举行。<br/></p><p id="2Q47L1GT">由世界著名软件架构大师、云原生和微服务领域技术先驱 Chris Richardson 和 MIT 计算机与 AI 实验室(CSAIL)副主任，ACM Fellow Daniel Jackson 领衔，BAT、微软、字节跳动、小米等技术专家将齐聚一堂，共同探讨软件开发的最前沿趋势与技术实践。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F0620%2Fceb66e2aj00sfdd1s00bdd200u00240g00it01bn.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p>