[arin-ppml] Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.kng Proposal Version: 1.m
Stacy Hughes
ipgoddess.arin at gmail.com
Tue Aug 31 08:49:13 EDT 2010
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/20100831/4b458c36/attachment.htm>
More information about the ARIN-PPML
mailing list