Reduce IP Address Fragmentation through Allocation
Mei Wang Larry Dunn Wei Mao Tao Chen
Cisco Systems, Inc. China Internet Network Information Center
{mei, ldunn}@cisco.com
Abstract— The scalability of Internet addressing and routing
has been a serious issue and becomes a more urgent problem
today because of driving factors like IPv6. A radical impacting
element of the scalability is address allocation, as it directly
affects routing table structure, hence, IP lookup and routing
efficiency.
A key problem in IPv4 today is address fragmentation, i.e.,
one entity is represented by multiple non-contiguous IP address
blocks in the routing table. Address fragmentation increases
routing table size, therefore degrades scalability. Existing address
allocation practices are a major contributor to address fragmen-
tation.
In this paper, we demonstrate that the performance of ad-
dress allocation can be dramatically improved. We propose a
new address allocation algorithm called GAP: Growth-based
Address Partitioning. Through real data, we show that GAP
can reduce fragmentation by 90% compared to the existing
allocation schemes. This is significant for reducing routing table
size, increasing scalability, and improving the performance of the
Internet. We also introduce a software tool being developed for
address allocation.
I. I NTRODUCTION
The Internet routing and addressing scalability is becoming
an urgent issue [1]. The fast increasing number of users, multi-
homing, IPv6 [3], traffic engineering, and policy routing are
all posing more challenges to the scalability of the Internet.
IP address fragmentation is a critical factor that impacts
addressing and routing scalability, it is also a key problem
in IPv4 today. Address fragmentation is the phenomenon
in which a single entity on the network has multiple non-
contiguous IP address blocks or prefixes instead of a single
prefix in the routing table. Address fragmentation increases
routing table size, therefore degrades scalability as well as
IP address lookup and routing performance in routers. The
opposite of fragmentation is aggregation, combining separated
prefixes into one.
One major contributor to address fragmentation is a poor ad-
dress allocation policy. This is because addresses are allocated
to an entity on an as-needed basis. A customer would often file
multiple separate requests for addresses over time as it grows.
Thus, the address assignments to the same customer might end
up being non-contiguous. Avoiding, or minimizing, address
space fragmentation is a major goal of address allocation.
Little work has been done in the area of address allocation
since the massive allocation of IPv4 addresses years ago. As
IPv6 is taking off, its larger address space (due to 128-bit
addresses) can aggravate the problem. Thus, now is a life time
opportunity to do it right from the beginning for IPv6, learning
1-4244-1251-X/07/$25.00 ©2007 IEEE.
{mao, chentao}@cnnic.cn
the lessons from IPv4, study and design address allocation
schemes that induce minimum fragmentation,
In this paper, we propose a scheme called GAP: Growth-
based Address Partitioning. GAP takes the growth rate of
each customer into account and partitions the address space
accordingly to provide the maximum space for each customer.
We use the real world data to demonstrate that, compared
to the current allocation methods, GAP significantly reduces
address fragmentation and improves the efficiency of address
usage.
We are also developing a software package for further
studies and experiments in address allocation. This software
can take dynamic requests and simulate real allocations. The
graphics in this software enables the visualization of address
allocations. It provides a platform for analysis of different
allocation algorithms and policies.
These studies and results would be instrumental in providing
technical guidelines for setting the right policies and standards
for IPv6 address allocation at all levels across the world.
The rest of this paper is organized as follows: Section II lays
out the background for how addresses are allocated nowadays.
Section III introduces GAP scheme. Section IV presents the
result comparisons using real data. Section V describes the
software package for address allocation. Section VI shares
some discussions and future directions.
II. H OW ARE ADDRESSES ALLOCATED
The hierarchical IP address allocation structure is depicted
in Figure 1. The size of the address blocks decreases with
each increasing level of the hierarchy. The addresses at the
top of the hierarchy are controlled by the Internet Assigned
Numbers Authority (IANA). IANA allocates large address
blocks to each of the five Regional Internet Registries (RIRs)
serving North America (ARIN), Europe (RIPE), Asia Pa-
cific (APNIC), Africa (AfriNIC), and Latin America and
the Caribbean (LACNIC). The regional registries divide up
these large address blocks into medium blocks to allocate to
Local Internet Registries (LIRs), consisting mainly of Internet
Service Providers (ISPs). The ISPs further assign small address
blocks to their customers, including smaller ISPs, companies,
universities, etc.
An address allocation consists of three technical elements:
1) the size of the allocation; 2) the location of the allocation in
the address space pool; 3) the requirements a customer needs
to meet before requesting further expansion. An allocation
standard at each layer should address these three aspects.
371
 Fig. 1. The hierarchy of IP address allocation and the policies on
