Looking for 240/4 addresses

If you look through the IANA’s IPv4 address registry you will find a set of reservations that collectively are encompassed by the address prefix 240/4, and are annotated in the registry for ‘Future Use’. These entries reference RFC 1112 Section 4, which states: “Class E IP addresses, i.e., those with “1111” as their high-order four bits, are reserved for future addressing modes.”

This address prefix encompasses 268,435,455 IPv4 addresses. From time it has prompted the obvious question: ‘If we have run out of available IPv4 addresses, then why are a quarter of a billion IPv4 addresses still sitting idle in an IANA registry waiting for an undefined Future Use?’ Surely, if there was to be some ‘future addressing mode’ to be defined in IPv4, then we would’ve done it by now. Why can’t we just add this pool of IP addresses into the all-but fully depleted pool of available IPv4 unicast addresses and relieve, to some small extent, some of the pressures that we have been experiencing with IPv4 depletion over the past decade?

The major points of discussion on this topic were recorded in a couple of Internet drafts from 2008. One of these, draft-wilson-class-e, advocated the redesignation of this address block for private use, extending the set of such local addresses to “assist in the IPv6 transition of larger networks who are using IPv4 in the context of a dual-stack deployment.”

In such contexts, it was reported that the reuse of network 10/8 was not an option because of existing use and potential address clashes (1918bis). The use of 240/4 offered a more conventional method to connect Consumer Premises Equipment (CPE) Network Address Translators (NATs) to the network’s border Carrier NATs without having to use more involved solutions such as Dual-Stack Lite (RFC 6333), NAT464 or 464XLAT (RFC 6877).

Another reason why a private use context was advocated for this address prefix was that it was believed that many IP implementations had implemented this reservation of the 240/4 address block within the IP code itself within end hosts, discarding the processing of any IP packet that had an address from this prefix as either the source or destination address. The address prefix was unsuitable for general use while significant populations of host protocol stacks contained this discard code. The other draft, fuller-240space, advocated the reclassification of this address block as conventional unicast address space, noting that “given the current consumption rate, it is clear that the block should not be left unused.”

Given that by 2008, when these drafts were submitted, the prospect of IPv4 address pool depletion was estimated to occur between 2010 and 2012, the discussion in the IETF turned to what would be the most productive use of the available time before the pools of available IPv4 addresses ran out. Consumption of IPv4 addresses was rising dramatically with the transition of mobile voice networks into mobile IP networks, and these networks were slow to adopt a dual-stack mode of operation.

By 2009 the annual IPv4 address consumption rate was rising to 190M addresses per year (see Addressing 2009), so an additional pool of 268M addresses would apparently defer the inevitable IPv4 address exhaustion by only 16 months or so. There was a prevalent view that the cumulative effort to update the hundreds of millions of IP hosts to accept IP addresses drawn from the address prefix 240/4 would probably take a comparable period, if not significantly longer, and such effort would form a distraction to the overall objective to rapidly transition all hosts and networks to support IPv6 before we experienced acute IPv4 address exhaustion pressures.

The mobile industry had gathered an unprecedented level of momentum at this stage, so our collective attention then turned to dual-stack transition mechanisms (at one point around 2010 more than 30 such IPv6 dual-stack transition mechanisms were being proposed!) and the associated effort to manage the remaining pools of available IPv4 addresses responsibly took up far more attention than the plight of this little corner of address space. These proposals to revive 240/4, either as private use space or as general unicast space, quietly languished.

Languished, yes, but the topic still resurfaces from time to time.

Measuring the usability of 240/4

There have been several exercises in recent years to see to what extent this address prefix is usable. A 2022 measurement exercise was reported in the RIPE Labs blog. An analysis of the traceroute data collected by the Atlas project indicated that, at the time, Amazon AWS (AS14618 and AS6509) were using this address block internally to address customer assets.

Other instances of internal private use of this address prefix were also apparent at the time, as evidenced by the traceroute reports of router interface addresses reporting the use of this address prefix in these traceroutes. It appears that the proposal described in draft-wilson-class-e for use in private contexts had apparently not fallen on totally deaf ears!

The second part of this measurement experiment involved setting up a server using an IP address drawn from the 240/4 address and directing 7,600 Atlas probes to perform a traceroute to this destination. They reported that 34 probes were able to reach this server, and all these probes were hosted in the AS701 (Verizon Business) network.

As a follow-up, I conducted a similar, but smaller-scale experiment using Atlas in July 2024. Just 1 of the 190 tested probes reached a host server (hosted in AS29208, Quantcom, Czech Republic). This network peers with DE-CIX, and the one successful traceroute appeared to transit DE-CIX to reach the server. A larger re-run of this experiment, using 1,000 randomly selected probes from the Atlas collection did not fare any better. Of some 967 probes that responded, all of them reported failure in reaching this server.

