[arin-ppml] Updated 121 to address staff comments

[Owen DeLong]

Modified sections 2.12, 2.13, and 2.14 to clarify that these definitions apply
only to IPv6 policies.

(The term -> When applied to IPv6 policies, the term)

Added some line spacing for better readability in several areas.

Modified Section 6.5.2.2(b) to clarify the logic. It now reads:

	(b) Are currently multihomed or will immediately become
		multihomed for IPv6 using a valid assigned global
		AS number.

		In either case, they will be making reassignments
		from allcation(s) under this policy to other organizations.

Staff had commented about the section mixing tenses. I believe
that is intentional in the first sentence and that the future tense
remaining in the second sentence is necessary. I suspect that
this comment may have been a result of misinterpretation of
the relationship between the and and or clauses in the
prior version.

Modified Section 6.5.2.2(c) for grammar and punctuation.
It now reads:

	(c) Provide ARIN a reasonable technical justification
		indicating why an allocation is necessary. Justification
		must include the intended purposes for the allocation
		and describe the network infrastructure the allocation
		will be used to support. Justification must also include
		a plan detailing anticipated assignments to other
		organizations or customers for one two and five
		year periods, with a minimum of 50 assignments
		within 5 years.

Added the following clarification at the bottom of the rationale
section (above the sizing table):

	Clarifications in response to Staff and Legal Assessment

	In the Proposal Summary (Staff Understanding) staff states
	"This policy will lower the current minimum allocation size
	from a /32 to a /36 as it allows ISPs to request a /36". It should
	be noted that this policy still allows any ISP to receive at
	least a /32. However, the /36 is provided as an option
	specifically to allow very small ISPs currently in the x-small
	IPv4 fee category a reduced option. It is the intent that by
	allowing this, the board may reconsider the IPv6 ISP fee
	table and allow these particularly small organizations to
	obtain IPv6 without increasing their annual subscription
	fees from ARIN. Since fees are not a policy matter, the
	fee request must be considered elsewhere, but, the
	enabling policy language contained in this policy is a
	precursor to that discussion.

	The author has submitted a request that the board
	make the fee change to the IPv6 fee table through the
	ACSP.

Here is the revised policy in its entirety:

Policy Proposal: Better IPv6 Allocations for ISPs

Version/Date: 30 January, 2011

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 When applied to IPv6 policies, 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 When applied to IPv6 policies, 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 when applied to IPv6
			policies:

			(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.

			In either case, they will be making reassignments
			from allocation(s) under this policy to other organizations.

		(c)	Provide ARIN a reasonable technical justification
			indicating why an allocation is necessary. Justification
			must include the intended purposes for the allocation and
			describe the network infrastructure the allocation will be used to
			support. Justification must also include a plan detailing anticipated
			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.


</pre> 
== Rationale:  ==
<pre>The current ISP policy for IPv6 allocations is both short-sighted and
insufficient for rational deployments by most ISPs. We have gained
significant operational experience with IPv6 in the time since it was
written and it is clear that current policy is driving many ISPs to choices
of excess conservatism that will eventually harm innovation in the
consumer space.

Under the proposed policy, the entirety of the ARIN region can still
be numbered in no more than 2 /12s (quite probably 1). There are
still 506 /12s free within the current /3. It is unreasonable to shoot
ourselves in the foot with address scarcity thinking so early into the
IPv6 deployment. This policy seeks to strike a more reasonable and
harmonious balance of the goals stated in NRPM 6.3.

The lower bound of /36 is intended to facilitate extremely small
ISPs getting a smaller block if they do not need to support more
than ~4000 customers. It is hoped that the board will take
subsequent action to adjust the fee structure to eliminate
the $1,000/year price hike for those extremely small ISPs. These
ISPs can, of course, get a /32 if they wish.

The intent of section 6.5.4 is to create and preserve parity between
the requirements for LIR->End User and ARIN->End User policies.
This section presumes that 6.5.8 has already been modified as
described in draft policy 2010-8.

Some examples of determining the size of block for which an
organization is eligible:

Bill's Bait, Sushi, and IP Transit:
	Largest serving site:		200 end sites
	Number of serving sites:	5
	200 rounds up to 256 (nibble boundary, 8 bits). 200 > 192 (256 * 0.75), so, round up to 4096 (12 bits)
	5 rounds up to 16 (nibble boundary, 4 bits). 5 < 12 (16 * 0.75), so, no further round up. 16 (4 bits)
	48 - (12+4) = 32 -- This organization could receive up to a /32.
Lee's Rural Internet, Inc.
	Largest serving site:		1024 end sites
	Number of serving sites:	30
	1024 rounds up to 4096 (nibble boundary, 12 bits) 1024 < 3072 (4096 * 0.75), so 4096 (12 bits)
	30 rounds up to 256 (nibble boundary, 8 bits). 30 < 192 (256 * 0.75), so, 256 (8 bits)
	48 - (12+8) = 28 -- This organization could receive up to a /28.
Paul's Mega Metro ISP, LLC
	Largest serving site:		3,500 end sites
	Number of serving sites:	140
	3,500 rounds up to 4096 (nibble boundary, 12 bits). 3500 > 3072 (4096 * 0.75), so, round up to 65,536 (16 bits)
	140 rounds up to 256 (nibble boundary, 8 bits) 140 < 192 (256 * 0.75), so, 256 (8 bits)
	48 - (16+8) = 24 -- This organization could receive up to a /24
PON's CMTS mega DSL Corp.
	Largest serving site:		30,000 end sites
	Number of serving sites:	700
	30,000 rounds up to 65,536 (nibble boundary, 16 bits). 30,000 < 49,152 (65536 * 0.75), so, 65,536 (16 bits)
	700 rounds up to 4,096 (nibble boundary, 12 bits). 700 < 3072 (4096 * 0.75), so, 4,096 (12 bits)
	48 - (16+12) = 20 -- This organization could receive up to a /20.

Clarifications in response to Staff and Legal Assessment

In the Proposal Summary (Staff understanding) staff states "This policy will lower the current minimum allocation
size from a /32 to a /36 as it allows ISPs to request a /36". It should be noted that this policy still allows any ISP
to receive at least a /32. However, the /36 is provided as an option specifically to allow very small ISPs currently
in the x-small IPv4 category a reduced option. It is the intent that by allowing this, the board may reconsider the
minimum IPv6 ISP fee table and allow these particularly small organizations to obtain IPv6 without increasing their
annual subscription fees from ARIN. Since Fees are not a policy matter, the fee request must be considered
elsewhere, but, the enabling policy language contained in this policy is a precursor to that discussion. The author
has submitted a request that the board consider this fee structure through the ACSP.

Owen