[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.htm>
More information about the ARIN-PPML
mailing list