arXiv:1411.2649v3 [cs.NI] 27 Feb 2015
a
X
iv
:1
41
1.
26
49
v3
[
cs
.N
I]
2
7
Fe
20
15
A Primer on IPv4 Scarcity
Philipp Richte
TU Berlin / ICSI
XXXXXXXXXX
Mark Allman
ICSI
XXXXXXXXXX
Randy Bush
Internet Initiative Japan
XXXXXXXXXX
Vern Paxson
UC Berkeley / ICSI
XXXXXXXXXX
This article is an editorial note submitted to CCR. It has NOT been peer reviewed.
The authors take full responsibility for this article’s technical content. Comments can be posted through CCR Online.
ABSTRACT
With the ongoing exhaustion of free address pools at the
egistries serving the global demand for IPv4 address space,
scarcity has become reality. Networks in need of address
space can no longer get more address allocations from thei
espective registries.
In this work we frame the fundamentals of the IPv4 ad-
dress exhaustion phenomena and connected issues. We elab-
orate on how the cu
ent ecosystem of IPv4 address space
has evolved since the standardization of IPv4, leading to
the rather complex and opaque scenario we face today. We
outline the evolution in address space management as well
as address space use patterns, identifying key factors of the
scarcity issues. We characterize the possible solution space
to overcome these issues and open the perspective of address
locks as virtual resources, which involves issues such as dif-
ferentiation between address blocks, the need for resource
certification, and issues arising when transfe
ing address
space between networks.
Categories and Subject Descriptors
C.2.3 [Computer-Communication Networks]: Network
Operations—Network Management ; C.2.2 [Computer-
Communication Networks]: Network Protocols—Proto-
col architecture (OSI model)
Keywords
IPv4 address exhaustion; IPv6 transition.
1. INTRODUCTION
The Internet’s design philosophy has facilitated enormous,
apid, and de-centralized growth, from a specialized research
facility to a massive network of global importance. In turn,
the tremendous growth enabled by the original design also
outpaced engineers, researchers, and policy makers. This is
clear in the numerous technical challenges that have arisen—
from the lack of support for traffic engineering and routing
security, to the scalability issues of the initial mapping of
hostnames to IP addresses, to the lack of congestion control,
to the inability to accommodate mobility.
The community has largely been able to address such is-
sues, albeit not always in the most elegant way given that
changing a running system presents a challenging target in
many cases. However, under the surface, policy and gover-
nance issues arose. While scientists and engineers often ig-
nore these issues, they ultimately shape what we can deploy
in production. In this paper we consider the entanglement
of policies and governance with the technology for one of the
Internet’s key resources: IP addresses.
Transmission of data between hosts across the Internet re-
quires network layer addresses to name the endpoints—i.e.,
IP addresses. In IP version 4, an address is represented by
32 bits in the IPv4 header; hence there is a finite pool of
oughly 4B addresses available. The network routing sys-
tem cannot keep enough state to deal with each individ-
ual address and therefore aggregates addresses into blocks.
Originally blocks were allocated quite informally, but as the
Internet grew the complexity of the process did as well. At
this point the address space is nearly entirely allocated.
The Internet engineering community has long recognized
the impending exhaustion of IPv4, and in response designed
a replacement network-layer protocol with much longer ad-
dresses, IPv6. However, given the network layer’s critical
functionality, deploying IPv6 has proven difficult.1 There-
fore, it is now widely acknowledged that IPv4 will continue
to play a significant role for a long time within the confines
of the cu
ent resource limits. While there are technical ma-
neuvers we can still make to cope—e.g., adding layers of net-
work address translation (NATting)—IPv4 address blocks
have already become a good that people exchange on sec-
ondary markets. This reality
ings yet another challenge
to the Internet’s policy and governance ecosystem.
In this paper we first survey the evolution of the com-
munity’s management of IP addresses, for which we include
oth a discussion of the relevant policy structures and orga-
nizations, as well as empirical illustrations of the allocation
and use of IP addresses over time. This history then leads
to a set of observations about protocol design and the ac-
companying stewardship of community resources.
2. EVOLUTION OF ADDRESS MANAGE-
MENT
From its standardization in 1981 [69] until now, the man-
agement of IP addresses has undergone drastic change. The
changes were mainly a result of the evolution of the Inter-
net from a research network to a global commercial net-
work and the co
esponding need to establish international
frameworks to manage its critical resources. We elaborate
on this evolution in three time phases: The Early Registra-
tion Phase starting with the a
ival of IPv4, the Needs-based
Provision Phase leading to the modern registry framework,
and the recently entered Depletion and Exhaustion Phase.
1See [32] for an understanding of IPv6 deployment from mul-
tiple viewpoints.
1
http:
arxiv.org/abs/1411.2649v3
IPv4
Standard
1
9
8
1
RIR
Framework
Initiation
First RIR (RIPE)
founded
1
9
9
2
APNIC
exhausted
2
0
1
1
RIPE
exhausted
2
0
1
2
ARIN
exhaustion
projection
2
0
1
5
Early Registration Needs-Based Provision Depletion & Exhaustion
2
0
0
5
Last RIR
(AFRINIC)
founded
Figure 1: Evolution of address management.
2.1 First Phase: Early Registration.
Initially, address blocks were allocated quite informally,
with Jon Postel serving as the “czar” personally attending to
each allocation. Postel periodically re-published RFCs enu-
merating the cu
ent address assignments (“please contact
Jon to receive a number assignment”) [68]. At that time, ad-
dresses block allocations came in one of three classes: class
A networks (224 addresses), class B (216), and class C (28).
Classful addressing required a network identifier of one of
these distinct types, meaning that an operator requesting
significantly more addresses than provided by a particula
threshold would instead be allocated a larger class network.
Given the coarse-grained nature of the differences between
these classes, this policy led to heavy internal fragmentation
and thus waste of address space.
Early XXXXXXXXXXin the Internet’s evolution, parties had al-
eady registered 43 class A networks, allocating in total more
than 700M addresses [68]—vastly larger than the number of
hosts actually connected at that time.2 While scarcity in
address blocks was not mentioned as a looming issue, the no-
tion of different sizes of networks (A, B and C) suggests early
ecognition of the finite nature of network address blocks and
the need for some sort of stewardship when parceling them
out to different parties. The responsibility for the manage-
ment of address space led to formalizing the notion of the
IANA (first mentioned in IETF documents in 1990 [72]),
and, in the same timeframe Solensky, drawing upon alloca-
tion statistics, predicted IPv4 address exhaustion in the late
’90s [86].
2.2 Second Phase: Needs-based Provision.
The need for a more distributed and parsimonious frame-
work to allocate IP addresses—shaping the modern registry
structure—appeared at least as early as 1990 [31], with fur-
ther refinements in 1992 and 1993 [41]. The discussion at
that time included the need to distribute the administra-
tion of IP address blocks to regional registries, covering dis-
tinct geographic regions to better serve the respective local
community—consciously fragmenting the registry. In ad-
dition, classless inter-domain routing (CIDR)3 and private
2Address registration statistics in terms of number of blocks
and block holders varied heavily among the first published
RFCs.
3CIDR [39] supported routing and forwarding on bit-
aligned, as opposed to the previous byte-aligned, variable-
length prefixes. CIDR denotes prefixes as a combination of
an IP address and a co
esponding network mask, such as
1.1.2.0/23 specifying a network with 29 IP addresses that
share their top 23 bits. Introducing CIDR required signif-
icant network restructuring efforts, as well as changes to
outing protocols and hardware (see, for example, [38]).
IANA
ARIN
LIR
end-use
LACNIC
LIR
end-use
AFRINIC
LIR
end-use
RIPE
LIR
end-use
APNIC
LIR
end-use
address space allocation
address space assignment
Figure 2: Regional Internet Registry system.
address space4 arose in 1993–4 to further conserve publicly
outable address space.
The modern framework of Regional Internet Registries
(RIRs), established in the years between 1992 and 2005,
was very specific that conservation of address space was a
primary goal [43]. Five RIRs emerged, run as non-profit
organizations: RIPE for Europe in 1992, APNIC for the
Asia-Pacific in 1993, ARIN for the North-Americans in 1997,
LACNIC for Latin America in 2002, and AfriNIC for Africa
in 2005.
The RIRs manage the distribution of IP address resources,
each according to their local policies. Policies within the
RIRs are created using a community process; for details of
the process for each RIR, see [5, 9, 13, 53, 77]. For the most
part, anyone can submit an RIR policy proposal which then
undergoes an open discussion and review process, usually
ca
ied out on mailing lists as well as in working group and
policy meetings. Adopting a proposal requires the commu-
nity to reach a degree of consensus as reflected in these dis-
cussions.
We sketch the structure of the RIR framework in Fig-
ure 2. The IANA serves as the parent organization, allocat-
ing large free address blocks (/8, i.e. 224 addresses, granu-
larity) to an RIR once their regional free pool reaches a low
threshold level. The RIRs then further allocate subsets of
these address blocks to their members, the so-called LIRs
(Local Internet Registries), which are mainly ISPs. The
LIRs then assign address blocks to either smaller ISPs o
for their own infrastructure. Thus, the allocation of a block
eserves it for (future) use, while the assignment of parts
of an allocation puts that subset into use.5 ISPs decide fo
themselves whether to become LIRs—meaning entering a
direct contractual relationship with the respective RIR—o
to rely upon their upstream provider to assign address space
to them.6
4Reserved address blocks not globally routable, and thus
usable concu
ently within multiple networks as long as
the given hosts do not require globally reachable IP ad-
dresses [71].
5The APNIC and LACNIC regions also have National Inter-
net Registries (NIRs), which act as intermediaries between
the RIR and the LIR to serve specific countries. For exam-
ple, JPNIC does so for Japan.
6Under some circumstances, RIRs can also assign address
space directly to end users—so-called provider independent
(PI) address space. Such assignments usually arise due to
the user’s need to connect to multiple upstream providers
(multi-homing), and thus requiring independent address
space. For more details, see for example § 4.2 in the ARIN
NRPM [14] or the RIPE policy documents [83]. For a prac-
tical guide for operators, see [27].
2
During the needs-based provision phase, one of the key
principles was that receivers of address space (LIRs) must
justify their need for the address blocks they receive,