allocation sizes at different layers.
At present, documents on allocation mainly specify the size
of prefixes and the criteria for allocation expansion. Few
specific procedures exist on how the address space should be
partitioned, which is the focus of this work, as it is important
to the network structure. For the rest of this paper, we will
refer standards on allocation sizes as “allocation policies”, as
sizes are the main specifications in the current policies; we will
use “allocation algorithms” to denote address space partitions,
i.e., where the addresses are allocated. We will introduce the
current practices in these two areas separately in the following
two subsections.
A. Existing allocation policies
Allocation policies vary for different registries at different
layers of the hierarchy. Allocation policies on initial allocation
size at different levels are shown in Figure 1. For example, in
the current IPv4 policies [13]–[15], IANA allocates to RIRs
in the unit of /8. Different RIRs adopt their own policies for
allocations to LIR/ISPs with unit sizes varying from /10 to
/20. The sizes assigned to end users by each ISP also vary
greatly. Due to historical allocation schemes, fragmentation is
a common problem in IPv4 [8]: one ISP is often left with
multiple prefixes.
For IPv6, although there are 128 bits in the IP address, the
last 64 bits are assigned to interface ID [4], e.g., an ethernets
MAC address. Thus, address allocation only considers the
top 64 bits. Allocation policies [17] in terms of size are
shown in Figure 1. There is a proposal [19] from major RIRs
recommending a Common Address Pool (CAP) in IANA for
all RIRs, instead of each RIR keeping a separate pool of
addresses for allocation.
B. Existing allocation algorithms
A good allocation algorithm can be applied to any layer in
the allocation hierarchy and any registry. It can be combined
with the allocation policy to provide efficient usage of address
space and preserve address aggregation.
There are two address allocation schemes that are currently
deployed in the real world: the sequential scheme and the
bisection scheme.
1) Sequential scheme: Using sequential scheme, each new
request is allocated into the first empty space available from
left to right on the address line that fits the requested size. Due
1-4244-1251-X/07/$25.00 ©2007 IEEE.
Fig. 2. Bisection scheme.
to its simplicity, sequential scheme is commonly deployed in
the real world practice. It is a good scheme if the requested
sizes are static, i.e., there is no growth of each customer, the
total required size for each customer is fixed at the beginning
of the allocation. This is obviously not the case in reality.
Each entity often requests a relatively small address block at
the beginning, then comes back for more as it grows, as we
will see in real allocation request patterns in section IV.
2) Bisection scheme: Bisection scheme is proposed for
IPv6 address allocation practice by regional registries [19].
Address blocks are allocated in the following way: each new
address block is allocated by evenly splitting the maximum
available space on the address line between the existing cus-
tomer and the new customer. This leaves maximum possible
space for potential growth of both customers.
To illustrate this scheme, an example is demonstrated in
Figure 2. Each customer is given an ID labeling the incoming
sequence of the customers. The first four customers are allo-
cated by dividing the total address space equally into four parts
as shown in Figure 2(a). When the fifth customer applies for
an address block, it is placed to evenly split the section labeled
by the arrow in Figure 2(b). The 6th, 7th, and 8th customer
will be placed sequentially in the spaces after the 3rd, 2nd,
and 4th customer, respectively. Only after the largest empty
slots have been exhausted, will new allocations be assigned to
bisect the smaller slots at the next level. A similar technique
can be found for dynamic memory allocation in Operating
Systems.
Bisection scheme treats each customer equally, it uniformly
separates the allocated blocks to maximize the spacing be-
tween customers. Regardless whether a customer is big or
small, as far as it comes in as the 5th customer in the address
requesting sequence, this customer is always allocated into the
space as shown in Figure 2(b). In reality, different customers
are likely to require different sizes in the address space and
have different growth rates. Thus this uniform partition may
not be the most efficient way to utilize the address space
and give each customer adequate amount of space to grow,
especially when there are a few very fast-growing customers.
These fast-growers can run out of space for further expansion,
due to their occupying neighbors, this phenomenon is called
collision. When collision occurs, the provider can either find
a separate location on the address line or still expand the
customer’s space by carving out the section already occupied
by its neighbor. Both options lead to fragmentation: non-
372
 continuous address blocks for one entity, i.e., more than one
