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 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.