<p>We're trying to alleviate the acute shortage of Internet Protocol version 4 (IPv4)
addresses by bringing some unused addresses into use.
</p>
</dd>
<dt><b>How did we get here?</b></dt>
<dd>
<p>
Around 1981, the Internet's original protocol, IPv4, was designed to have up to 2<sup>32</sup>,
or about 4.2 billion, unique addresses. At that time, this number seemed absurdly large;
today, it seems absurdly small.
</p>
<p>
In the original design of the Internet, every device ought to have at least one completely
unique address. That poses a limit of 4.2 billion Internet-connected devices. The real
limit was somewhat less because of inefficient address allocations and hundreds of millions
of reserved addresses (that were not available for use by any device). Since about 1994,
<ahref="https://en.wikipedia.org/wiki/Network_address_translation">multiple devices have been
able to share a single Internet addresses</a>, which increases the limits
to the total number of devices that can connect, but introduces new limitations, especially
on the use of those devices as servers.
</p>
<p>
Depending on how we measure, we ran out of new completely unused IP addresses sometime
between 2012 and 2020. (There are many different milestones that can be taken as marking
the "definitive" moment of exhaustion, so we may never agree on a more specific date.)
The Internet community adopted a plan around 1999
to switch the Internet to a new technology, IPv6, which has 2<sup>128</sup> addresses. This
transition has been slow and uneven; the
adoption of IPv6 is still only about 30% worldwide, much less than originally predicted.
While its adoption is still growing, researchers
<ahref="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3410895">question whether it
will ever completely replace IPv4</a>.
</p>
<p>
There is still a very considerable demand for IPv4 addresses, often though not exclusively
from web hosting and cloud companies. This demand has led to efforts to find and reclaim
IPv4 addresses that were allocated but are not in use. Among many examples, the
Massachusetts Institute of Technology
<ahref="https://gist.github.com/simonster/e22e50cd52b7dffcf5a4db2b8ea4cce0">sold half of its allocation</a>
of 16.7 million IPv4 addresses ("18/8") to Amazon and possibly other hosting companies in
2017, since MIT wasn't using anywhere near this many addresses on its campus networks.
</p>
<p>
While unused or underused previously-allocated IPv4 addresses continue to be found and
resold, we're broadening the search for these addresses by proposing making active use of
other categories of addresses, including long-ago reserved addresses that have never been
used for any purpose.
</p>
</dd>
<dt><b>What are "unicast addresses"? Why do you call the project "IPv4 Unicast Extensions"?</b></dt>
<dd>
<p>
Unicast refers to the most common form of communication on the Internet,
directly between a single device and another single device. Internet software
and standards usually decide whether this form of communication is intended
by examining the IP addresses in a packet. (Other possibilities include
"broadcast", "multicast", and "loopback".) Almost all Internet communication
is unicast because it takes place directly between a client and server, or
between two peer devices.
</p>
<p>
This project is called IPv4 Unicast Extensions because it aims to allow
many IPv4 addresses to be used for unicast communications that previously
couldn't be used this way, because they were <ahref="https://en.wikipedia.org/wiki/IPv4#Special-use_addresses">reserved or allocated for some other use</a>. We will do this
by reducing special cases in Internet standards and software.
</p>
</dd>
<dt><b>Who still needs new IPv4 addresses?</b></dt>
<dd>
<p>
Lots of networks still need IPv4 addresses—the most conspicuous examples are cloud
and hosting providers, which largely need these addresses in order to provide services
to IPv4 clients. IPv4 addresses are a significant portion of the costs of hosting
services. If they intend to serve the general public worldwide, most of these services
cannot hope to go IPv6-only today, as that would cut out accessible to a huge fraction
of their users. (Some hosting providers offer "IPv6-only" hosting with shared IPv4
reverse proxies, where clients connecting over IPv4 connect to the proxy, which then
makes its own IPv6 connection to the server. This works well for some sites, but also has
its own trade-offs related to scalability and encryption.)
</p>
<p>
We can benefit the Internet community by addressing this demand which is limiting
flexibility and raising costs of entry for all kinds of new Internet sites and services.
Making new IPv4 addresses available will, for example, stop the costs of web hosting
from increasing as quickly as they would otherwise. That helps more people and
organizations be able to afford their own web sites or start Internet companies.
</p>
<p>
The active market for resale of IPv4 blocks, the high prices that purchasers have paid,
and the way that purchased blocks were put into productive use all shows the unmet
and growing demand and the value that could be provided by bringing these addresses
into use.
</p>
</dd>
<dt><b>Which addresses are you trying to reclaim?</b></dt>
<dd>
<p>
The addresses we're looking at fall into five categories:</p>
<p>The <b>zero network</b>. This is the network that starts with 0, including addresses
like "0.1.2.3". These addresses have never been allocated to any specific network, and were
historically used to mean "this network" by some host autoconfiguration designs that ended
up never getting used on the Internet.</p>
<p>The <b>loopback network</b>. This is the network that starts with 127, including the
main loopback address 127.0.0.1, and over 16 million <em>other</em> addresses, all of
which currently have the same meaning—"this machine".</p>
<p>The <b>lowest address</b> on each subnet (sometimes also called "zeroth address"). This is the address that <em>ends</em> with zero,
such as 103.224.182.0 (in 103.224.182.0/24). On a subnet smaller than /24, the lowest address doesn't end in ".0", but it still ends with zeroes in the binary representation. For example, the lowest address in 192.168.86.96/28 is 192.168.86.96, whose binary representation <tt>11000000 10101000 01010110 0110<b>0000</b></tt> ends with four zeroes (32-28=4).</p>
<p>
The lowest address is always exactly equal to the subnet's network address; for instance, 93.184.216.32/28's lowest address
is 93.184.216.32, which ends with 0000 in binary. Current standards call for not using this
<b>Why should reserved addresses be turned into global space that gets allocated
and announced publicly, rather than used as additional RFC 1918-style
private address space?</b>
<dd>
<p>Some proposals like <ahref="https://tools.ietf.org/html/draft-wilson-class-e-02">Wilson, Michaelson, and Huston's</a> draft from 2009 have advocated using
reserved space such as 240/4 as private address space, like 192.168/16 from
RFC 1918. There is considerable demand for private address space, and it
has the advantage the changes needed to support it would only need to be
made by organizations that actually want to use it. Some organizations have
also started using various IPv4 blocks (including allocated but
never-publicly-announced blocks like 22/8 and 25/8, and unallocated and
reserved blocks like 240/4) as private address space on an unofficial basis
without standards coordination with the rest of the Internet. These
organizations might like the security of knowing that their practices are
officially approved by the Internet community.
</p>
<p>
However, we think that global unicast is a better and more valuable use of
the remaining reserved address space. In particular, organizations that
control a private network well enough to set addressing policy for it are
especially well-positioned to use IPv6 on that network, since they don't
have to rely on any other networks' behavior to adopt IPv6 internally.
IPv4 addresses, on the other hand, may still be required by networks that
need to achieve interoperability with distant strangers, with whom they can't
coordinate easily. There may be counterexamples to this calculus,
particularly for private addresses meant for large carrier-grade NAT
deployments, but intuitively "we're rolling out a new datacenter/organizational
network and we need more IPv4 space to talk to ourselves" makes less
sense than "we're rolling out a new public service and we need more IPv4
space to let users elsewhere in the world reach us".
</p>
<p>
In any case, we should start with the work necessary to support reserved
address space as globally routable, since this work will also make this
space usable for private allocations, while the converse is not necessarily
true. The technical work is almost all the same, no matter what these
addresses are allocated for. Millions of hosts, routers, and ancillary
equipment like Internet-of-Things devices would need to enable unicast
use of the address, and be able to route them, whether they are being
used and routed inside a data center, inside a company, or in the whole
world.</p>
<p>
This will still preserve the option to subsequently "allocate" some
portion of this space as private if this course of action appears
particularly beneficial. Our Internet-Drafts do not actually perform any
allocation of reserved address space, while our software patches will be
helpful to future users of this space with either global or organizational
scope. Once the reserved address space is successfully unreserved (and
successfully usable at least for up-to-date hosts and routers), we can
have a further discussion of the most valuable allocation method for it.
</p>
<p>
We are motivated by the disconnect between the indifference of the
Internet policy community, versus the prices that ordinary Internet
users and large Internet companies are paying for IPv4 addresses—in
the range of $25 per address and gradually rising. This indicates enormous
demand and potential value that will be created by selling new addresses
publicly, increasing the supply of IPv4 addresses and driving the price