prefix representing a single entity in the routing table. Such
practice should be avoided whenever it is possible. A third
option is to move either one of the two customers to a different
address location, which will create much hassle and may not
always be viable.

III. GAP: G ROWTH - BASED A DDRESS PARTITIONING Fig. 3. GAP scheme.

To reduce collisions and utilize the address space more

efficiently, we propose Growth-based Address Partitioning
(GAP) scheme to make allocations based on the growth of
each customer. When there are n exiting customers, there are
at most n possible address location candidates for the (n+1)th
customer. Instead of treating each customer equally, as in the
bisection scheme, the GAP scheme evaluates all the options
and chooses the location based on the existing customers’ sizes
and their growth-rates, the available space sizes, as well as the
size and the growth-rate of the new customer. For example, one
can choose the location for the new customer that maximizes
the time before the first collision is projected to take place.
Because the prefix bits are binary, the newly allocated block
has to start at the middle point of the available address space.
Let us assume for now that the growth rate information is Fig. 4. An example of the GAP scheme. The relationship of customers
growth-rates: r2 > r1 > r4 = r5
r3 > r6 .
available. We will further discuss how to obtain the growth-
rate of each customer later. As shown in Figure 3, we define:
n: the number of existing customers;
figure that by the time customer 5 arrives, customer 2 has
n+1: the new customer;
already doubled its space occupation due to its fast growth.
Ai : i=1,...,n,n+1,
The best location for customer 5 would be after 3, according
the allocation for each customer;
to Eq.1, since customer 3 has the slowest growth rate. Note
ri : i=1,...,n,n+1,
that allocation 1 is still far from filling up its potential growth
the growth rate of each customer;
space up to the bisection point. Even so, allocation 5 is not
Xi : i=1,...,n, the empty space available
assigned after allocation 1 because of the fast growth rate of
for the existing customer to grow, i.e.,
1, in contrast to the previous scheme. Figure 4(c) shows that
the empty space behind each allocated block
although the spaces after customers 3 and 5 are smaller than
to bisection point;
those after 1, 2, and 4, all five spaces are treated as candidates
Yi : i=1,...,n, the empty space available
for the 6th customer. Customer 6, along with customer 3,
for newly allocated customer to grow;
has an extremely slow growth rate compared to other existing
The new location is chosen to maximize the time before customers. Based on Eq.1, customer 6 is placed in the small
anybody runs out of space to grow, i.e., the first collision empty space after customer 3. This leaves the fast growers
occurs, using: more space for potential expansion and also saves the larger
blocks for future customers that may need more space.
max{min[t(Xi , Ai , ri ), t(Yi , An+1 , rn+1 )], i = 1, ..., n}.
(1) In order for two address blocks to be aggregated into one
t(X, A, r) is the time it takes for an allocation with size A and prefix, not only do these two address blocks have to be adja-
growth rate r to fill up the space X. In other words, the new cent to each other, but also the aggregated address space size
location is chosen among all available spaces that maximizes has to be an integer power of two. This is because IP addresses
the time it takes for either the existing or the new customer to represent binary address blocks. This constraint limits the ways
run into the boundary. Function t(X, A, r) can be of different one can allocate IP addresses to optimally utilize address space
forms depending on the definition of growth rate r. while maximizing aggregations. For example, in Figure 4(b),
This scheme is further illustrated by an example in Figure all possible choices for a new customer 5 are indicated by
4. For a given address space, we consider allocations for the arrows. Any other choice will not lead to better address
six customers. Assume the order of their growth rates to be: aggregation for the future growth of these five customers.
r2 > r1 > r4 = r5
r3 > r6 , where the indices label the Extensive theoretical analysis and simulations [2] have
incoming sequence of the customers. The address locations demonstrated that GAP outperforms the existing allocation
for the first four customers are shown in Figure 4(a). The schemes. How well will this algorithm work in real world
5th customer can choose among the four bisection points settings? Next section will focus on the results using real
indicated by the arrows in Figure 4(b). We can see from the allocation data.

