The ISP Column A column on things Internet
	Other Formats:

Looking for 240/4 Addresses
September 2024

If you look through the IANA’s IPv4 address registry you will find a set of reservations which collectively are encompasses 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 some 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 some 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 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 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 some 190M addresses per year (see "Addressing 2009""), so an additional pool of 268M addresses would apparently defer the inevitable IPv4 address exhaustion by only some 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 as 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 there were more than 30 such IPv6 dual stack transition mechanisms being proposed!) and the associated effort to manage the remaining pools of available IPv4 addresses in a responsible manner 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 Usability of 240/4

There have been number of 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 some 7,600 Atlas probes to perform a traceroute to this destination. They reported that some 34 probes were able to reach this server, and all of these probes were hosted in the AS701 (Verizon Business) network.

As a follow-up for this article, I have 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 some 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 are able to undertake measurements at a significantly larger scale both in volume and in coverage. The ad program is currently running with a total of some 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 1x1 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 understand the problem space in reaching a destination that has an address drawn from this 240/4 prefix. There are a number of 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 3 peers have propagated a route to a prefix drawn from 240/4, namely 242.242.0.0/16, originated by AS 8747 and propagated via AS 29208 (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 some 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 a country level in Table 1.

CC	Tests	Hits	Rate	CC Name
RO	1,313,452	42,814	3.2597%	Romania
CZ	985,470	15,162	1.5386%	Czech Republic
SK	198,416	532	0.2681%	Slovakia
RU	48,574	270	0.5559%	Russian Federation
AE	137,308	92	0.0670%	United Arab Emirates
US	4,539,376	34	0.0007%	United States of America
BH	32,302	8	0.0248%	Bahrain
GR	61,106	2	0.0033%	Greece
Total:	130,298,477	58,914	0.0452%

Table 1 – 240/4 Accessibility by Country

Over a 14-day period from late August through early September we presented some 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.

Our expectations were understandably low, as we have already noted that the interdomain routing space has not propagated the route for 242.242.0.0/16 very far, and just 3 RIS and RouteViews peers report visibility of this route prefix, compared to some 702 peers for other prefixes advertised from 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 an 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 AS 29208 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 failure, where the user in question is indeed located within the realm if visibility of 240/4 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 individual customised 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 country of origin. The results of this accessibility measurement are shown in Table 2.

AS	CC	Tests	Hits	Rate	AS Name
9050	RO	40,952	34,990	85.4415%	RTD Bucharest
29208	CZ	6,898	5,236	75.9061%	QUANTCOM-AS
48161	RO	15,374	4,682	30.4540%	NG-AS Sos. Bucharest
28725	CZ	8,406	2,768	32.9289%	CETIN-AS
39668	RO	2,652	2,290	86.3499%	AS-INTERSAT_CT
25424	CZ	2,778	2,202	79.2657%	INEXT-CZ
6740	CZ	1,648	1,500	91.0194%	INEXT-CZ-ADA
209947	CZ	976	936	95.9016%	MWIFI
205619	CZ	816	790	96.8137%	ASVESNET
48926	CZ	1,196	616	51.5050%	PE3NY-AS
60895	SK	638	384	60.1881%	LEKOS
196952	CZ	342	328	95.9064%	ASBEZVANET
35725	RO	37,528	202	0.5383%	TELEKOM
57825	CZ	174	164	94.2529%	MORAVANYNET-AS
52029	CZ	320	150	46.8750%	ASNOVOSEDLY
34315	CZ	132	132	100.0000%	MAXNET-AS
20485	RU	110	108	98.1818%	TRANSTELECOM MOSCOW
214529	RO	106	106	100.0000%	DSNET
12905	SK	106	106	100.0000%	ACS-SK-AS,
205275	RO	298	106	35.5705%	ROMARG HOSTING
206382	RO	142	100	70.4225%	NEXTSTART
34560	RO	100	92	92.0000%	SOFTEX-AS
197083	CZ	86	86	100.0000%	K2ATMITEC
199405	CZ	98	84	85.7143%	OSLAVANY-NET-AS
44081	RO	148	84	56.7568%	YUL-PRO-INTERNET-RASNOV-AS
138915	AE	124	80	64.5161%	KAPOKU Cloud
211137	CZ	74	72	97.2973%	ISPSERVICES
206438	CZ	182	60	32.9670%	MXNET-AS
60533	SK	136	40	29.4118%	SATELIX
49107	RU	34	34	100.0000%	TELKO-AS
207913	RO	32	32	100.0000%	CLAR-TELEVISON-SRL
205400	CZ	186	32	17.2043%	VIVOCONNECTION
57180	RO	32	30	93.7500%	STAR-NET-ALBA-AS
203574	RO	28	28	100.0000%	CONECTX-AS
210713	RO	26	26	100.0000%	CORESI-NETLINK
35512	RO	26	26	100.0000%	TELEMEDIA-AS
6856	RU	24	24	100.0000%	IC-VORONEZH-AS
61403	RU	24	24	100.0000%	SEVER-TELECOM-CHER
138915	US	154	20	12.9870%	KAOPU CLOUD
60840	RU	20	20	100.0000%	TELECOMSERVICEVRN
57411	RU	16	16	100.0000%	NOVOTEHNIKS-AS
47165	RU	14	14	100.0000%	OMKC-AS
62642	US	312	14	4.4872%	BIGLEAF
210616	RU	30	12	40.0000%	SIBMEDVED-AS
5384	AE	17,218	12	0.0697%	EMIRATES-INTERNET
51102	RO	12	10	83.3333%	IMPATT-AS
41087	RO	10	10	100.0000%	ROMPRIX-AS
47236	RU	24	6	25.0000%	CITYLINK-AS
56791	RU	6	6	100.0000%	CT-AS
138915	BH	4	4	100.0000%	KAOPU
13150	CZ	6	4	66.6667%	CATON
5416	BH	9,642	4	0.0415%	Internet Service Provider
49055	RU	2	2	100.0000%	NEWIT-AS
38949	SK	6	2	33.3333%	TRESTEL
57294	CZ	204	2	0.9804%	INTERNET_EXPER
41719	RU	2	2	100.0000%	SKTVSPEKTR-AS
60042	RU	2	2	100.0000%	ONTELECOM-AS
13150	GR	2	2	100.0000%	CATON

Table 2 – 240/4 Accessibility by Network

The first serven networks in Table 2 appear to have accepted the route to 242.242.0.0/16 into their network, and also 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 AS 48161 and AS 28725 the lower 240/4 hit rate of some 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 the use of web proxy agents in the client-side network, as the IP address used to access this server are 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 very limited propagation of the route 242.242.0.0/16 indicates that there is widespread practice of route filtering. 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 (CGN) 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, some 26 years later the approach still makes some sense to me. Such a use allows a network operator to use these addresses in a controlled environment where the operator can assure themselves that the addresses are fully functional in their desired limited context of use. But 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!

Disclaimer

The above views do not necessarily represent the views of the Asia Pacific Network Information Centre.

About the Author

 
 
GEOFF HUSTON AM B.Sc., M.Sc., is the Chief Scientist at APNIC, the Regional Internet Registry serving the Asia Pacific region.

www.potaroo.net