In measurement terms, the Atlas network is of medium size with 12,500 probes, but it is extremely flexible in terms of what the probes can be programmed to measure. At APNIC Labs we use a somewhat different measurement approach, based on enrolling users to perform a simple web object retrieval. This approach is less flexible, but by using an online ad network (Google Ads) to pass these retrieval tasks to end users, we can undertake measurements at a significantly larger scale both in volume and in coverage.

The ad program is currently running with a total of 25M ad impressions per day, which is significantly larger than the Atlas probe set. With this measurement system, we can place a simple web object on a server (a 1×1 pixel image using a .PNG image format, or a ‘blot’), and direct users to attempt to retrieve this object within the ad’s script. For this measurement the server is addressed with a host address drawn from the 240/4 prefix and the server’s network service provider advertises reachability to this server with a BGP announcement to its routing peers.

Before looking at the results of this measurement it may be useful to understand the problem space in reaching a destination that has an address drawn from this 240/4 prefix. There are several potential issues in trying to use such an address, including:

• Routers may reject packets with a destination address from 240/4.
• The configuration of a network’s routing environment may not accept a route advertisement for this prefix, or for more specifics of this prefix.
• CPE equipment that performs a NAT function may reject packets with source or destination addresses drawn from this prefix.
• For mobile networks, other forms of network middleware, such as carrier-grade NATs, may reject packets with source or destination addresses drawn from this prefix.
• End systems may reject packets with source or destination addresses drawn from this prefix.

Of the 788 total BGP peers for the Route Views and RIS systems, just three peers have propagated a route to a prefix drawn from 240/4, namely 242.242.0.0/16, originated by AS8747 and propagated via AS29208 (both networks are operated by Quantcom, in the Czech Republic). Another IPv4 network originated by the same AS, 109.235.180.0/24, is seen by a total of 702 separate peers of Route Views and RIS, so it would be reasonable to infer that there is widespread BGP filtering taking place for the 242.242.0.0/16 route.

$ traceroute 109.235.180.1
traceroute to 109.235.180.1 (109.235.180.1), 30 hops max, 60 byte packets
 1                     (10.210.2.210)              0.102 ms  0.025 ms  0.063 ms
 2                     (10.210.35.30)              0.215 ms  *         *
 3                     (10.210.32.1)               0.221 ms  0.423 ms  0.272 ms
 4  lo0-0.gw2.fra1.de.linode.com (139.162.129.102) 0.476 ms  0.326 ms  0.268 ms
 5  decix.quantcom.cz (80.81.192.217)              1.078 ms  0.995 ms  1.094 ms
 6  cz-prg-p1sit-be3.quantcom.cz (82.119.246.102)  7.832 ms  7.848 ms  7.815 ms
 7  * * *

$ traceroute 242.242.100.1
traceroute to 242.242.100.1 (242.242.100.1), 30 hops max, 60 byte packets
 1                 (10.210.2.210)                   0.100 ms  0.050 ms  0.036 ms
 2                 (10.210.35.30)                   0.669 ms  0.475 ms  0.290 ms
 3                 (10.210.32.1)                    0.203 ms  0.200 ms  0.180 ms
 4  lo0-0.gw2.fra1.de.linode.com (139.162.129.102)  0.500 ms  0.398 ms  0.402 ms
 5  ae18.r02.fra03.ien.netarch.akamai.com (23.210.54.18) 0.587 ms  0.611 ms  0.477 ms
 6  * * *

Measurement results for testing unicast reachability for 240/4

Now let’s look at the results of this experiment, shown at the economy level in Table 1.

Over a 14-day period from late August through early September we presented 130 million unique clients with tests to users drawn from across the entire Internet. The test included the direction to fetch a blot from this server addressed within the block 242.242.0.0/16.

We had low expectations because we observed that the interdomain routing space has not widely propagated the route for 242.242.0.0/16. Only three peers from RIS and RouteViews report seeing this route prefix, compared to about 702 peers for other prefixes announced by the same origin AS.

 On the other hand, this network directly peers with 913 other networks, so even if this route is not extensively propagated over transit networks so that it is seen at various route collectors, there is still a relatively rich domain of local propagation. Table 1 shows that access to endpoint addresses in the 240/4 prefix is largely limited to hosts located in Romania and the Czech Republic where the host’s network either peers directly with AS29208 or is very closely connected.

