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

[ARIN]

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.