240/4 As Seen by RIPE Atlas

The Internet Protocol version 4 (IPv4) leaves many addresses unallocated or reserved. The largest such block of addresses is 240/4 (the range 240.0.0.0 through 255.255.255.255).

Long-time Internet users may know these as "class E". In 1986, IP addresses were divided into five "address classes" (A through E), with A, B, and C for unicast addressing, D for multicast addressing, and E "reserved for future use". Each class contained between one-sixteenth and half of the entire IPv4 address space.

That scheme was replaced in 1993, when the Internet Engineering Task Force (IETF) introduced the Classless Inter-Domain Routing (CIDR) architecture for the unicast addresses, facilitating subnetting and route aggregation. Modern practice under CIDR refers to address blocks with a prefix and prefix length, separated by a slash. However, the class E addresses, while renamed to 240/4 in CIDR notation, remained reserved for future use.

The heightening scarcity of IPv4 address resources, along with the continued lack of any official use for these addresses, has prompted several discussions and initiatives over the years to repurpose the 268 million still-reserved addresses in the former class E. Two drafts at IETF in 2008 proposed such changes.

A draft proposed by V. Fuller et al. at IETF suggested reclassifying the address block 240/4 as unicast address space, which could subsequently be allocated for either public or private use. Similarly, P. Wilson et al. proposed redesignation of 240/4 from "Future Use" to "Limited Use for Large Private Internets" (essentially, a new private address block to complement those previously allocated by RFC 1918). However, neither draft progressed to adoption as an RFC. Opponents noted that the demand for IPv4 addresses is so large that even hundreds of millions of new addresses might quickly be exhausted. They maintained that organisations are better off accelerating the adoption of IPv6 in their networks since it provides a dramatically larger address pool. There is also controversy about the effort required to update operating systems and routers to allow routing 240/4 since software has historically been told to treat it as off-limits.

Since 2011, the regional Internet registries (RIRs) have run out of new IPv4 addresses to allocate to Internet networks. New IPv4 allocations are often handled on private markets for address resources. While IPv6 adoption has continued to grow, it has so far not obviated the demand for either public or private IPv4 address space. The IPv4 unicast extensions project has prepared a new set of drafts to make 240/4 (as well as other reserved address ranges) more usable, potentially adding several hundred million new IPs to the world. The authors also provide a list of major operating systems that already support unicast use of 240/4, which has become more widely supported in software since 2008. 

Of interest to the Internet measurement community, many reports allude to widespread existing unofficial use of 240/4 and other reserved address ranges. Most of this use appears to be unofficial private use which is not explicitly coordinated with the global Internet community. Essentially, some network operators seem to be following the scenario contemplated by the 2008 Wilson et al. draft.

There are several ways that references to private use of reserved addresses may leak into the public Internet (much as references to officially-reserved RFC 1918 addresses also leak outside of private networks). Among other possibilities, these addresses may appear in traceroutes as an unexpected portion of the path between two public addresses, they may appear in the results of DNS queries, or some networks and routers may filter them incorrectly and allow partial or complete connectivity between public and private networks.

RIPE Atlas Measurements

This article uses data from RIPE Atlas probes to find evidence of usage of 240/4 address space in the wild. We took a snapshot of traceroute, ping, and DNS data for 1 May 2022. We did not find any references to 240/4 addresses in DNS and ping measurements on that date. However, there were about 14.4 M traceroutes that contained one or more hops with 240/4 IPv4 addresses.

We find almost all of these traceroutes originated from two Amazon ASes (AS16509 and AS14618). The majority of the traceroutes, 12,160,892 (84%), originated from AS16509, while another 2,258,344 (15.6%) originated from another AS14618. These differences are most likely because of the coverage of RIPE Atlas probes within these ASes; we have 53 probes in AS16509 and only one probe in AS14618.

If we further inspect these traceroutes, we find a 240/4 IP address in the first hop for 8,671 traceroutes from probes in AS16509. Similarly, we see 313,227 traceroutes in AS14618, where the first hop has an IP address from 240/4 address space. Please find an example traceroute below with the first hop containing 240/4 address. These results provide us an indication that both the Amazon ASes use 240/4 address space in their AS, in conjunction with 172.16/12 space used to number customer instances.

Finding a needle in a haystack

Even though we find most traceroutes with source as one of the Amazon ASes, we also observe a few traceroutes outside Amazon. The following traceroute shows a hop with 240/4 between Vodafone (AS1273) and Adobe Inc. (AS15224). Note that the destination AS for the traceroute is AS15224 (Adobe Inc.), and the IP address before 240/4 also originates from AS15224. It is, therefore, likely that Adobe is using 240/4 address space. However, since there are timeouts after 240/4, we cannot say with certainty which AS is using 240/4 IP addresses.

