[arin-ppml] Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.kng Proposal Version: 1.m

Owen DeLong owen at delong.com
Tue Aug 31 17:34:39 EDT 2010


I believe the /10 was adequate for the ORIGINAL stated purpose of the proposal. I believe that with the expanded scope being demanded by a number of members of the community that a /8 may actually come up short.

Owen

Sent from my iPad

On Aug 31, 2010, at 10:49 PM, Stacy Hughes <ipgoddess.arin at gmail.com> wrote:

> I believe this is misuse of a whole /8, and that the /10 already designated for this purpose is sufficient.
> Stacy
> 
> 
> -- 
> 
> Stacy Hughes 
> +1-831-676-5166
> Sent from my iPad, please forgive typos 
> 
> On Aug 20, 2010, at 16:12, Owen DeLong <owen at delong.com> wrote:
> 
>> 2010-13 has been revised to accommodate this as follows:
>> 
>> Specifically, I refer you to 4.10.6(f) below...
>> 
>> 
>> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.kng 
>> Proposal Version: 1.m
>> 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).
>> 
>>     (f) 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.
>> 
>> 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.
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100901/4c84c2dc/attachment.html>


More information about the ARIN-PPML mailing list