The ISP Column A column on things Internet September 2024 Geoff Huston Looking for 240/4 Addresses 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. As a quick illustration of the issues in network reachability , lets compare two traceroutes from a Akamai Linode server located in Frankfurt, Germany. The first is to a conventional IPv4 host address: $ 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 * * * The first three hops appear to pass through the Linode infrastructure, which uses network 10 to number its internal routers. The packets then pass out through a Linode egress router to the Frankfurt DE-CIX switching infrastructure, and is next seen at Quantcom's ingress, and from there into a Quantcom router in Prague. $ 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 * * * The difference here is in hop 5, where the outbound packet is passed into the Akamai infrastructure rather than to DE-CIX. It is likely that these initial hops are following the internal default route. As it appears that Linode is not accepting a route to any prefix in 240/4 from DE-CIX, then the default outbound path points to an Akamai router, which discards the packet as there is no explicit route and no further default routes to follow. 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 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 (https://stat.ripe.net/ui2013/AS29208#tabId=at-a-glance), 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 seven 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 or positions of the Asia Pacific Network Information Centre. Author Geoff Huston AM, M.Sc., is the Chief Scientist at APNIC, the Regional Internet Registry serving the Asia Pacific region. www.potaroo.net