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