[arin-ppml] Correction to 2010-13

Owen DeLong owen at delong.com
Thu Aug 19 08:47:12 EDT 2010


The version sent out a few minutes ago contained an edit which was misapplied.

4.10.6(a) should be limited to /14.
4.10.6(b) should be limited to /16.

The corrected text appears below:

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

Rename section 4.10: "Dedicated IPv4 pool to facilitate IPv6 Deployment"
Amend section 4.10 replacing
        "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."
with
        "When ARIN receives its last /8 IPv4 allocation from IANA, that
        /8 will form a dedicated pool to facilitate IPv6 Deployment."

and replacing
        "...when possible within that /10 block."
with
        "...when possible within this pool, particularly within the last
        /8 block. Following IANA depletion, all IPv4 address space returned
        directly to ARIN except space to be reissued under an 8.3 directed
        transfer will be added to this pool." .

and Strike
        "This block will be subject to a minimum size allocation of /28
        and a maximum size allocation of /24." from section 4.10.

Amend 4.10.1 replacing
        "...under this policy in the preceding..."
with
        "...under each provision of this policy (as detailed in
        section 4.10.6) in the preceding..."

Add the following to section 4.10 of the NRPM

6. 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 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 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 /22 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 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 /28 and no larger than a /24 for purposes relevant to their
       ability to deploy IPv6 as specified in section 4.12.
       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. DNS64 or other transitional DNS enablers
          e. For other technologies of similar purpose and scope.

   (d) An ISP/LIR or End user organization may request a block no smaller
       than a /28 and no larger than a /24 for other transitional
       technologies not envisioned at the time of this proposal, but,
       in no case for general IPv4 addressing provided to customers.
   (e) A /10 from the final /8 shall be reserved for issuance under
       4.10.6(c) and 4.10.6(d). In no case shall any addresses from
       this /10 be issued under 4.10.6(a) and 4.10.6(b).

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.10
     3. All prior 4.10 allocation/assignments must be at least 90% utilized.
     4. For purposes of this computation, space received under each
        provision shall be considered separately if an organization has
        received resources through multiple provisions.

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

It also expands the scope of 4.10 to include more address space to be
given out in manners that facilitate transition, but, are not directly
transitional technologies per se. These allocatios and assignments
require specific IPv6 deployment targets to be met and have much
stricter limitations on the utilization of IPv4 addresses issued
from this pool.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100819/818eb83a/attachment.html>


More information about the ARIN-PPML mailing list