Final draft of 2010-13 for Atlanta (Rev 1.55)

[ARIN]

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

Attached is the ARIN staff assessment of 2010-13. We assessed the 1.53
version of the draft policy (it's currently at 1.55). It is noted that
the time frame for reserves has been reduced from 36 to 24 months in
version 1.55.

This draft policy is open for discussion on this mailing list and will
be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta.

2010-13 is below and available at:
https://www.arin.net/policy/proposals/2010_13.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Staff Assessment of Draft Policy 2010-13 (version 1.53 dated 19
September 2010)

Permitted Uses of space reserved under NRPM 4.10

1. Proposal Summary (Staff Understanding)

This policy modifies the existing NRPM policy 4.10 (“Dedicated IPv4
block to facilitate IPv6 Deployment”).  It sets aside in its entirety
the last /8 ARIN receives from the IANA for issuance to networks
transitioning to a dual IPv4/IPv6 network rather than the /10 currently
cited in NRPM 4.10. Any IPv4 address space returned to ARIN (and not
subject to a global or regional transfer policy) will be added to this
transition pool.  Under this policy there are four major classes of
requestors:

   - ISPs can apply for /32s for customers as long as each customer
meets the policy's detailed qualification criteria.

   - Any operator can apply for /32s for issuing to devices used to
serve-up internet facing content, within the constraints of the defined
qualifying criteria.

   - From the /8, a /10 will be set aside so that any operator can
request space for use in infrastructure numbering for the purposes of
deploying IPv6. Space can be issued from this /8 for applicants who
qualify under ARIN's Micro-allocation Policy (with additional
restrictions).

   - Finally, space can be issued from this /8 for applicants who
operate content distribution networks, again, within the context of the
policy's qualifying criteria.

Organizations can request address space to meet their 3-year needs.
Space is allocated/assigned in quarterly installments.  After the first
quarter, the requestor can only return to ARIN if they have utilized 80%
of the most recent assignment, and 90% of past assignments (issued under
this policy). The organization must have also assigned all IP addresses
issued under the policy to uses that are acceptable under the policy.
If the organization fails to meet the utilization criteria for four
consecutive quarters, then the policy directs ARIN staff to reduce the
amount of space reserved.

2. Comments

  A.	ARIN Staff Comments

   • The policy text has become very complex and complicated and the
general community will have a very hard time understanding the concepts
and criteria proposed within the policy.

   • It seems to be out of order – it starts out with reservations
before ever mentioning the initial qualifying criteria.  The author
might want to consider re-ordering to start with the essential
qualification criteria first.

   • Section 4.10.2 suggests that all allocations made under this policy
will initially be made from a 3-year reservation.  In light of the
imminent depletion of IPv4 address space, it doesn't seem fair to allow
some organizations to retain/reserve this valuable resource for up to 3
years while others will be denied.

   • The policy text in (in 4.10.3) appears to contradict itself, as it
first directs staff to remove one quarter's worth of reservation, and
then, if the organization continues this practice for three consecutive
quarters, remove the organization's reserves completely. Later, it
explicitly directs staff to revoke addresses issued under this policy
that are used by the organizations for purposes not permitted under this
policy.

   • This proposal will essentially supplant the recently ratified
policy "Waiting List for Unmet Resources". That list will consist of
people waiting for resources to be returned or revoked so that ARIN can
then reissue them to requestors in need of IPv4 address space.  This
proposal says that any IPv4 address space that comes back to ARIN
immediately goes into the IPv6 transition pool and can only be used for
that purpose.

   • Under 4.10.4.B5, how would staff be able to verify that x percent
of an organization’s content is IPv6 reachable?


  B. ARIN General Counsel
This policy is unlikely to cause any legal issues of any importance.


3. Resource Impact

This policy would have moderate to major resource impact.  It is
estimated that implementation would occur within 6 to 9 months after
ratification by the ARIN Board of Trustees. The following would be
needed in order to implement:
   • Changes to the way ARIN manages reverse DNS (to handle in-addr.arpa
delegations for blocks smaller than /24)
   • Updated guidelines
   • Staff training


> -----Original Message-----

> From: Owen DeLong [mailto:owen at delong.com]

> Sent: Thursday, September 23, 2010 7:26 PM

> To: arin-ppml at arin.net List; policy

> Subject: Final draft of 2010-13 for Atlanta (Rev 1.55)

>

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