At the APRICOT 2022 APOPS session earlier this year, I had the chance to present on the IPv4 Unicast Extensions Project.
This project responds to the continued acute scarcity of IPv4 addresses by proposing changes that would free up hundreds of millions of addresses, or about 6 to 7% of the IPv4 address space.
Several decisions made during the 1980s, in the infancy of IPv4, resulted in making these addresses ‘special’ and unavailable for ordinary addressing purposes. Even though the reasons behind those decisions have not been borne out over the past decades, the addresses have, perhaps surprisingly, continued to be treated specially. That has resulted in a substantial amount of numbering resources going to waste.
One way of thinking about address space is to look at the bit patterns within the 32-bit IPv4 address corresponding to different address categories (Figure 1).
As shown in Figure 1, the IPv4 address categories the project is seeking to unreserve are:
- The lowest address in each IPv4 subnet
- 240/4, except 255.255.255.255
- 0/8, except 0.0.0.0
- 127/8, except 127/16
Our proposals, reflected in four Internet-Drafts, call for defining these kinds of addresses as ordinary unicast addresses, so they would no longer be regarded as reserved, invalid, or loopback address space. Each of these kinds of addresses was reserved for a different reason, and changing each one presents different challenges and opportunities.
Challenges and opportunities
The lowest-address fix removes the historical duplicate broadcast address within each local network segment. This change has the most backward compatibility since it requires software changes only within one’s local network. The resulting address is already usable by distant hosts (outside the local network), with no other software changes required, since existing Internet standards only give the lowest address a special meaning within a subnet, not outside it. Therefore, whoever can reach the hosts in the EC2 reachability test can also reach the .0 (or other lowest-numbered) host on any other network.
The benefits of this change are extremely broad (freeing up exactly one extra address per IPv4 subnet, Internet-wide, for any subnet larger than a /31). The lowest-address fix also has no addressing policy implementations, simply allowing organizations to take a small step to unilaterally increase the efficiency of their use of their existing IPv4 allocations.
The other changes require software changes in IPv4 implementations, although many of these changes are widespread already (with 240/4 support, in particular, already present in the majority of hosts on the Internet). We have also worked with Linux and FreeBSD to adopt the lowest-address fix; OpenBSD did so years ago.
We are continuing to encourage implementers to make the required changes, and developing software patches to support them. These addresses will gradually become more useful as more implementations accept them as valid address space.
We’ve learned that several companies are already making, or considering, fairly extensive unofficial use of 240/4 as private address space because enough devices already permit it. The use of 240/4, 0/8, and 127/8 as routeable address space for public or private purposes does pose policy questions (for instance, whether, when, and how each range could be used officially as either private or public address space), to which we have not proposed answers. Instead, we’re trying to maximize compatibility with these addresses to give the Internet community the best possible options for their use years from now.
While we hope that compatibility will eventually be sufficient for these addresses to be used on the public Internet, we also recognize that using them as official or unofficial private address space will provide value for network operators.
Will this undermine the adoption of IPv6?
Some people have been sceptical about our proposals because of the large installed base of systems that are in some way hard-coded to reject these addresses as invalid. Others fear that our proposals compete with or threaten to undermine the adoption of IPv6. To the former group, we suggest nonetheless setting the process in motion as quickly as possible to maximize the long-term potential value of these addresses. To the latter, we have insisted that this is a false dilemma; no efforts to improve the supply of IPv4 address space need be interpreted as an attack on IPv6, or as a reason for any organization to refrain from implementing IPv6. And the initial steps we advocate are small software changes within implementations that generally already have excellent IPv6 support.
Even organizations that have extensively adopted IPv6 typically continue to have demand for IPv4 space for many reasons. We think this will be true for a long time, and so we are aiming to set a process in motion that can be useful in the future, supposing that IPv4 addressing demand continues. We also aim to work with the Internet measurement community to find out more about compatibility with historically reserved address ranges in the field.
Thanks to APRICOT and APNIC for the opportunity to share our ideas and efforts. We invite interested readers to view the APOPS session recording below or read our Internet-Drafts, linked above, for more details and we look forward to continuing to hear from the community.
Seth Schoen is a consultant based in San Francisco. He was previously a Senior Staff Technologist at the Electronic Frontier Foundation and helped found the Let’s Encrypt certificate authority.
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.
In most complex environments this is not going to work.
https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-address-space/
Hi Enno,
Thanks for your comment. I agree with with your concrete prediction that most reserved addresses could not be made universally usable within “24–48 months” (indeed, you made that prediction more than 48 months ago now, so it has already come true!).
Nonetheless, they are also more usable now than they were 48 months ago. We are viewing this as a gradual and long-term process.
The most challenging case is those devices that don’t receive software updates at all. Such devices are challenging for the Internet in many ways; for example, I’ve been working with the Let’s Encrypt CA and remember how complicated it was when the DST X3 root certificate expired last year, since usually most devices receive trusted root certificates along with OS or other software updates. As a result, older client devices that haven’t been updated can also have interoperability problems with TLS servers. There are a number of ways in which devices that don’t get updates will pose compatibility challenges in the future, so a higher-level question to think about is how and to what extent we can minimize the number of such devices in the long term.
To quote the meme ‘Leave IP4 space alooooone ’.
A more modern version might be ‘Get my IPv4 space out your GODAMN MOUTH’
This is not a necessary change.
‘It ain’t broke, don’t “fix” it’.
This may not be an attack on the transition to IPv6 in the direct sense but the true opportunity cost may be hidden.
What effort from clear thinking clever people will be required for this? There is a finite supply. If they are eking out IPv4 and fixing the inevitable bugs they are not implementing IPv6.
There is also a cost to running both IPv4 and IPv6. The quicker we can transit through to IPv6 the better all around.
“240/4, except 255.255.255.255”
Was set aside “For future use”, it was never reserved.
The problem with using it ‘in the future’ (now) is that some operating systems (Microsoft) has forbidden those addresses from being used/processed..
Windows 9x and NT will never be patched, but are still in use, for example, along with 2000, XP, Vista, 7, plus the server versions that will NOT get updated..
So because of Microsoft (and a couple others), the 240.0.0.0/4 space can never be used, even if it was put into service.
You will have a lot easier time convincing the US DoD to return some of their 14 /8s than you will making the 240.0.0.0/4 space usable.
I do not think the lowest address in each subnet is worth doing, as it does not help anyone obtain new IPv4 networks or subnets, and is more error-prone in network management.
I realise that collectively across the Internet allowing the lowest (usually zero) address in a subnet to be used for a host creates a huge number of new addresses. But individually, no organisation that needs an entire new network or subnet can get such from this proposal (unlike the other three). The only actual gain is to an organisation that needs one more host on an existing subnet. That does not strike me as much of a benefit given the potential for new errors.
The convention that zero won’t be used for hosts is slightly inefficient from a pure information coding viewpoint, but it is practical and robust. Setting values to zero when they shouldn’t be, or not setting them so they end up zero, is a very common programming / configuration error. So common that checking for zero is standard defensive programming, and even the human eyeball is pretty good at detecting such errors. I do not think the benefit of one extra address per subnet outweighs the likely extra errors.