[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.html>


More information about the ARIN-PPML mailing list