[sig-policy]Discussion document: Application of the HD-Ratio to IPv4

  • To: <sig-policy at lists dot apnic dot net>
  • Subject: [sig-policy]Discussion document: Application of the HD-Ratio to IPv4
  • From: "Paul Wilson" <pwilson at apnic dot net>
  • Date: Thu, 7 Aug 2003 17:52:27 +1000
  • Importance: Normal
  • List-archive: <http://www.apnic.net/mailing-lists/sig-policy/>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>,<mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>,<mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • Organization: APNIC
  • Sender: sig-policy-admin@lists.apnic.net
    • 
      Following is a discussion paper for the Address Policy SIG at APNIC 16.
      Note that this is not a proposal for approval at this meeting.
      
      I hope to have a lively discussion about this topic, so please feel free to
      send comments or questions to this list, or to me directly by email.
      
      Hope to see you in Seoul,
      
      ________________________________________________________________________
      Paul Wilson, Director-General, APNIC                      <dg at apnic dot net>
      http://www.apnic.net                            ph/fx +61 7 3858 3100/99
      ------------------------------------------------------------------------
      See you at APNIC 16
      Seoul, Korea, 19-22 August 2003            http://www.apnic.net/meetings
      ------------------------------------------------------------------------
      
      
      
      Discussion Document
      
      Application of the HD-Ratio to IPv4
      
      Prepared by: Paul Wilson, APNIC Secretariat
      Version: 1.0
      Date: 7 August 2003
      
      1    Summary
      
      Internet address space is managed hierarchically, by
      allocation from IANA to RIRs and from RIRs to LIRs (ISPs),
      and by assignment from LIRs to infrastructure components and
      customer networks.  Within each level of allocation or
      assignment some address space is generally reserved for
      future expansion and/or efficient aggregation.  As more
      hierarchical levels are introduced into any address space,
      the overall efficiency of utilisation of that space (in
      terms of the total number of individual addresses actually
      used) will inevitably decrease.
      
      The HD Ratio (Host-Density Ratio) has been proposed as a
      practical mechanism for measuring the utilisation of
      addresses within hierarchically-managed Internet address
      blocks [RFC 3194].  A given HD Ratio value corresponds to a
      percentage utilisation which decreases as the size of the
      address space grows, thus allowing for the decreasing
      overall address management efficiency which is described
      above.
      
      The HD Ratio is currently used as the utilisation metric for
      IPv6 address space, under the current IPv6 management policy
      [ipv6-address-policy].  According to this policy, a block of
      IPv6 address space is considered to be effectively utilised
      when its HD-Ratio reaches 0.80.  This value is said to
      represent a conservative but manageable figure ("values of
      80% or less correspond to comfortable trade-offs between
      pain and efficiency" [RFC 3194]).
      
      This document explores the possible use of the HD Ratio for
      measurement of IPv4 utilisation, for the same purpose of
      determining when a given block of address space should be
      considered as fully utilised.
      
      
      2    Background and problem
      
      The current management framework for IPv4 address space
      relies on policies developed within each RIR community [ipv4-
      address-policy].  These policies dictate, effectively, that
      a given block of IPv4 addresses should be considered
      "utilised" when at least 80% of the addresses within the
      block have been allocated or assigned. This measure is
      applied equally for address blocks held by small or large
      LIRs, regardless of their size.  In any case, it is deemed
      that once 80% of the space held by an LIR has been allocated
      or assigned, that LIR may request more address space from
      its appropriate RIR.
      
      Current policies assume a hierarchical system of address
      space delegation (from IANA to RIRs to LIRs to customers, as
      described above), but they make no allowance for
      hierarchical address management within an organisation's own
      address space. For LIRs in particular, a hierarchical
      approach is often required for assignment of address space
      to service elements such as customer networks, individual
      POPs, regionalised topologies, and even distinct ISP
      products. Small network infrastructures may require simple
      hierarchies, but large infrastructures can require several
      levels of address space subdivision. These levels of
      hierarchy are "hidden" in terms of recognition by the
      current RIR policy framework, and highly constrained by the
      80% utilisation requirement.  As a result, management of
      large blocks is often extremely difficult, requiring large
      internal routing tables and/or frequent renumbering of
      internal address blocks.
      
      One of the goals of the RIR system is to avoid unnecessary
      depletion of IPv4 address space, and the 80% utilisation
      requirement may be justifiable on that basis.  However
      address management policies must also be practical in terms
      of management overhead imposed.  It may be argued that when
      large address spaces are involved, the "80% rule" imposes
      unreasonable management overheads on an LIR.
      
      A more reasonable approach should attempt to impose a
      uniform degree of management overhead, rather than
      penalising the holders of large address blocks.  This may be
      achievable to some degree by basing utilisation requirements
      on the HD ratio rather than the fixed percentage-based
      measure which is in use today.
      
      
      3    A Proposal
      
      In recognition of the problems outlined above, it is now
      proposed to consider replacing the current fixed percentage
      based utilisation requirement for IPv4 address space with an
      "HD Ratio" based requirement, referred to as the AD Ratio.
      
      3.1  The HD Ratio
      
      According to RFC3194, The HD-Ratio is calculated as follows:
      
           HD = log(U)/log(S)
           
           Where:
                S is the size of the address block concerned, and
                U is the number of site addresses (/48s) which are
                utilised.
      
      In order to calculate the HD-Ratio for a given IPv6 block,
      it is necessary to know the size of that block, and number
      of host addresses which are in use.  The current IPv6
      policies allow for this by requiring registration of address
      assignments to the /48 level, however this degree of
      registration is not appropriate under IPv4 management
      policies.
      
      3.2  Definition - the AD Ratio
      
      IPv4 address space utilisation is measured in terms of the
      number of allocations or assignments which have been made
      from a given address block, rather than the number of host
      addresses which are in use within the block.  We therefore
      use the term "Allocation Density" for the measure of address
      space utilisation within an IPv4 block, rather than the term
      "Host Density" which represents host-address utilisation in
      IPv6.
      
      Consequently, we refer propose a new utilisation metric for
      IPv4, to be known as the "AD Ratio" (for Allocation or
      Assignment Density Ratio). The AD Ratio measures the number
      of addresses allocated or assigned from a given block of
      address space, as follows:
      
           AD = log(A)/log(S)
      
           Where:
                S is the size of the of the address block, and
                A is the number of addresses allocated or assigned
                from that block.
      
      3.3  Selection of AD Ratio value
      
      The appropriate AD Ratio value for the purposes of this
      proposal should be decided on a rational basis. In order to
      do this, we make certain assumptions about the depth of
      "hidden" hierarchy involved in managing address blocks of
      various sizes.  We then assume that at each level of this
      assumed hierarchy, the currently accepted 80% utilisation
      requirement is achieved, in order for the entire address
      space to be considered as fully utilised.
      
      The following table proposes a set of assumed hierarchical
      depths which may be reasonably expected within
      hierarchically-managed address spaces of certain sizes. At
      each delegation level an allocation density of 80% is
      assumed, so that within a hierarchy of "n" levels, the
      overall address space utilisation is calculated as 0.80 to
      the power of "n".
      
           Size range        Depth     Util        AD Ratio
           (prefix)          (n)       (0.80**n)   (calculated)
           
           /24 to /20        1         80%         .960 to .973
           /20 to /16        1.5       72%         .961 to .970
           /16 to /12        2         64%         .960 to .968
           /12 to /8         2.5       57.2%       .960 to .966
           /8 to /4          3         51.20%      .960 to .966
           
           Note:  the above AD Ratio values are derived directly
           from the formula above.  For instance, a /20 block
           contains 4096 addresses, and 80% utilisation
           corresponds to 3276.8 addresses; therefore the
           corresponding AD Ratio is calculated as
           log(3276.8)/log(4096) = 0.973
      
      The depths of address hierarchy listed above are notional
      approximations only, based on general assumptions about the
      likely size and structure of LIRs holding address blocks in
      the respective size ranges.  From the table, a rational
      common AD ratio value may be determined as 0.966 (chosen as
      the most conservative value which is common to all of the
      listed ranges).  For this value, the following table gives
      the percentage utilisation requirement for the full range of
      IPv4 address blocks (this is also derived directly from the
      AD ratio formula shown above).
      
           IPv4        Addresses        Addresses      Util%
        Prefix            Total         Utilised
        
            32                1                1     100.00%
            31                2                2      97.67%
            30                4                4      95.40%
            29                8                7      93.17%
            28               16               15      91.00%
            27               32               28      88.88%
            26               64               56      86.81%
            25              128              109      84.79%
            24              256              212      82.82%
            23              512              414      80.89%
            22             1024              809      79.00%
            21             2048             1580      77.16%
            20             4096             3087      75.37%
            19             8192             6030      73.61%
            18            16384            11780      71.90%
            17            32768            23010      70.22%
            16            65536            44949      68.59%
            15           131072            87804      66.99%
            14           262144           171518      65.43%
            13           524288           335046      63.90%
            12          1048576           654485      62.42%
            11          2097152          1278482      60.96%
            10          4194304          2497408      59.54%
             9          8388608          4878479      58.16%
             8         16777216          9529704      56.80%
             7         33554432         18615487      55.48%
             6         67108864         36363809      54.19%
             5        134217728         71033685      52.92%
             4        268435456        138758413      51.69%
             3        536870912        271053050      50.49%
             2       1073741824        529479652      49.31%
             1       2147483648       1034294583      48.16%
             0       4294967296       2020408681      47.04%
      
         Note: This table provides values for CIDR blocks only,
         however for non-CIDR blocks the same calculations can be
         applied to produce equally meaningful results.
      
      
      4    Implementation
      
      If implemented at any particular level in the IP address
      delegation chain, this proposal would have a number of
      impacts on administrative processes at that level.  It is
      not currently proposed to apply this proposal to the
      relationship between RIRs and IANA, therefore the
      implementation of the proposal at the RIR-LIR level is
      discussed there.
      
      4.1  RIR-LIR Procedures
      
      The impact of the proposal on the RIR-LIR administrative
      procedures would be to replace the current 80% utilisation
      requirement, with a 0.966 AD Ratio requirement.
      
      By way of examples, an LIR holding a total address space
      equal to a /16 would be able to receive more address space
      when they had allocated or assigned 68.59% of that space;
      while an LIR holding a /9 would be able to receive more
      space when they had allocated or assigned 58.16% of their
      address space. For blocks smaller than /22, it is proposed
      that the current 80% requirement be used, in order that this
      new policy does not impose tighter utilisation requirements
      than were previously imposed.
      
      The AD-Ratio calculation is trivial, but certainly more
      complex and less intuitive than the existing 80%
      calculation.  Some APNIC members may in some circumstances
      require extra assistance, however for those using the
      MyAPNIC service, the calculation would be automatic and
      therefore no additional effort would be involved.
      
      4.2  Assignment procedures
      
      In order to support consistent calculation of an LIR's AD
      Ratio, it would be preferable for each LIR to register
      infrastructure assignments in the same way as customer
      assignments.  This could be done by whois update via email,
      or via the MyAPNIC service.  It would not be necessary to
      register individual hardware components or subnets, but
      rather only the independent infrastructure blocks which are
      designated by the LIR, and which can be justified on the
      same basis as customer assignments. Such registrations would
      be publicly visible as normal whois records, unless database
      changes were implemented to specifically hide them.
      
      4.3  Implementation timeline
      
      If implemented, this policy could be effective within 3
      months of the implementation date.
      
      
      5    Impacts
      
      5.1  Administrative Impact
      
      The primary administrative impact of this proposal is to
      ease the administrative address management burden
      experienced by LIRs, especially those with large address
      space holdings. The proposal recognises the need to manage
      address space hierarchically within an LIR service
      infrastructure, and makes allowance for it through the use
      of the AD ratio for assessment of address utilisation.
      
      This proposal would impose a small administrative cost on
      LIRs.  In the first place, an LIR's internal systems (manual
      or automated) would need to incorporate a new method of
      calculating address space utilisation (and especially when
      determining the point at which the LIR may request more
      space from APNIC).  In the second place, an LIR would need
      to register infrastructure assignments in the same way as
      customer assignments, which would impose additional
      administrative cost.  In both cases, LIRs using the MyAPNIC
      service would experience a small extra cost because these
      changes can be automated within that system.
      
      The administrative impact on internal systems of the APNIC
      Secretariat is also relatively small.  APNIC hostmaster
      processes can be tailored easily to accommodate a changed
      method of calculating address space utilisation; and the
      whois database can certainly accommodate an increased number
      of registrations.
      
      5.2  Address Space Consumption
      
      Because this proposal lowers the utilisation requirement for
      IPv4 address blocks, it would certainly increase the rate of
      deployment of IP addresses.  In analysing this impact, we
      can identify two separate factors contributing to increased
      consumption: firstly, an initial impact resulting from
      increased "wastage" of deployed address space; and secondly,
      on ongoing impact as utilisation requirements continue to
      fall for individual LIRs' growing address holdings.
      
      5.2.1     Initial impact
      
      The initial impact on address consumption can be estimated
      by calculating for each APNIC LIR the difference between the
      current 80% utilisation, and the AD-ratio-determined
      utilisation requirement. This calculation will indicate the
      amount of extra "wasted" address space which would result
      from the proposed policy change.
      
           Total LIRs in sample                788
           
           Total address space held           4.17  (/8 blocks)
           Utilised addresses (80%)           3.32
           Utilised addresses (AD 0.966)      2.53*
           Extra "wasted" space               0.81
           Extra "wastage" as % of total       19%
           
           * This figure is calculated from the sample of 788
           LIRs, according to actual address space holdings
      
      These figures show that by reducing the address space
      utilisation requirement from 80% to AD 0.966, an additional
      0.81 blocks are consumed out of a total 4.17 blocks
      allocated. This corresponds to an additional of 19% of the
      total allocated address space.
      
      It should be noted that this assessment indicates a
      theoretical impact in terms of increased address
      consumption, assuming all deployed address space is actually
      utilised.  The actual impact will be less than this due to
      underutilisation of address space; and furthermore the
      impact will not take place at one time, but progressively as
      part of ongoing address space allocations.
      
      5.2.2     Ongoing impact
      
      The ongoing impact on address consumption can be estimated
      by distributing additional address space to the same set of
      LIRs, in proportion to their existing address space
      holdings. For the purposes of this analysis, an additional
      /8 block is distributed to the same set of 788 LIRs, in
      proportion to their existing address holdings.
      
           Initial address space held         4.17  (/8 blocks)
           Additional space allocated         1.00
           Total address space now held       5.17
           Utilised addresses (AD 0.966)      3.11*
           Additional addresses utilised      0.58*
           Utilised addresses (80%)           0.80
           Extra "wasted" space               0.22
           Extra "wastage" as % of allocation  22%
           
           * These figures are calculated from the same sample of
           788 LIRs, assuming a proportional distribution of an
           additional /8 block
      
      These figures show that after an additional /8 block is
      distributed and utilised, 58% of that block would actually
      be utilised, rather than 80%.  Therefore up to 22% of that
      block would be "wasted" by the use of AD 0.966 in place of
      80% as the utilisation measure, resulting potentially in an
      increased consumption rate of up to 22%.
      
      Again, this calculation is theoretical only, and assumes
      that all address space which has been distributed will be
      utilised.
      
      5.2.3     Conclusions on address consumption
      
      The above analysis indicates that the adoption of this
      proposal would cause an initial additional consumption of up
      to 19% of address space allocated.  In APNIC's case, a total
      of 8.07 /8 blocks have been allocated (as of 1 July 2003),
      so up to an additional 1.53 blocks would eventually be
      consumed as a result of the change.
      
      The analysis also indicates that this proposal would cause
      an overall 22% increase in the rate of address consumption.
      In APNIC's case, a total of 1.90 /8 blocks per year are
      currently being allocated (in the 12 months to 1 July 2003),
      and this rate would therefore rise to 2.32 blocks per year.
      
      The assumptions on which the above analysis is made include:
      firstly, that the 788 LIRs in the sample are representative
      of all LIRs in the region; and secondly, that a consistent
      rate of growth will be experienced by all LIRs in the
      region.
      
      
      6    References
      
      [RFC 3194] "The Host-Density Ratio for Address Assignment
      Efficiency: An update on the H ratio", A. Durand, C.Huitema,
      November 2001.
      
       [ipv6-address-policy] APNIC document: "IPv6 Address
      Allocation and Assignment Policy"
      (http://www.apnic.net/docs/policy/ipv6-address-policy.html)
      
      [ipv4-address-policy] APNIC document: "Policies for IPv4
      address space management in the Asia Pacific region"
      (http://www.apnic.net/docs/policy/add-manage-policy.html)