Re: [sig-policy] prop-090-v002: Optimizing IPv6 allocation strategies
I think there are a number of reasons that the /48 recommendation is good
and I would prefer to retain it. As I have said, it is a recommendation and
any provider that wants to may use a longer minimum assignment unit
which is supported by the policy. However, if there is larger opposition to
this recommendation, I would rather see us move forward with the rest
of the policy than preserve the recommendation to the detriment of the
policy.
I would like to know what actual downsides you see to using a /48 as a
default assignment unit, but, if you are unwilling to elaborate for whatever
reasons, that is your prerogative.
Do others have opinions as to whether this recommendation should
stand or be removed?
My reasons that it should stand are as follows:
+ Promotes innovative capabilities in the home gateway and
residential networking arena
+ Is in line with the initial design criteria of the IPv6 protocol
+ Provides maximum flexibility to subscribers for the future
deployment of flexible topologies
+ No obvious (or yet stated) disadvantages
I can only speculate as to what the business or operational reasons
for wanting a longer assignment unit might be. None of the ones that
come to mind are in the subscriber's best interest, but, only serve to
allow providers to treat reasonable address allocations as a premium
service for increased billing. If there are other reasons, I would like
to know what those are so that I can better understand them and
consider them in this or future policy proposals.
Owen
On Feb 19, 2011, at 9:46 AM, Yi Chu wrote:
> I am fine with APNIC setting max end-site assignment unit without justification
> 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
>>
>>
>>
>
>
>