[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GLOBAL-V6] Analyzing IPv4 and Ipv6 address space with the HD-ratio
I've just published a new Internet Draft
"Analyzing IPv4 and IPv6 address space with the HD-ratio"
draft-durand-hdv4v6-00.txt
This draft looks at current IPv4 address allocation
and at IPv6 allocation using the HD ratio.
There is a section that tries to provide some
information on how much IPv6 address space
an ISP/LIR/entity doing address assignment
needs in order to allocates a number of site prefixes under
a given HD ratio.
I think it may be useful input in the current debate.
As the draft won't appear until a few days in the
database, I sent a copy attached to this mail.
- Alain.
Internet Engineering Task Force Alain Durand
INTERNET-DRAFT SUN Microsystems,inc.
Feb 19, 2002 Christian Huitema
Expires October, 20, 2002 Microsoft
Analyzing IPv4 and Ipv6 address space with the HD-ratio
<draft-durand-hdv4v6-00.txt>
Status of this memo
This memo provides information to the Internet community. It does not
specify an Internet standard of any kind. This memo is in full
conformance with all provisions of Section 10 of RFC2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document analyses current IPv4 allocation and projected IPv6
allocations using the HD-ratio defined in RFC3194.
1. Introduction
As shown in RFC3194, the HD-ratio is a good indicator
of the pail level associated to various addressing plans.
This document analyses current trends in IPv4 allocations
and future Ipv6 allocations.
2. Evolution of the pain level in the IPv4 Internet
The allocation of IPv4 addresses went through several phases that
correspond to growing levels of pains. This included the transfer of
the registry functions from IANA to the Internic in 1991, the
definition of CIDR in 1992 and its practical introduction in 1993,
the generalization of variable length subnets in the same period, the
delegation of address allocation to regional registries between 1992
and 1996, the arrival of NAT around 1996. Logically, we should
observe over the years an evolution of the HD-ratio that reflects
this growing level of pain.
The following table shows the value of the HD-ratio before and after
the allocation of new /8 prefixes to the registries. The date of
allocation and the number of /8 open for allocation is derived from
the INTERNET PROTOCOL V4 ADDRESS SPACE maintained by the IANA
[IANAV4]; the number of /8 includes all the prefixes open for the
allocation of global IPv4 addresses, excluding the 16 domains used
for multicast (224/4), the 16 domains used for experiments (240/4),
the unspecified addresses (0/8), the local addresses (10/8) and the
loop back addresses (127/8). The number of hosts in the Internet is
extrapolated from the Internet Domain Name Surveys [DOMSRV].
HD
Date /8 Hosts ratio
--------------------------------
01/01/94 97 2,217,000 69%
01/01/95 113 4,852,000 72%
01/01/96 123 9,472,000 75%
01/01/97 127 16,146,000 77%
01/01/98 131 29,670,000 80%
01/01/99 132 43,230,000 82%
01/01/00 134 72,398,092 84%
01/01/01 138 109,574,429 86%
01/01/02 145 147,344,723 87%
log(number of hosts)
Note: HD = ------------------------
log(number of /8 x 2^24)
The table lists the number of prefixes and the corresponding HD-ratio
on January 1st each year. We notice that the HD-ratio grows
continuously, which reflects continuous efficiency gains; it is also
clearly the picture of a growing pain level. As of January 2002, we
have already reached a level of 87%.
2. Available capacity with IPv6
Applying the HD-ratio to a 128 bit address space predicts that we
could comfortably number 6.6 E+30 addresses with an HD-ratio of 80%.
This is quite satisfying, but we should conduct a more specific
analysis that takes into account the structure of IPv6 global
addresses. The "first wave" of specifications only define the
structure for the 001 binary /3 prefix. The addresses are composed
in practice of a 64 bit subnet prefix and a 64 bit host identifier;
we expect "sites" to be identified by a 48 bit prefix. As the
network prefix for those global unicast addresses starts by the 3
bits "001", there are in practice 61 bits available to number the
subnets and 45 to number the sites. This leads to the following
numbers:
IPv4 IPv4
pain level pain level
Reasonable Painful 01/01/2001 01/01/2002
HD=80% HD=85% HD=86% HD=87%
-----------------------------------------------------------
Sites (45 bits) 70 B 330 B 450 B 610 B
Subnets (61 bits) 490 T 4 Q 6 Q 10 Q
Note: 1M = 1E6, 1B= 1E9, 1T=1E12, 1Q=1E15
number of object = exp(HD x log(2^ number of bits))
To put those numbers in perspective, according to
http://www.census.gov/ipc/www/world.html, the projected world
population in 2050 will be 10 Billions.
One could also use the HD-ratio to get some indication on how much
address space should be allocated to ISPs, LIR & other entities that
assign addresses to other than just themselves. One way to look at
the problem is to see how many site (/48 prefixes) delegation they
can do given a prefix allocation and a particular HD value.
If they are allocated a prefix of length n, the formula is:
Number of site delegation = exp(HD x log(2^(48-n)))
IPv4 IPv4
pain level pain level
Prefix Available Reasonable Painful 01/01/2001 01/01/2002
Length Bits HD=80% HD=85% HD=86% HD=87%
-----------------------------------------------------------
/16 32 50859008 154175683 192462215 240256463
/17 31 29210829 85534315 106037549 131455567
/18 30 16777216 47453132 58421659 71925499
/19 29 9635980 26326273 32187562 39353810
/20 28 5534417 14605414 17733819 21532313
/21 27 3178688 8102861 9770493 11781337
/22 26 1825676 4495343 5383078 6446121
/23 25 1048576 2493948 2965820 3526975
/24 24 602248 1383604 1634026 1929773
/25 23 345901 767602 900271 1055869
/26 22 198668 425854 496006 577715
/27 21 114104 236257 273276 316095
/28 20 65536 131072 150562 172950
/29 19 37640 72716 82952 94629
/30 18 21618 40342 45702 51776
/31 17 12416 22381 25180 28329
/32 16 7131 12416 13873 15500
/33 15 4096 6888 7643 8480
/34 14 2352 3821 4211 4640
/35 13 1351 2120 2320 2538
/36 12 776 1176 1278 1389
/37 11 445 652 704 760
/38 10 256 362 388 415
/39 9 147 200 213 227
/40 8 84 111 117 124
/41 7 48 61 64 68
/42 6 27 34 35 37
/43 5 16 19 19 20
/44 4 9 10 10 11
/45 3 5 5 5 6
/46 2 3 3 3 3
/47 1 1 1 1 1
For example, if an ISP wants to delegates 10000 /48 site prefixes
with a HD-ratio (pain level) of 85%, it needs to be allocated at
least a /32 prefix.
3. Security considerations
Security issues are not discussed in this memo.
4. IANA Considerations
This memo does not request any IANA action.
5. Author addresses
Alain Durand
SUN Microsystems, Inc
901 San Antonio Road MPK17-202
Palo Alto, CA 94303-4900
USA
Mail: Alain.Durand@sun.com
Christian Huitema
Microsoft Corporation
One Microsoft Way Redmond, WA 98052-6399
USA
EMail: huitema@microsoft.com
6. References
[RFC1715] C. Huitema, "The H Ratio for Address Assignment
Efficiency." RFC 1715, November 1994.
[RFC3194] A. Durand, C. Huitema, "The Host-Density Ratio for Address
Assignment Efficiency: An update on the H ratio", RFC3194, November
2001.
[IANAV4] INTERNET PROTOCOL V4 ADDRESS SPACE, maintained by the IANA,
http://www.iana.org/assignments/ipv4-address-space
[DMNSRV] Internet Domain Survey, Internet Software Consortium,
http://www.isc.org/ds/
10. Full Copyright Statement
"Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
