Re: [sig-policy] prop-090-v002: Optimizing IPv6 allocation strategies
Different ISP have their own business and operationa reasons to select their own
assignment unit(s). APNIC should not favor one way or the other by
recommnding a specific unit.
Yi Chu
Sprint
----- Original Message ----
From: Owen DeLong <owen at delong dot com>
To: Yi Chu <yi_chu_01 at yahoo dot com>
Cc: Gaurab Raj Upadhaya <gaurab at lahai dot com>; APNIC Policy SIG List
<sig-policy at apnic dot net>
Sent: Fri, February 18, 2011 5:18:15 PM
Subject: Re: [sig-policy] prop-090-v002: Optimizing IPv6 allocation strategies
On Feb 18, 2011, at 11:07 AM, Yi Chu wrote:
> I support this proposal in principle. I do have a few comments:
> - Fully support 4.3 assignment and allocation on nibble boundaries
> - Support 4.4.2, however, suggest not to include the formula N=48-(X+Y),
>
> or any reference to assignment unit being /48
I'd like to know more about your objection here.
> - I do not support 4.7 as written. I am specifically against the
> statement ‘recommended provider assignment unit is /48’. I feel it is premature
>
> to recommend /48 as the LIR assignment unit. I am fine with the rest in this
> section.
Would you care to elaborate on this? We've been running an IPv6 production
network for years and we find that the /48 is a very good end-site assignment
unit.
Additionally, the policy does allow a provider to choose a smaller unit if they
wish and the formula is easily recomputed by replacing 48 with a different
(larger) number. The intent here is to say that providers cannot make default
end sites shorter (larger) than /48 without justification.
> - I support the rest of the proposal.
>
Thanks!
Owen
> yi
>
>
> ----- Original Message ----
> From: Gaurab Raj Upadhaya <gaurab at lahai dot com>
> To: APNIC Policy SIG List <sig-policy at apnic dot net>
> Sent: Fri, February 18, 2011 4:15:42 AM
> Subject: [sig-policy] prop-090-v002: Optimizing IPv6 allocation strategies
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear SIG members,
>
> Version 2 of 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 SAR, China, 21-25 February 2011.
>
> Changes in version 2:
>
> - In section 3, the status of the proposal in the ARIN region has
> been updated.
> - The calculation for probable impact over 50 years in section 5,
> "Disadvantages", has been changed from 99.62% to 99.54%.
>
> 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
> effective?
>
>
> Information about this and other policy proposals is available from:
>
> http://www.apnic.net/policy/proposals
>
>
> Gaurab, Ching-Heng, and Terence
>
> ________________________________________________________________________
>
> prop-090-v002: Optimizing IPv6 Allocation Strategies
> ________________________________________________________________________
>
>
> Author: Owen DeLong
>
> Version: 2
>
> Date: 18 February 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
>
> 2001:0db8::/30
>
> The LIR would need to calculate that the end address of that /30 was
>
> 2001:0dbb:ffff:ffff:ffff:ffff:ffff:ffff
>
> 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
> - ---------------------------
>
> ARIN:
>
> Draft Policy ARIN-2011-3, "Better IPv6 Allocations for ISPs",
> is currently under discussion and will be presented at ARIN XXVII
>
> https://www.arin.net/policy/proposals/2011_3.html
>
> The author intends to submit a similar proposal to LACNIC and AfriNIC.
>
> RIPE:
>
> 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.
> unit:
>
>
> 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
> customers.
>
>
> 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:
>
> 2001:0dbf:ffff:ffff:ffff:ffff:ffff:ffff
>
> 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
> aligned
>
> 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
> justification.
>
>
> 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
> - -------------
>
> Advantages:
>
> - 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.
>
>
> Disadvantages:
>
> - Increases IPv6 address allocation. Probable impact over 50 years,
> free pool drops from 99.9995% to 99.54%.
>
>
> 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'
> http://www.apnic.net/policy/ipv6-address-policy#5.5
>
>
> 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.
>
>
> - --
>
> http://www.gaurab.org.np/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1eOL4ACgkQSo7fU26F3X2SFgCgii4rA/48b7Db3zMgDyNEY0fY
> nCcAn2sMZ8DNTq+II9Q3g+6YaFByq0hC
> =ThUY
> -----END PGP SIGNATURE-----
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>
>
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy