Can IPv4 Class E Addresses Revive Exhausted IP Space? A Deep Dive

Origin of IPv4 Class E

IPv4 address space is divided into classes A‑E. Class E occupies the range 240.0.0.0 – 255.255.255.254 (240.0.0.0/4) and was defined in RFC 1112 as reserved for experimental use. It has never been allocated for public Internet routing.

Practical expectations

The long‑term solution to IPv4 exhaustion is IPv6 deployment. Even after IPv6 is widely adopted, IPv4 will remain in use for many years, but class E is unlikely to be accepted in global routing tables because most existing hardware and operating systems treat the range as “martian” and drop the traffic. Upgrading billions of devices would be impractical.

Class E as a local unicast pool

Local networks often consume large private address blocks (RFC 1918: 10/8, 172.16/12, 192.168/16). When those pools are exhausted, the eight /8 blocks of class E provide a massive supplement for isolated environments, provided every device in the path supports the range.

AWS network devices have been observed using 240.0.0.0/4.

Some home and small‑business networks experiment with class E.

Canonical’s internal “fan” network uses class E.

Cloudflare offers an optional mapping that hashes IPv6 addresses into class E space for legacy systems, though real‑world adoption is unclear.

Vendor and OS support

Support for class E addresses is limited to relatively recent software releases:

Linux kernels released after 2008.

Android 2.3 (2009) and later.

macOS/OS X and iOS releases after 2009.

OpenBSD versions released after October 2022.

All known Windows versions, NetBSD, and FreeBSD reject class E traffic.

Lab tests and compatibility

A virtual lab was built to answer two questions:

Can routers exchange traffic using class E addresses?

Do dynamic routing protocols (OSPF, BGP) operate correctly with class E CIDR?

Configuration examples:

# JunOS (allows class E in the forwarding plane)
routing-options {
    martians 240/4 orlonger allow;
}

# Arista EOS (accepts class E as routable)
ipv4 routable 240.0.0.0/4

Some vendors reject the configuration outright.

OSPF unexpected behavior

If a router that supports class E advertises a route to a neighbor that does not support the range, OSPF will still propagate the prefix. The non‑supporting router discards the traffic or forwards it to a default route, causing loss of packets. Example: a MikroTik device forwards class E traffic to a Nokia router that drops it, while a normal unicast address (e.g., 6.6.6.6) is correctly forwarded.

Real‑world reachability tests

Using RIPE Atlas probes, roughly 50 % of SOHO‑class hardware accepted class E traffic. A BGP downstream test with the same probes yielded a similar 50 % success rate.

A large‑scale IPv4 scan of the entire class E block reported 184,496 responsive IPs, which is only 0.04 % of the expected 380 million addresses, indicating heavy filtering by upstream providers and exchange points.

Networks that accepted the 240.0.0.0/4 prefix included:

AS2686 – AT&T (EMEA)

AS3216 – VEON / Beeline

AS5416 – Bahrain Telecom

AS6740 – InterneXt 2000

AS8926 – Moldtelecom

AS9050 – Orange Romania

AS13335 – Cloudflare (Prague PoP)

AS16625 – Akamai

AS19281 – Quad9

AS20485 – TransTeleKom (and downstreams)

AS25424 – InterneXt

AS28725 – CETIN

Guidance on using Class E

Deploying class E is only advisable when you control the entire network topology and can guarantee that every device—including backup paths—recognizes the range. Global adoption faces three major hurdles:

Massive software updates across billions of endpoints.

Policy changes at IANA/IETF to re‑classify the space.

Allocation decisions among the five RIRs for the eight /8 blocks available.

Given the difficulty of modifying existing stacks and the ready availability of IPv6, the prudent choice is to transition to IPv6 rather than rely on class E as a stop‑gap.