[GLOBAL-V6] Analyzing IPv4 and Ipv6 address space with the HD-ratio

  • To: global-v6 at lists dot apnic dot net
  • Subject: [GLOBAL-V6] Analyzing IPv4 and Ipv6 address space with the HD-ratio
  • From: Alain Durand <alain.durand at eng dot sun dot com>
  • Date: Wed, 20 Feb 2002 16:00:34 -0800
  • References: <20020212115606.V56841@Space.Net> <200202142142.g1ELg1F10925@rotala.raleigh.ibm.com> <20020215002803.F56841@Space.Net> <v04220801b8988e35e256@[171.71.118.51]> <20020220163119.V26551@Space.Net>
  • Sender: owner-global-v6@lists.apnic.net
    • 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 at sun dot com
      
         Christian Huitema
         Microsoft Corporation
         One Microsoft Way Redmond, WA 98052-6399
         USA
         EMail: huitema at microsoft dot 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.