[arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)

[Owen DeLong]

Changes:

1.	Set maximum reservation period to 24 months. This avoids creating
	a 4-year reservation by CIDR-rounding 36 month reservations.
2.	Reduced minimum size for 4.10.4(b) to /28

These changes will make the policy more balanced and reduce the extent to
which larger organizations could be disadvantaged relative to smaller
smaller organizations if reservations have to be resized.

The change to a 2-year system resolves an issue with the CIDR-Rounding
where a 36-month reservation is mathematically guaranteed to become a
48-month reservation. The other alternative was to round-down instead of
up which would have mathematically converted all reservations to 2 years.
As such, a 2-year reservation system seemed the cleanest and most
straightforward approach.

Owen

Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10
Proposal Originator: Owen DeLong, Chris Grundemann
Proposal Version: 1.55
Date: 23 September 2010
Proposal type: modify
Policy term: permanent
Policy statement:

Remove section 4.1.8 (Unmet requests) from the NRPM.
Replace the text of section 4.10 in its entirety (including the name) with:

4.10	IPv4 Transition Pool Post IANA Regular Pool Depletion

	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.

	Addresses returned to ARIN and not subject to a regional or
	global transfer policy will be reserved for utilization in the transition
	pool.

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

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

	4.10.1	Addressing Plan

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

	4.10.2 Reservation System

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

	Each organization's reservation amount will be divided
	into quarterly allotments. Allotments will be rounded up
	to a CIDR bit boundary. The final quarterly allotment will 
	contain only the remaining space from the full reservation.

	An organization may request one reservation under each provision 
	listed in section 4.10.4. Once a reservation has been satisfied,
	another may be requested.

	4.10.2.1 Reservation Requests Prior to Initial ARIN Free Pool Depletion

	Reservations will be accepted from the time that this policy
	is adopted until the day that ARIN can no longer fill regular requests from
	space allocated to ARIN by IANA. At that time, if necessary, all reservations 
	will be reduced by an equal amount to allow them to fit within
	the total space available in the transition pool. No reservation 
	will be reduced lower than the minimum quarterly allotment for 
	it's category. Each organization may decide whether to adjust 
	the reservation period or the allotment size (within the stated 
	range) when reservations are reduced. Organizations must make
	this decision within 30 days of announcement and may not alter
	their choice once made. Any space added to the transition
	pool during this time will cause a final recalculation of
	reservation sizes. Once all necessary adjustments are
	made, all reservations are guaranteed and the first quarterly
	allotment is issued to each org.

	4.10.2.2 Reservation Requests Post ARIN Free Pool Depletion

	Reservation requests received after ARIN free pool depletion
	as defined in 4.10.2.1 will not be guaranteed. If approved, such 
	requests will be placed in a queue. As space becomes available in 
	the transition pool it will be used to provide allotments to 
	organizations with reservations in the queue on a first-approved 
	first-served basis. Partially filled allotments will remain at the
	front of the queue.

	4.10.2.3 Abandonment of Reservation

	Any organization may abandon their remaining reservation at any
	time by informing ARIN of their desire to do so. Upon abandonment,
	the remaining space in the reservation will be returned to the
	transition pool.

	4.10.3 Quarterly Requirements

	Organizations with approved reservations and address plans
	are entitled to quarterly allotments. In order to receive each 
	additional allotment, an organization must submit evidence of 
	compliance with the following sub-sections:
	(a)	The most recent 4.10 allotment is at least 80% utilized.
	(b) 	All prior 4.10 allotments within the same 4.10.4
		category are at least 90% utilized.
	(c)	All utilization is permitted under the 4.10.4 category for
		which it was initially requested.

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

	If an organization does not meet all obligations in any given
	quarter, that organization shall not receive that quarter's allotment
	and shall have their reservation reduced by one quarterly allotment.
	If an organization does not meet all obligations
	for three consecutive quarters, that organization forfeits the remainder
	of their reserved block.

	Utilization requirements (a) may be delayed at ARIN's discretion.

	If an organization is using space received under 4.10 in a manner
	contrary to 4.10, 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.

	4.10.4	Specific types of transitional uses have specific requirements:

	(a)	An ISP/LIR may request a block no smaller than a /25 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 per 1,000 Internet connected hosts upto 8 /32s.
		2. 	The customer site must not have any IPv4
			addresses not issued under this policy.
		3.	The customer site must use the /32 to provide
			IPv4 connectivity for hosts which have IPv6
			addresses with IPv6 connectivity to the ISP/LIR.
		4.	The ISP/LIR must demonstrate that it already
			provides IPv6 addressing and connectivity to at
			least one additional existing customer site for 
			each /32 requested, up to 90% of all customer sites 
			served (across all customers).
		5.	An ISP/LIR customer which is not large enough to qualify
			under this provision and has no unassigned IPv4 addresses
			may receive an appropriate number of /32s from their 
			upstream provider for reassignment to their customers 
			under the terms of 4.10.4(a).
		6.	A customer site which terminates multiple connections
			from the same provider on separate routers may qualify
			for one /32 per unique router with a direct connection to
			the provider, up to a total of 8 /32s.
		7.	The total space issued to all organizations under
			this provision shall not exceed an aggregate /9
			or equivalent per /8 placed into the transition pool.


	(b)	An ISP/LIR or End user organization may request a block
		no smaller than a /28 and no larger than a /18 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 receive 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 receiving organization must demonstrate that it
			already provides IPv6 addressing and connectivity
			to at least one additional existing server 
			(organizations which can show 100% dual stack are 
			exempt from this requirement).
		5.	The receiving 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.	A network providing SSL terminations for applications
			or content acceleration may receive a /32 for each
			distinguished name by following all requirements in
			this provision, substituting "distinguished name" for
			"server." 
		7.	Networks using these addresses for authoritative
			DNS servers can use 2 /32s per 1,000 authoritative
			domains served up to 128 /32s total per organization.
		8.	The total space issued to all organizations under
			this provision shall not exceed an aggregate /9
			or equivalent per /8 placed into the transition pool.

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

