[sig-policy] prop-090: Optimizing IPv6 allocation strategies

  • To: APNIC Policy SIG List <sig-policy at apnic dot net>
  • Subject: [sig-policy] prop-090: Optimizing IPv6 allocation strategies
  • From: Gaurab Raj Upadhaya <gaurab at lahai dot com>
  • Date: Wed, 12 Jan 2011 10:59:24 +0000
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • List-archive: <http://mailman.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>
  • User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101207 Thunderbird/3.1.7
    • Hash: SHA1
      Dear SIG members,
      The proposal, 'Optimizing IPv6 Allocation Strategies', has been sent to
      the Policy SIG for review. It will be presented at the Policy SIG at
      APNIC 31 in Hong Kong, 21-25 February 2011.
      We invite you to review and comment on the proposal on the mailing list
      before the meeting.
      The comment period on the mailing list before an APNIC meeting is an
      important part of the policy development process. We encourage you to
      express your views on the proposal:
              - Do you support or oppose this proposal?
              - Does this proposal solve a problem you are experiencing? If
                so, tell the community about your situation.
              - Do you see any disadvantages in this proposal?
              - Is there anything in the proposal that is not clear?
              - What changes could be made to this proposal to make it more
      Information about this and other policy proposals is available from:
      Gaurab, Ching-Heng, and Terence
      prop-090-v001: Optimizing IPv6 Allocation Strategies
      Author:        Owen DeLong
      Version:       1
      Date:          12 January 2011
      1.  Introduction
      - ----------------
      This is a proposal to change how the size of IPv6 allocations and end
      site assignments are determined, allowing more room for LIRs to grow
      within their allocation, while also preventing excessive address
      consumption. The proposal also assists to prevent potential human errors
      in configuration that can be caused by the current IPv6 policies, which
      allow allocations and assignments to be made on non-nibble boundaries.
      2.  Summary of the current problem
      - ----------------------------------
      2.1 Many ISPs expect to make all of their users fit within a /32 IPv6
           address block.
           This assumption has led to such problems as end user customers
           receiving single /64s, minimal /60s, or even /56s. If the practice
           of unnecessarily limited address spaces becomes widespread, vendors
           will not produce the innovations that are possible in home
           networking with larger address spaces. Just as NAT has delayed or
           prevented many forms of innovation in IPv4, small customer
           assignment sizes could seriously reduce innovation in IPv6.
           If this proposed policy were to be implemented, in 50
           years, the projected IPv6 free pool would be 99.54% of total
           IPv6 space vs 99.9975% if the current policy were still in place
           at that time. Given the small amount of extra IPv6 addresses that
           would be consumed by implementation of this proposed policy, it
           would be a shame for innovation to be stifled by continuing the
           current policy.
      2.2 Mistakes are made when calculating end addresses for non-nibble
           boundary allocations and assignments
           In IPv6, non-nibble boundary prefixes can lead to human error in
           calculating the end address of the prefix. For example, if a network
           were allocated
           The LIR would need to calculate that the end address of that /30 was
           However, even experienced engineers can make mistakes when making
           such calculations. In fact, to clarify the problem, as I was writing
           the above example, I initially made the mistake of calculating the
           end of the range as 2001:0db3:ffff:ffff:ffff:ffff:ffff:ffff.
           When mistakes like this are made in routers, it causes outages.
      2.3 If /32s continue to be the default allocation size, it will also
           eventually lead to unnecessary disaggregation and larger
           routing tables.
      2.4 The HD Ratio is confusing to many ISPs and misunderstood by many in
           the community.
           Therefore, this proposal replaces the HD ratio with simple ratios
           for utilization thresholds and reduces the frequency with which
           utilization thresholds would need to be calculated.
      3.  Situation in other RIRs
      - ---------------------------
           Submitted. Currently undergoing a process of staff review before
           being handed to the ARIN Address Council for further review.
      The author intends to submit a similar proposal to LACNIC and AfriNIC.
           As RIPE NCC seems to be currently issuing generous allocations, the
           author currently has no intention of submitting this proposal to
           RIPE. However, the author may eventually submit a proposal to RIPE
           to address the problem of non-nibble boundary allocations.
      4.  Details
      - -----------
      This is a proposal to amend the IPv6 policy to:
      4.1 Add the following definitions:
           Serving site:  A location where an ISP terminates or aggregates
                          customer connections, including, but not limited to
                          Points of Presence (POPs), Datacenters, Central or
                          Local switching offices or regional or local
                          combinations thereof.
           Provider       The prefix of the smallest IPv6 block a given ISP
           assignment     assigns to end sites.
           Nibble         A network mask which aligns on a 4-bit boundary.
           boundary:      This means that the prefix length must be divisible
                          by 4. For example, /24, /28, /32, and /48 are all
                          aligned on a nibble boundary while /22, /26, /29,
                          /30, and /47 are not.
      4.2 Redefine the following terms:
           End site:      A single structure or service delivery address, or
                          a single tenant within a multi-tenant structure
                          - The aim of this more generous interpretation of end
                            site to provide a clear definition which is easily
                            understood and provides maximum flexibility for
                            service providers to meet the needs of their
           Utilized:    (i)  A provider assignment unit shall be considered
                             fully utilized when it is assigned to an
                             end site.
                       (ii) The utilization percentage of a block at the LIR
                            level is calculated as the fraction of total
                            provider assignment units which have been assigned
                            to end sites.
      4.3 Make all allocations and assignments on nibble boundaries
           Removing the ability to make delegations on non-nibble boundaries
           makes it easier for end addresses of IPv6 blocks to be calculated.
           For example, if the next allocation one size larger than /32 is /28,
           then, 2001:0db0::/28 has an end address of:
           Allocating and assigning on nibble boundaries also makes DNS
           delegations easier.
      4.4 Change the size of initial allocations to LIRs according to the
           following criteria:
           4.4.1 The minimum allocation size for an LIR shall be a /32, unless
                 the LIR specifically requests a /36.
           4.4.2 The maximum allocation unit shall be the smallest block which:
                 - Is nibble-boundary aligned
                 - Permits the largest serving site to be assigned a large
                   enough block to allow <=0.75 (75%) utilization
                 - Can provide an equal-sized block to each serving site
                 - Permits each serving site's block to be nibble-boundary
                 This can be summarized as /N where:
                     N = 48-(X+Y) where:
                          X is a multiple of 4 such that 2^X is greater than
                          4/3*(serving sites)
                          Y is a multiple of 4 such that 2^Y is greater than
                          4/3*(end sites served by the largest serving site)
                 In addition:
                     (i) An end site which can justify more than a /48 under
                         the current end-user assignment policy [1] shall count
                         as the appropriate number of /48s that would be
                         assigned under that policy.
                    (ii) An LIR which has subordinate LIRs shall make such
                         allocations according to the same policies and
                         criteria as APNIC. In such a case, the prefixes
                         necessary for such an allocation shall be treated as
                         fully utilized in determining the block sizing
                         for the parent LIR.
                   (iii) An LIR is not required to design or deploy their
                         network according to this structure. It is strictly a
                         mechanism to determine the largest IP address block to
                         which the LIR is entitled.
      4.5 Change the criteria for an allocation
           To qualify for an allocation, an LIR must meet the criteria
           described in one of the following sections: 4.5.1, 4.5.2, or 4.5.3:
           4.5.1 The LIR:
                 - Has a previously justified IPv4 allocation from APNIC, OR
                 - Has a previously justified IPv4 allocation from one
                   of APNIc's predecessor registries, OR
                 - Can qualify for an IPv4 ISP allocation under current
                   APNIC criteria.
           4.5.2 The LIR:
                 - Will be making reassignments to other organizations AND
                   - Is currently multihomed for IPv6, OR
                   - Will immediately become multihomed for IPv6 using a valid
                     assigned global AS number
           4.5.3 The LIR must provide APNIC a reasonable technical
                 justification of why an allocation is necessary including:
                 - The intended purposes for the allocation
                 - A description of the network infrastructure the allocation
                   will be used to support.
                 - A plan detailing assignments to other organizations or
                   customers for one, two, and five year periods, with a
                   minimum of 50 assignments within 5 years.
      4.6 Change the way subsequent allocations to LIRs are made
           To qualify for a subsequent allocation, an LIR must meet one of the
           following two criteria:
           - Utilization of 75% or more of their total address space, OR
           - One the LIR/ISP's serving sites has a 90% utilization rate
           Note: the process for calculating the utilization rate is detailed
                 in  Appendix A.
           When making subsequent allocations to LIRs, APNIC will follow the
           allocation procedure below:
           - Wherever possible, APNIC will make an allocation that expands one
             or more existing allocations.
           - Where  APNIC cannot expand one or more existing allocations, APNIC
             shall make a new allocation based on the initial allocation
             criteria described in section 4.5 above.
             When this occurs, the LIR is encouraged, but not required, to
             renumber into the new allocation over time and return any
             allocations no longer in use. In such a case, it is legitimate for
             an end-site to have assignments from as many as two of these
             blocks at a time to facilitate transition to the new range.
      4.7 Change the recommendations for LIRs to make assignments to end users
           The recommended provider assignment unit is /48. In no case will
           policy consider a provider assignment unit larger than /48.
           Instead, if an LIR/ISP chooses to assign more than a /48 to an
           end site, that will be considered to be multiples of the provider
           assignment unit.
           If the LIR/ISP chooses to have a provider assignment unit
           smaller than a /48, then calculations of its address space
           utilization will accordingly use the smaller prefix size.
           An LIR may issue up to a /48 to an end site without requiring
      4.8 Allow LIRs with existing IPv6 allocations to expand their allocation
           size if they are eligible for a larger block under the allocation
           criteria suggested in this proposal.
           Any LIR which received an allocation under previous policies which
           is smaller than what they are entitled to under this policy may
           receive a new initial allocation under this policy provided that
           they agree to renumber into that new allocation and return their
           prior allocation(s) within 5 years.
           If possible, APNIC will simply expand their existing allocation
           rather than requiring renumber and return.
      5.  Pros/Cons
      - -------------
           - Provides nibble-boundaries for direct allocations and for at least
             one level	of network hierarchy within the LIR, reducing the
             potential for human factors errors.
           - Increases the potential for network aggregation by issuing very
             large blocks to ISPs.
           - Reduces the potential for harmful under-sized assignments to end
             users by removing any incentive to do so.
           - Simplifies the IPv6 allocation policy by removing logarithmic
             computations in favor of simple ratios.
           - Reduces the number of times any given LIR will need to return to
             APNIC for	additional allocations.
           - Allows for better network planning and growth.
           - Increases IPv6 address allocation. Probable impact over 50 years,
             free pool drops from 99.9995% to 99.62%.
      6.  Effect on APNIC
      - -------------------
      APNIC LIR members will be able to obtain significantly larger blocks of
      IPv6 addresses and both receive and make their allocations and
      assignments on nibble boundaries to simplify human factors and network
      management while improving aggregation.
      7.  Effect on NIRs
      - ------------------
      This policy should not significantly impact NIRs.
      8.  References
      - --------------
      [1] Section 5.5, 'Assignment', in 'APNIC IPv6 Allocation Policy'
      Appendix A
      - ----------
      In general, the following formula is used to calculate the utilization
      rate in IPv6:
                           No. of provider assignment units assigned
           Utilization % = ----------------------------------------- x 100
                           Total no. of provider assignment units
                           within allocation block(s)
      However, there may be occasions when the calculation may need to be
      amended if an LIR is in the process of renumbering out of an earlier
      IPv6 block into a subsequent block from APNIC. If this is the case,
      the following is permitted:
           - An LIR can count provider assignment units made to end sites
             in both the original and newer block into which the LIR is in
             the process of renumbering into.
           - The LIR can count assignments made to serving sites in both the
             original and newer block into which the LIR is in the process of
             renumbering into.
      This double-counting during renumbering means that APNIC would always
      allocate enough space to an LIR to encompass both existing customers and
      growth of the LIR within a single new aggregatable block.
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
      Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
      -----END PGP SIGNATURE-----