1-4244-1251-X/07/$25.00 ©2007 IEEE. 373

 Comparison using APNIC allocation data
IV. E VALUATIONS WITH R EAL DATA
160

An efficient address allocation scheme can benefit both IPv4 140

and IPv6. However, as IPv4 space is already getting very Existing APNIC allocation
120 New algorithm (GAP)
saturated, how well will a scheme work for the imminent IPv6

Number of fragmentations
allocations demands the focus of the design. The best way to 100

test it is applying the scheme to real data. However, there are 80

very few real IPv6 data available nowadays, while we have a 60

long history of IPv4 allocations. What if we had adopted this 40

proposed allocation algorithm for IPv4 say, six months, one
20
year, or even ten years ago? How would the results compare
with that of the existing allocation? These result comparisons 0
6/2006 7/2006 8/2006 9/2006 10/2006 11/2006 12/2006
Allocation date
can be an objective judgement on how good of an allocation
algorithm is. Fig. 5. With real allocation data from APNIC, the number of fragmentation
Following this thought, we conducted experiments using is significantly reduced using GAP compared to the existing allocation.
data from existing IPv4 allocations from a regional registry
and a country registry. These data are the historical address Comparison using CNNIC allocation data
requesting sequences from various customers. They are fed 140

into the GAP engine in the identical order as they were ac-
120
tually requested, without any knowledge of future allocations. Existing CNNIC allocation
New algorithm (GAP)
This makes it an apple-to-apple comparison with the existing 100

Number of fragmentations
allocations. 80
Without any additional information, GAP estimates the
growth rate of each customer based its requesting history 60

data. According to these growth projections, GAP allocates 40

the address blocks to prolong the time to collision.

20

0
6/2000 12/2000 6/2001 12/2001 6/2002 12/2002 6/2003 12/2003 6/2004 12/2004
A. Data from Asia Pacific Region Allocation date

The real allocation data for Asia Pacific region are from
Asia Pacific Network Information Center (APNIC). Being one
of the five Regional Internet Registries in the world, APNIC
is in charge of the address allocation and management in Asia
Pacific region.
The data from APNIC span from July 1, 1985 to December
27, 2006. The address blocks are allocated to a region or
a large ISP directly. We processed the data based on each
country or region as an entity. Each entity has a unique ID.
There are 52 entities total in this set of data. To show an
example, a block of the address 122/7 is used in the experiment
shown here. Thus, the total address space in this block is 225 .
The assignments in this block are very recent: from May 2006
to December 2006. There are 21 entities assigned to this block.
The largest number of requests from a single entity during
this period of time is 39. Among these 21 entities, 6 of them
requested for address blocks only once. The majority of the
entities (16 out of 21) requested less than 10 times. As 80/20
rule indicates, the major part of the address space is assigned
to few entities.
The comparison results in terms of the number of fragmen-
tation are shown in Figure 5. Using the same set of APNIC
data, GAP reduces the number of fragmentation from 150 to
16 compared to the current allocations, a 90% reduction of
fragmentation.
B. Data from China
The real allocation data for China are from China Internet
Network Information Center (CNNIC). CNNIC is a country
Fig. 6. With real allocation data from CNNIC, the number of fragmentation
is significantly reduced using GAP compared to the existing allocation.
registry, in charge of IP address allocation and management
in China. The same methodology is used for this set of data
as for APNIC data. The comparison results in Figure 6 show
the number of fragmentation is reduced from 124 to 30 using
GAP.
In both experiments with APNIC and CNNIC data, the
online allocations using GAP fulfilled the same address allo-
cation requests with a much higher degree of aggregation. All
the results we experimented consistently demonstrate similar
degree of improvement in reducing fragmentation using GAP.
These experiments are conducted based on the constraint
that only one block of addresses, i.e., a small fraction of the
entire address space, is available as the total address pool
for allocation, which has limited room to enable the full
advantages of GAP. Also the time span we look at is relatively
short. If larger total address space and longer time duration are
given, the gain of using GAP can be even more substantial,
as more time and space give the algorithm additional buffer
to better arrange the addresses. This is why it is critical to
do the address allocation right for IPv6 from the beginning.
Further more, these results are achieved without any addi-
tional information taken from customers. All the growth rate
information is derived empirically from the historical data.
If projected growths are provided by individual organization
when it requests addresses, even larger enhancements can be