There are a small number of more anomalous entries in this table. What is going on where we see just a handful of connections from networks that are geolocated to the United States, Bahrain, and Greece? The most likely explanation is a geolocation error, where the user is actually within the area where 240/4 is visible, specifically in Eastern Europe. It is entirely possible that there is some form of infrastructure route tunnelling or web proxy activity where the route is leaking via a route tunnel, but the very small hit counts would tend to suggest some form of individually customized network or application configuration as distinct from a whole-of-network tunnelling configuration.

We can increase the level of detail to look at the extent of propagation of access of this service by access network rather than by geolocated economy of origin. The results of this accessibility measurement are shown in Table 2.

Table 2 — 240/4 accessibility by network.

The first five networks in Table 2, AS9050, AS29208, AS48161, AS28725, and AS39668 appear to have accepted the route to 242.242.0.0/16 into their network and have both a sizeable user base and have a high proportion of host platforms that also support communications with server addresses drawn from 240/4.

However, within the networks AS48161 and AS28725 the lower hit rate of 30% of tests suggests that there is a further factor here. A possible explanation lies in variations in the CPE equipment used in the interface between the client network and the service provider, on in the gateway equipment used to connect the network to the Internet. The user may also be using a ‘clean filter’ DNS resolver service where a name will not be resolved if the name is on some exception list, or, as may be the case here, the IP address is in a reserved address block.

There is also a ‘long tail’ in this table of more remote networks where just one or two tested users were seen to perform a successful fetch of this test blot. A possible explanation of these isolated anomalies may lie in using web proxy agents in the client-side network, as the IP address used to access this server is using networks that apparently have no route to this 242.242.0.0/16 prefix.

Observations

Is the address prefix 240/4 usable in a global unicast sense in the same way as all other IPv4 global unicast addresses? With a measured reachability rate drawn from across much of the Internet at just 0.0452%, it’s clear that it is not a generally reachable prefix, which implies that it is just not a useful address.

The intent of a unique unicast IP address in the Internet model is that any other host is capable of sending packets to it and receiving packets from it. It’s clear from these measurements that this is just not happening for this test server.

In the most general terms, there are three causes of reachability failure:

• Network routing, where the routing system does not propagate a route for a prefix drawn from 240/4
• Host filtering, where the host performs some form of address check on outgoing and possibly incoming packets and will discard IP packets with destination and/or source addresses drawn from 240/4.
• Middleware filtering, where various forms of network middleware, generally NATs, will not process a packet being directed to a 240/4 destination address.

The minimal propagation of the route 242.242.0.0/16 indicates that route filtering is a widespread practice. This may be due to a particular block for the 240/4 prefix or a more general route ‘bogon filter’, where routes drawn from IANA reserved address blocks are rejected.

The very high hit rates in some networks in Table 2 appear to indicate that host filtering is not a major block for using addresses from this prefix.

The lower hit rates or around 30% for some networks pose an interesting question. Is filtering of this prefix a property of some consumer premises equipment (CPE) used by clients? Is this a behaviour of some network-level Carrier-Grade NATs (CGNs) used by some networks? In the case of Germany, Austria, Hungary and Romania, all of which are ‘close’ to the Czech Republic there is a reasonable level of IPv6 adoption. Are the dual-stack transition mechanisms being used in some of these networks dropping IPv4 packets addressed to this 240/4 address?

Should we do anything about this? Or not?

The Internet is big enough that any form of a coordinated change, such as a ‘flag day’, to enable access to 240/4 in networks, middleware and hosts is just not a realistic approach. For adoption in today’s Internet, any technology must be deployable in a piecemeal fashion. However, in general, piecemeal adoption is generally motivated by the perception of early adopter rewards. These rewards motivate additional adopters and momentum gathers if all is going well.

But in the case of addresses, the extremely limited visibility of services that use this address, and the limited ability of other users to access services that are addressed from this prefix suggest that there is an early adopter penalty rather than any form of reward. That tends to make piecemeal adoption for the use of this prefix as a general-purpose unicast address a forbidding proposition.

The 2008 advice contained in the wilson-class-e draft (where I’ll own up to being a co-author), which advocated the designation of this address space as ‘Private Use’ seemed to me to be the most sensible approach then, and now, 16 years later the approach still makes some sense to me. Such use allows a network operator to use these addresses in a controlled environment where the operators can assure themselves that the addresses are fully functional in their desired limited context of use.

However, in many ways, there is little that prevents a network operator from using addresses drawn from 240/4 in their internal environment already, as has been reported in traceroute data by Amazon collected by RIPE Atlas. Such a private use will not clash with any existing unicast addresses. This form of entirely private use of this IANA-reserved address block is, pragmatically speaking, already an option today and doesn’t require any particular IANA re-designation of the address block, so the obvious question is why bother with an IANA re-designation in any case.

It appears that the status quo is entirely adequate for the 240/4 address prefix!

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.