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.