Draft Policy 2010-13: Permitted Uses of space reserved under NRPM 4.10 [Archived]

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.

Status: Abandoned

Tracking Information

Discussion Tracking

Mailing List:

Formal introduction on PPML on 4 August 2010

Origin - Policy Proposal 116

Draft Policy - 4 August 2010

Revised - 23 September 2010

Staff assessment - 27 September 2010

Abandoned by the AC - 13 October 2010

Public Policy Mailing List

ARIN Public Policy Meeting:

ARIN XXVI

ARIN Advisory Council:

Shepherds: Scott Leibrand
and Bill Sandiford

ARIN Board of Trustees:

Revisions:

Previous version(s)

Implementation:

Draft Policy 2010-13
Permitted Uses of space reserved under NRPM 4.10

Version/Date: 23 September 2010 (ver. 1.55)

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.

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

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

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.