1-4244-1251-X/07/$25.00 ©2007 IEEE. 374

 accomplished.
V. S OFTWARE FOR ADDRESS ALLOCATION
We are developing a software tool to provide a platform for
address allocation analysis and a visualization for allocation
results. Currently, this software is working for demonstrations
and research studies, we are working to make it a production
quality software that can be deployed in real allocations and
available to broader audience.
Simulating real allocation process, this software takes ad-
dress requests in terms of address block sizes from users with
IDs. Then the optimum allocation space for a specific request
is calculated based on the allocation algorithm (GAP currently)
implemented in this software, according to all the existing
customers and previous allocations in the database. The new
allocation is displayed graphically in the total address space.
Figure 7 shows an example. The x-axis is the IP address space,
the y-axis is time, indicating the year an allocation is made.
Each customer’s allocation is represented by a horizontal bar
in different color, the position of the bar in the figure shows
the allocation time and the location in the address space. The
length of the bar indicates the size of the allocation. Viewing
the new allocation, in relations with other assignments, the
customer has options to take this assignment or choose a
different one. The software also provides the capability for
customers to manually choose a block themselves. Once the
assignment is confirmed, the new information is stored in
the database and displayed permanently in the figure. The
space immediately above x-axis in Figure 7 shows the overall
address space occupancy up to date.
There are two main parts of the software: the front end takes
the request input dynamically and displays the latest address
space occupancy graphically; the back end is the address
allocation algorithm engine that calculates the online optimum
assignment. There is a database where the allocation requests
and assignments are stored. Both front engine and back engine
refer to the database for inputs and results.
A good visualization software can be very instrumental to
address allocation at all levels. Being able to visualize the
allocations makes it easier for both the customers and address
providers. Customers can view what they are offered more
intuitively. It is more efficient for the registries or ISPs who
are assigning the addresses to manage the whole address pool
using this software.
How to effectively display the address space and the alloca-
tions was a challenge. Due to the characteristics of the address
prefixes, address blocks connected together are not necessarily
able to be aggregated into one prefix. The aggregation has to
be intelligently shown based on both the continuity of the
prefixes and their locations in the address space. Also, how
to demonstrate a large address space with many assignments
is not an easy task either. In addition to these difficulties, we
have also tried to tackle the issues for comparing different
algorithms visually.
This software provides a platform to systematically analyze
and compare the correctness and performance of different
address allocation schemes. Any allocation algorithm can be
1-4244-1251-X/07/$25.00 ©2007 IEEE. 375
implemented and easily plugged in for studies and compar-
isons. Using this software, the results from different algorithms
can be verified directly.
VI. D ISCUSSIONS AND FUTURE DIRECTION
The benefits of using GAP algorithm is proportional to
the accuracy of growth rate information provided. In the
GAP algorithm described in Section III, we assumed that the
growth-rates are known. Theoretical analysis and simulations
demonstrated huge gains when we possess the growth-rates
[2].
The estimation of the growth can be acquired through
various means. Each address provider (a registry, an ISP,
or a company) can access the information of its customers’
utilization. Address providers can also collect the growth esti-
mations directly from customers while continuously calibrate
these estimations by monitoring customers’ utilization. Price
related incentives can be applied to help collect more accurate
estimations of growth rates from customers.
This scheme still works even when the estimation of the
growth rate is not accurate or even wrong. Because for
each address allocation there is still space left for potential
growth. Since we check each available block’s growth every
time inserting a new comer, the growth rate can be adjusted
frequently and adaptively according to any changes. GAP is
online optimum at each step of allocations. In the experiments
using real data described in Section IV, no estimation of future
growth is provided by customers. The estimated growth of
each customer was derived from its growth history and current
utilization. GAP shows obvious advantages even in this case.
We have been discussing with registries, as well as policy
and standard bodies during this research project. After the
research stage, with all the results, data, and facts, we are
encouraged to officially submit a proposal for standard in
the near future. This will stimulate more studies in deploying
efficient allocation algorithms into real practices. The results
will benefit future network in the long run.
VII. C ONCLUSIONS
We use real IP address allocation data to demonstrate that
GAP, an algorithm based on growth-rate, can dramatically
reduce address fragmentation. This will control routing table
size and increase the scalability of the network. The first
software tool for address allocation is also being developed
and introduced in this work. Both of these results are meant
to lead to more research and standardization in the area of
address allocation.
R EFERENCES
[1] IETF Internet Architecture Board, Routing and Address Workshop, Oc-
tober 2006.
[2] Mei Wang, A growth-based Address Allocation Scheme for IPv6, Net-
working, 2005.
[3] S. Deering, R. Hinden. RFC2460 Internet Protocol, Version 6 (IPv6)
Specification.
[4] R. Hinden, S. Deering. RFC2373 IP Version 6 Addressing Architecture.
[5] R. Hinden, S. Deering. RFC2374 IPv6 Aggregatable global unicast
address format.
 Fig. 7. A snapshot of the software tool with the implementation of GAP algorithm. The software provides a visualization for allocation results and a platform
