[arin-ppml] Policy Proposal 121: Sensible IPv6 Allocation for ISPs - revised

[Hannigan, Martin]

Not in favor....


Best,

-M<


On 12/2/10 10:49 AM, "ARIN" <info at arin.net> wrote:

> The proposal originator submitted revised text.
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Policy Proposal 121: Sensible IPv6 Allocation for ISPs
> 
> Proposal Version: .9
> 
> Date: 2 December 2010
> 
> Policy statement:
> 
>> Amend section 2 as follows:
>> 
>> Delete section 2.9 (Obsolete)
>> Replace section 2.10 with the following:
>> 2.10 The term End Site shall mean a single structure or service delivery
>> address, or, in the case of a multi-tenant structure, a single tenant
>> within said structure (a single customer location).
>> Add the following:
>> 2.12 The term serving site shall mean a location where an ISP terminates
>> or aggregates customer connections, including, but, not limited to
>> Points of Presence (POPs), Datacenters, Central or Local switching
>> office or regional or local combinations thereof.
>> 2.13 The term provider assignment unit shall mean the prefix of the
>> smallest block a given ISP assigns to end sites (recommended /48).
>> 2.14 The term utilized shall have the following definitions:
>> (i) A provider assignment unit shall be considered fully utilized when
>> it is assigned to an end-site.
>> (ii) Larger blocks shall have their utilization defined by dividing the
>> number of provider assignment units assigned from the
>> containing block by the total number of provider assignment
>> units. This ratio will often be expressed as a percentage
>> (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization)
>> 
>> Replace sections 6.5.1 through 6.5.3 with the following:
>> 6.5.1 Terminology
>> (a) The terms ISP and LIR are used interchangeably in this document and
>> any use of either term shall be construed to include both meanings.
>> (b) The term nibble boundary shall mean a network mask which aligns
>> on a 4-bit boundary (in slash notation, /n, where n is evenly divisible
>> by 4, allowing unit quantities of X such that 2^n=X where n is
>> evenly divisible by 4, such as 16, 256, 4096, etc.)
>> 
>> 6.5.2 Initial Allocations to LIRs
>> 6.5.2.1 Size
>> (a) All allocations shall be made on nibble boundaries.
>> (b) In no case shall an LIR receive smaller than a /32
>> unless they specifically request a /36.
>> (c) The maximum allowable allocation shall be the smallest
>> nibble-boundary aligned block that can provide an equally
>> sized nibble-boundary aligned block to each of the
>> requesters serving sites large enough to satisfy the needs
>> of the requesters largest single serving site using no more
>> than 75% of the available addresses.
>> 
>> This calculation can be summarized as /N where
>> N = 48-(X+Y) and X is a multiple of 4 greater
>> than 4/3*serving sites and Y is a multiple of 4
>> greater than 4/3*end sites served by largest serving site.
>> 
>> (d) For purposes of the calculation in (c), an end site which
>> can justify more than a /48 under the end-user assignment
>> criteria in 6.5.8 shall count as the appropriate number of /48s
>> that would be assigned under that policy.
>> (e) For purposes of the calculation in (c), an LIR which has
>> subordinate LIRs shall make such allocations according
>> to the same policies and criteria as ARIN. In such a case,
>> the prefixes necessary for such an allocation should be treated
>> as fully utilized in determining the block sizing for the parent LIR.
>> (f) 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.
>> 6.5.2.2 Qualifications
>> An organization qualifies for an allocation under this policy if
>> they meet any of the following criteria:
>> (a) Have a previously justified IPv4 ISP allocation from ARIN
>> or one of its predecessor registries or can qualify for
>> an IPv4 ISP allocation under current criteria.
>> (b) Are currently multihomed for IPv6 or will immediately
>> become multihomed for IPv6 using a valid assigned
>> global AS number and will be making reassignments
>> to other organizations.
>> (c) Provide ARIN a reasonable technical justification,
>> indicating why an allocation is necessary, including
>> the intended purposes for the allocation, and describing
>> the network infrastructure the allocation will be used to
>> support. Justification must include 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.
>> 6.5.3 Subsequent Allocations to LIRs
>> (a) Where possible ARIN will make subsequent allocations by
>> expanding the existing allocation.
>> (b) An LIR which can show utilization of 75% or more of their
>> total address space, or more than 90% of any serving site
>> shall be entitled to a subsequent allocation.
>> (c) If ARIN can not expand one or more existing allocations,
>> ARIN shall make a new allocation based on the initial
>> allocation criteria above. The LIR is encouraged, but not
>> required to renumber into the new allocation over time
>> and return any allocations no longer in use.
>> Replace section 6.5.4 with the following
>> 6.5.4  Assignments to end users shall be governed by the same
>> practices adopted by the community in section 6.5.8 except
>> that the requirements in 6.5.8.1 do not apply.
>> 
>> Add the following to 6.5.7
>> LIRs 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, ARIN will simply expand their existing
>> allocation rather than requiring renumber and return.
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.