In sum, we only found two companies that are using 240/4 IP space privately. Please note that this data is not fully representative since we only consider a snapshot of data from a single day, and it is also based on hops containing 240/4 addresses incidentally found in the wild and not targeted measurements. And, of course, RIPE Atlas probes are not present in every AS and are more concentrated in some parts of the Internet than others. So, it's possible that unofficial use of 240/4 is more widespread but remains partly invisible to these experiments.

Active measurements

RIPE Atlas probes running firmware 5060 and above can also directly send queries to 240/4 addresses. Currently, there are around 7,600 probes (63%) out of around 12,000 connected Atlas probes, which can send queries to 240/4 addresses. The number is expected to increase as more probe owners update the firmware.

We also performed some active measurements with 240/4 addresses as the target. The first active measurement was a traceroute between Amazon ASes to assess if there is a route between the two ASes. We selected a reserved address (240.3.12.67) previously found in traceroutes for AS14618. We then probed this IP address from a RIPE Atlas probe hosted in AS16509. The traceroute below shows that there is a route to the target IP address, but because of timeouts, we cannot say with certainty if the packet left the boundary of AS14618.

We also performed traceroutes to milliways.taht.net (255.255.255.254) from all the probes. We find 6,370 (87%) of traceroutes from a total of 7,285 had timeouts. We expected this behaviour since these packets should not be routed on the global Internet, and it is likely the border router dropped these packets before they could leave the network.

We also found that 34 probes were able to reach 255.255.255.254. All of these probes are hosted in AS701 (Verizon Business). The majority of these traceroutes have only two hops, which means that it is likely that AS701 is using this address. 

Finally, we had various error messages for the remaining traceroutes. For instance, we had a "Network Unreachable" error in 705 traceroutes. Similarly, 77 traceroutes had a "Host Not Available" error and 42 traceroutes terminated with an "Administratively denied" message.

Conclusions

There have been discussions on the Network Operator Group (NOG) lists indicating that Amazon Web Services (AWS) unofficially uses 240/4 as private address space. However, to the best of our knowledge, there is no official announcement by Amazon about the usage of 240/4 address space. Moreover, we did not find any 240/4 prefix in the official prefix list shared by Amazon.

Our work is the first to provide insights on the use of 240/4 address space and validates its usage by cloud providers, including Amazon and Verizon Business. We do not know the exact reason why these network providers are using reserved address space internally. We can only speculate that since they are an extremely large cloud provider, it is possible that they have run out of other private IP ranges (RFC 1918 designates a /8, a /12, and a /16, for a total of about 18 M private addresses).

It is also important to note here that Amazon has also acquired a large number of unicast IPv4 address blocks, and they continue to grow their inventory of IPv4 addresses. Andree Toonk, in 2020, estimated the total number of IPv4 addresses owned by AWS is just over 100 million (100,750,168). That's the equivalent of just over six /8's. If a cloud provider on Amazon's scale wanted to internally assign organisationally-unique RFC 1918 addresses to customer server and VM instances, it would probably have already run out of such addresses some time ago.

While the majority of network community members agree that IPv6 is the future, many people wonder why there is still a market for IPv4 and why hyper-giants like Amazon and Alibaba are investing in buying more IPv4 address space. One answer is that some networks are slow to adopt IPv6, while others who have already adopted it don't find it to be a perfect substitute for IPv4. A study of the IPv4/v6 transition by the Internet Governance Project at Georgia Tech examined the long-term dynamics of IPv4 and IPv6 deployment in 2019.

The report highlights that enterprise networks are particularly slow in adopting IPv6, especially for applications that are in production and are already earning them revenue. In the last few years, there has been a huge uptick in enterprise networks migrating their infrastructure and services to cloud service providers, which has increased the demand for IPv4 address space among cloud providers. The cloud providers have so far absorbed the rising cost of IPv4 addresses and have not passed it to their customers. Unless these organisations have economic or technological incentives, they will unlikely switch their services to support IPv6 in the near future. The networks that deploy IPv6 have to incur the cost of maintaining backward compatibility. In these cases, deploying IPv6 does not solve the problem of IPv4 exhaustion or increasing price points.

Although IPv6 adoption continues to increase, it appears likely that the logic of Wilson et al.'s draft has proven compelling for some large organisations. The IPv4 Unicast Extensions Project notes that a significant fraction of IPv4 implementations are already capable of using 240/4. If this holds true within a particular organisation, it may be tempting for that organisation to use portions of this address space unilaterally, without explicit coordination with the public. If so, we can expect to see more hints of the uses of this range in the future in Internet measurement data.

In summary, IPv4 and IPv6 will continue to co-exist until there are strong technological or economic incentives for most organisations to abandon IPv4 and migrate entirely to IPv6. However, until then, we might continue to see unofficial and uncoordinated use of Class E address space by large providers, especially cloud service providers. As some providers do restrict the routing of these addresses over the public Internet, these uses will mainly be private use on internal networks. Even so, if left unchecked, it will be challenging to assign this address space for any other use in the future.

I'd like to thank John Gilmore, Seth David Schoen, Dave Täht, and Emile Aben for their highly useful comments and input on earlier drafts of this article.