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

Charles O'Hern charles at office.tcsn.net
Wed Dec 8 14:17:32 EST 2010


We strong support this policy proposal.

-- 
Charles O'Hern
Network Operations

TCSN - The Computer Shop Netlink
1306 Pine St. Paso Robles CA 93446
1-(805) 227-7000  1-(800) 974-DISK
http://www.tcsn.net  abuse at tcsn.net

On 12/2/10 7:49 AM, ARIN 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.


-- 
Charles O'Hern
Network Operations

TCSN - The Computer Shop Netlink
1306 Pine St. Paso Robles CA 93446
1-(805) 227-7000  1-(800) 974-DISK
http://www.tcsn.net  abuse at tcsn.net



More information about the ARIN-PPML mailing list