[arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8

Owen DeLong owen at delong.com
Tue Nov 16 09:09:53 EST 2010 

 Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
   1. Policy Proposal Name: Sensible IPv6 Allocation for ISPs
   2. Proposal Originators
         1. name: Owen DeLong
         2. e-mail: owen at delong.com
         3. telephone: 408-890-7992
         4. organization: Hurricane Electric
         1. name: David Farmer
         2. e-mail: farmer at umn.edu
         3. telephone: 612-812-9952
         4. organization: University of Minnesota
         1. name: Andrew Dul
         2. e-mail: andrew.dul at quark.net
         3. telephone: 206-395-4004
         4. organization: Cascadeo Corp.
         1. name: Chris Grundemann
         2. e-mail: christopher.grundemann at twtelecom.com
         3. telephone: 303.542.6524
         4. organization: TW Telecom
   3. Proposal Version: 0.8
   4. Date: 16 November, 2010
   5. Proposal type: M
   6. Policy term: Permanent
   7. 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 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 (a number 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.
	(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.

   8. Rationale:
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.
Sizing table:
Units		Round-up	Bits
0-11		16		4
13-191		256		8
192-3,071	4,096		12
3,072-49,151	65,536		16
49,152-786,431	1,048,576	20
   9. Timetable for implementation: Immediate
END OF TEMPLATE 







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101116/70b4cb85/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IPv6 Allocation Sizer.xls
Type: application/vnd.ms-excel
Size: 17408 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101116/70b4cb85/attachment.xls>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101116/70b4cb85/attachment-0001.htm>

More information about the ARIN-PPML mailing list