for address allocation analysis.

[6] Z. Xu, X. Meng, C. J. Wittbrodt, S. Lu, L. Zhang. IPv4 Address

Allocation and the Evolution of the BGP Routing Table. UCLA Computer
Science Department, 2003.
[7] H. Narayan, R. Govindan, G. Varghese. The Impact of Address Allocation
and Routing on the Structure and Implementation of Routing Tables.
SIGCOMM 2003.
[8] T. Bu, L. Gao and D. Towsley. On Characterizing Routing table growth.
Proceedings of Global Internet 2002.
[9] G. Huston. Allocations vs. Anouncements, The ISP Column, May 2004.
[10] K. Hubbard, M. Kosters, D. Conrad, K. Karrenberg, J. Postel. RFC 2050
Internet Registry IP Allocation Guidelines, November 1996.
[11] A. Durand. RFC 3194 The HD Ratio for Address Assignment Efficiency
[12] IPv4 Address Space Report, http://bgp.potaroo.net/ipv4/
[13] M. Kuhne, P. Rendek, S. Wilmot, L. Vegoda. IPv4 Address Allocation
and Assignment Policies for the RIPE NCC Service Region, October
2003.
[14] ARIN. IPv4 Policies. http://www.arin.net/policy/ipv4.html
[15] Policies for IPv4 Address Space Management in Asia Pacific Region,
March 2004.
[16] http://6bone.net/
[17] APNIC, RIPE, ARIN. IPv6 Address Allocation and Assignment Policy,
June 2002.
[18] IAB, IESG. RFC 3177 IAB/IESG Recommendations on IPv6 address
Allocations to Sites, September 2001.
[19] P. Wilson, R. Plzak, A. Pawlik. IPv6 Address Space Management,
October 2002.

1-4244-1251-X/07/$25.00 ©2007 IEEE. 376