[arin-ppml] Fwd: Policy Proposal 121: Better IPv6 Allocations for ISPs - revised

[Owen DeLong]

There are two changes in this policy revision:

	1.	Version incremented to 1.0
	2.	It has been brought to my attention that some are offended or
		insulted by the use of the word Sensible in the title. As a result
		I have removed the offending word and renamed the proposal.

There are no changes to the content of the policy as none have been
suggested since the last revision.

I apologize to anyone who felt offended by my use of the word sensible
in the title. It was not my intent to imply that the current system is not
sensible or to in any way impugn or insult current policy or people who
disagree with this proposal. I used the word to describe that I felt the
allocations issued under this policy were not grotesquely large or
non-sensical, but, sensible in the context of the need for improved
route aggregation and the vastness of available IPv6 number
resources.

Owen


Policy Proposal 121: Better IPv6 Allocations for ISPs

Proposal Version: 1.0

Date: 16 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.