[arin-ppml] Updates to draft policy 2010-13

[Owen DeLong]

Based on additional community feedback, 2010-13 has again been revised. Here is an updated version:


Here is the updated text:

Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10
Proposal Originator: Owen DeLong 
Proposal Version: 1.38
Date: 5 September 2010
Proposal type: modify
Policy term: permanent
Policy statement:

Rename section 4.10: "IPv4 Transition Pool Post IANA Regular Pool Depletion"

Replace the text of section 4.10 in it's entirety with:

4.10	When ARIN receives its /8 IPv4 allocation from IANA under the
	global policy titled "Global Policy for the Allocation of the
	Remaining IPv4 Address Space" ratified by ICANN Board
	on 6 March, 2009, that /8 will form a dedicated pool to
	facilitate IPv6 Deployment.

	Subsequently, all IPv4 addresses received by ARIN regardless of
	source, except addresses to be reissued under a section 8.3
	directed transfer, will be added to this pool.

	Allocations and assignments from this block must be justified by
	immediate IPv6 deployment requirements. 

	Examples of such needs include:
	+	IPv4 addresses for key dual stack DNS servers
	+	NAT-PT
	+	IVI
	+	NAT464 translators

	ARIN staff will use their discretion in determining whether a particular
	application is meets the spirit of this policy.

	4.10.1	Reservation

	All space assigned or allocated under this policy will be reserved
	in advance for a maximum period of 36 months, requests for shorter
	reservations will be accepted. The total reservation size will be
	rounded up to a CIDR bit boundary.

	Each organization's reserved IPv4 space will be divided into one 
	portion per quarter. If a shorter reservation is requested such
	that a quarterly allotment does not match a CIDR boundary, then
	each quarter's allotment except the last quarter shall be
	increased as needed to align on a CIDR bit boundary. The final
	quarter will receive only the space remaining in the full
	reservation.

	An org may request one reservation in a 36 month period under
	each provision listed in section 4.10.4.

	4.10.2	Addressing Plan

	Any organization wishing to recieve IPv4 addresses through this
	policy must submit a detailed addressing plan for each request
	made containing the following:
	(a)	Their addressing needs over the entire reservation period and 
	(b)	Methods of meeting all requisite requirements (requirments are 
		explained in section 4.10.4.) over the entire reservation
		period. 

	If the submitted plan is accepted by ARIN staff as being in
	compliance with section 4.10.4, a reservation will be established
	and the first quarterly allotment of the organization's
	reservation will be assigned.

	4.10.3	Quarterly Obligations

	Once a reservation has been made by ARIN, the organization holding
	that reservation may request one additional portion of their reserved
	block each quarter until their reservation is exhausted or revoked. 

	For purposes of this computation, space received under each
	provision shall be considered separately if an organization has
	received resources through multiple provisions.

	In order to recieve each additional portion, the organization must
	submit proof that:
	(a)	The most recent 4.10 allocation/assignment is at
		least 80% utilized.
	(b)	All utilization is permitted under the 4.10.4 category for
		which it was initially requested.
	(c) 	ll prior 4.10 allocation/assignments within the same 4.10.4
		category are at least 90% utilized.

	Organizations must meet all obligations as above each quarter. An
	organization that fails only on utilization do to unanticipated
	address conservation shall not be penalized, but, such organization
	shall not receive an additional quarterly allotment until all
	obligations are met. An organization which does not receive a
	quarterly allotment for three consecutive quarters shall forfeit
	the remainder of their reservation and may reapply.

	If an organization does not meet all obligations in any given
	quarter, that organization shall have their reservation reduced by
	one quarterly allotment which shall be returned to the transition
	pool.

	If an organization does not meet all obligations for three
	consecutive quarters, that organization forfeits the remainder
	of their reserved block.

	If an organization is using space received under 4.10 in a manner
	contrary to 4.10 et seq. that organization forfeits their remaining
	reservation and may have their entire allocation or assignment
	revoked.

	All 4.10. space forfeited, revoked or otherwise reclaimed shall
	be returned to the ARIN transition pool and shall be exempt
	from any requirement to return space to the IANA.

	4.10.4	Specific types of transitional uses have specific requirements:

	(a)	An ISP/LIR may request a block no smaller than a /24 nor
		larger than a /18 per quarter to be used to provide single
		IPv4 /32s to their customers which could justify a /28 or
		more of IPv4 under ARIN policies in effect at the time of
		IANA depletion.
		1.	No customer site may receive more than a single
			IPv4 /32 under this provision.
		2. 	The customer must not have any other IPv4
			allocations or assignments from the provider at
			the time of this assignment.
		3.	The customer must not have any direct assignments
			from ARIN at the time of this assignment.
		4.	The customer must not have more than a single
			IPv4 /32 from any other provider at the time of
			this assignment.
		5.	The customer must have IPv6 addresses with IPv6
			connectivity to the ISP/LIR (must be dual-stacked).
		6.	The ISP/LIR must demonstrate that it already
			provides IPv6 addressing and connectivity to at
			least one existing customer for each /32 requested,
			up to 90% of their total customer base.
		7.	No organization shall receive more than a total
			of a /14 or equivalent under this section. 

	(b)	An ISP/LIR or End user organization may request a block
		no smaller than a /28 and no larger than a /23 per quarter
		to provide single IPv4 /32s to each physical server used
		to provide Internet reachable content.
		1.	Space issued under this provision is an assignment,
			not an allocation. An LIR may not distribute this
			space to their customers.
		2.	No server may recieve more than a single IPv4 /32
			under this provision.
		3.	The server must have IPv6 addresses with IPv6
			connectivity (must be dual-stacked).
		4.	The recieving organization must demonstrate that it
			already provides IPv6 addressing and connectivity
			to at least one existing server in addition to the
			server for which each /32 is requested, up to 100%
			of their total server base.  (organizations which
			can show 100% dual stack are exempt from this
			requirement).
		5.	The recieving organization must IPv6 enable all of
			their content on the following schedule:

			+	25% of content IPv6 reachable within six
				months of receiving their first addresses
				under this policy
			+	50% of content IPv6 reachable within one year
				of receiving their first addresses under this
				policy
			+	75% of content IPv6 reachable within 18 months
				of receiving their first addresses under this
				policy
			+	90% of content IPv6 reachable within 24 months
				of receiving their first addresses under this
				policy

		6.	No organization shall receive more than a total of
			a /16 or equivalent under this section.

	(c)	An ISP/LIR or End user organization may request a block no
		smaller than a /29 and no larger than a /25 per quarter for
		purposes relevant to their ability to deploy IPv6.
		1.	Space issued under this provision is an assignment,
			not an allocation. An LIR may not distribute this
			space to their customers.
		2.	Space issued under this provision must be used to
			provide the required public IPv4 address(es) for
			transitional technologies operated by the recipient
			organization. 

			Specific examples of permitted uses are:
			a.	Large scale or "Carrier Grade" NAT
			b.	NAT-PT
			c.	DS-LITE/B4/AFTeR
			d.	IVI
			e.	DNS64 or other transitional DNS enablers
			f.	For other technologies of similar purpose
				and scope.

		3.	A /10 from the final /8 shall be reserved for issuance
			under this provision. In no case shall any addresses
			from this /10 be issued for any purpose outside
			of 4.10.4(c).

	(d)	Applications which would qualify for IPv4 under section 4.4 of
		the NRPM (critical infrastructure) may qualify for IPv4 space
		under this policy if they meet the following criteria:
		1.	The critical infrastructure to be numbered must also
			have IPv6 addresses and must provide all services
			provided on IPv4 over IPv6 on the same time table.
		2.	Assignments under this provision shall be the
			smallest technically feasible size for the critical
			infrastructure in question.
		3.	The total space assigned under this provision shall not
			exceed the equivalent of a /14.

	(e)	A content distribution network providing SSL terminations for
		SSL application or content acceleration may receive space
		under the following conditions:
		1.	No organization shall receive more than an
			aggregate /20 under this provision.
		2.	For each /32 issued under this provision, there
			must be at least 8 unique SSL named terminations
			converted to dual stack. (A unique named termination
			is one in which the certificate DistinguishedName
			and/or SubjectAltName is unique as well as the IP
			address terminating the connection). An organization
			which can show that they have dual stacked 100% of
			their SSL terminations shall be exempted from this
			requirement.
		3.	The total space issued under this provision shall
			not exceed an aggregate /11 or equivalent.