</pre>

<pre>


Rationale:

The current terminology in section 4.10 is vague and could allow a variety of interpretations which could lead to allocations or assignments being made to ISPs intending to misuse the space for general deployment by using IPv6 overlay technologies as a "IPv6 deployments" requiring IPv4 space for transition. For example, the current policy could be interpreted to enable an ISP to require IPv4 addresses for all IPv6 customers to roll IPv6 out as 6rd to customers who would be otherwise unable to get IPv4 space. This is clearly outside of the original intent of the proposal which created 4.10 (6rd was not yet envisioned at the time that was written). This proposal seeks to clarify that intent and tighten up the requirements for organizations seeking to get space from this limited final resource so that it truly is available to facilitate transitional technologies.

Additionally, there are a number of community segments that are not well served by the original intent of 4.10 and several community members requested a mechanism for providing a certain amount of certainty with regards to obtaining space at the end. While it would be impossible to guarantee organizations all the space they need as runout is upon us, this policy seeks to provide a way for organizations to sign up for and receive a reservation from the final space proportionate to their need. The policy also includes guidelines intended to ensure that this vital community resource is given only to organizations working towards a smooth transition to IPv6 to the benefit of the full community.

In order to meet these needs, this policy has become very complex. It is an unfortunate artifact of the complex issue it seeks to address. A great deal of effort has been made to simplify the policy as much as possible, and, special thinks go out to several members of the community for their assistance in this matter.

One provision in this draft policy calls for utilization criteria which may be waived by ARIN staff discretion. The intent of this clause is to allow staff to avoid penalizing an organization for successful address conservation efforts.

Runout is upon us. IANA will run out of the IANA free pool and issue the last /8 this policy seeks to regulate before the next ARIN public policy meeting. If we are to make any attempt at fair distribution for the sake of IPv6 deployment, this is our final opportunity to do so outside of an emergency action by the ARIN board.

Timetable for implementation: immediate

For reference, here is the current text of 4.10

4.10 Dedicated IPv4 block to facilitate IPv6 Deployment

When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. 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, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications.

This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block.

In order to receive an allocation or assignment under this policy:
	1. the applicant may not have received resources under this policy in the preceding six months;
	2. previous allocations/assignments under this policy must continue to meet the justification requirements of this policy;
	3. previous allocations/assignments under this policy must meet the utilization requirements of end user assignments;
	4. the applicant must demonstrate that no other allocations or assignments will meet this need;
	5. on subsequent allocation under this policy, ARIN staff may require applicants to renumber out of previously allocated / assigned space under this policy in order to minimize non-contiguous allocations.