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

[ARIN]

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

Draft Policy 2010-13 comes from the successful petition of "Policy
Proposal 116: Permitted Uses of space reserved under NRPM 4.10." The
draft policy is being posted for adoption discussion on the PPML and at
the Public Policy Meeting in October. The text of this draft policy is
under the control of the petitioner, Owen DeLong, until the conclusion
of the Public Policy Meeting.

Draft Policy 2010-13 is below and can be found at:
https://www.arin.net/policy/proposals/2010_13.html

You are encouraged to discuss Draft Policy 2010-13 on the PPML prior to
the Public Policy Meeting. Both the discussion on the list and at the
meeting will be used by the ARIN Advisory Council to determine the
community consensus for adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


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

Version/Date: 4 August 2010

Policy statement:

Amend section 4.10 replacing "...a contiguous /10 IPv4 block..." with
"...that /8..." and replacing "...within that /10 block." with "within
this /8."

Add the following to section 4.10 of the NRPM

6. Under this policy, applications must be for one of two types of
transitional uses, declared at time of application.
   (a) An ISP/LIR may request a block not less than a /24 nor more than
a /18 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 ARIN received this reserved block from IANA.
    1. No customer 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 space with native IPv6 connectivity
to the ISP/LIR and must be making use of IPv6 within their network.
    6. The total of all allocations by ARIN under this provision shall
not be allowed to consume more than 3/4 of the /8 (the equivalent of a
/9 + a /10).
    7. No organization shall receive more than a total of a /16 or
equivalent under this section.

or (b) An ISP/LIR or End user organization may request not less than a
/28 and not more than a /24 for purposes relevant to their ability
to deploy IPv6 as specified in section 4.12.
    1. No organization shall receive more than a total of a /20 or
equivalent under this section.
    2. Space issued under this policy is an assignment, not an
allocation. An LIR may not distribute this space to their customers.

7. For purposes of section 4.10.1, separate times shall be considered
for 4.10.6(a) vs. 4.10.6(b). An organization may make applications for
both types within 6 months.

8. Other than transfers under NRPM section 8, all space returned to ARIN
after IANA depletion shall either be returned to IANA or shall be added
to the reserved pool created by 4.10.1.

Add the following to section 4 of the NRPM

4.11 Required utilization for subsequent allocation under section 4.10

No organization shall receive more than one allocation or assignment
under section 4.10 unless all prior space issued under 4.10 meets the
utilization requirements of this section:

1. The most recent 4.10 allocation/assignment must be at least 80% utilized.
2. All utilization must be permitted under section 4.12
3. All prior 4.10 allocation/assignments must be at least 90% utilized.
4. For purposes of this computation, space received under 4.10(a) shall
be considered separately from space received under 4.10(b) if an
organization has received resources of both types.

4.12 Permitted uses of allocations or assignments under section 4.10(b)

No organization shall use space received under section 4.10 for any
purpose other than as specified in this section

1. To provide the required public IPv4 address(es) for transitional
technologies operated by the recipient organization.
a. Large scale or "Carrier Grade" NAT
b. NAT-PT
c. DS-LITE/B4/AFTeR
d. DNS64 or other transitional DNS enablers
e. For other technologies of similar purpose and scope.

2. For other transitional technologies not envisioned at the time of
this proposal, but, in no case for general IPv4 addressing provided to
customers.

4.13 Quarterly Utilization Monitoring

Allocations and assignments under section 4.10 shall be subject to
quarterly verification of utilization.

1. An organization which is not meeting their utilization targets may
have their allocation or assignment reduced accordingly with the
reclaimed portions going back to ARIN for distribution to other
organizations. Space reclaimed in this manner shall be exempt from any
requirement to return space to the IANA.
2. An organization which is using space received under 4.10 in a manner
contrary to 4.10 et seq. may have their allocation or assignment reduced
or revoked with reclaimed portions going back to ARIN for distribution
to other organizations. Space reclaimed in this manner shall be exempt
from any requirement to return space to the IANA.

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.

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.