Re: [sig-policy] prop-090-v002: Optimizing IPv6 allocation strategies
at /48. What I am against is the statement ‘recommended provider assignment
unit is /48’. And as for using /48 as examples, I am fine as long as it is
stated obviously that they are examples.
yi
----- 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: Sat, February 19, 2011 12:26:10 PM
Subject: Re: [sig-policy] prop-090-v002: Optimizing IPv6 allocation strategies
The proposal doesn't favor one particular unit. It simply sets a maximum
end-site assignment unit without justification at /48. Do you think a larger
unjustified assignment unit without justification should be permitted?
Yes, it uses /48 for the examples (because there aren't really reasons
not to use /48 under the proposed policy), but, if an ISP wants to
do something else, the proposal allows for that.
Owen
On Feb 19, 2011, at 8:27 AM, Yi Chu wrote:
> Owen:
> 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
>
>
>