[arin-ppml] Updates to draft policy 2010-13
Owen DeLong
owen at delong.com
Sun Sep 19 19:26:47 EDT 2010
On Sep 19, 2010, at 1:56 PM, Alexander, Daniel wrote:
>
> What was the problem we set out to fix here? I went back and looked at the rationale from the original draft of this proposal. The goal was to prevent potential abuse of the current section 4.10 because of possibly vague language. If this was possible, an organization could obtain up to a /24 from the /10, once every six months. This could cause the /10 to become depleted in as soon as 2.5-3.0 years, or sometime in 2014.
I'm not sure how you arrived at your figures or your understanding of the original
goal. The original goal was to create criteria under which space from 4.10 could
actually get issued by ARIN based on feedback from staff that the original
policy didn't really given them sufficient guidance.
How we got here was an effort to achieve a rational compromise between the
goals of 4.10 and the needs of several other segments of the community in
order to broaden support for the proposal.
>
> Can someone help me understand how we got from the current policy of reserving a /10 for translation technologies and DNS servers to the current proposal text? Rather than closing possible loopholes, we would delete the current policy. We would tie up the last /8. Define what are acceptable architectures for an organization. And put ARIN in the business of short term allocation “loans” that it would have to figure out how to validate, administer, and recall.
>
I don't think you are making a valid characterization of the current proposal text.
Yes, the new proposal ties up the entire /8.
It does not define what are acceptable architectures for any organization. It merely
places tighter restrictions on address space from that last /8 in order to facilitate
and encourage IPv6 deployment.
I have no idea what you mean by short term allocation "loans". I don't see any
part of the policy that fits that description, so, I'd like to request some clarification
there as to what, specifically, you are referring to.
> I fail to see how 2010-13 improves section 4.10 and I currently do not support this proposal.
>
Please re-evaluate this based on text that will be distributed tonight.
There are a number of changes and I think the newer text is be
far better.
Owen
> Dan Alexander
> ARIN AC
>
>
> On 9/14/10 8:46 PM, "Owen DeLong" <owen at delong.com> wrote:
>
>> Based on additional community feedback, 2010-13 has again been revised. Here is an updated version:
>>
>>
>> Here is the updated text:
>>
>> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10
>> Proposal Originator: Owen DeLong
>> Proposal Version: 1.38
>> Date: 5 September 2010
>> Proposal type: modify
>> Policy term: permanent
>> Policy statement:
>>
>> Rename section 4.10: "IPv4 Transition Pool Post IANA Regular Pool Depletion"
>>
>> Replace the text of section 4.10 in it's entirety with:
>>
>> 4.10 When ARIN receives its /8 IPv4 allocation from IANA under the
>> global policy titled "Global Policy for the Allocation of the
>> Remaining IPv4 Address Space" ratified by ICANN Board
>> on 6 March, 2009, that /8 will form a dedicated pool to
>> facilitate IPv6 Deployment.
>>
>> Subsequently, all IPv4 addresses received by ARIN regardless of
>> source, except addresses to be reissued under a section 8.3
>> directed transfer, will be added to this pool.
>>
>> 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
>> + NAT-PT
>> + IVI
>> + NAT464 translators
>>
>> ARIN staff will use their discretion in determining whether a particular
>> application is meets the spirit of this policy.
>>
>> 4.10.1 Reservation
>>
>> All space assigned or allocated under this policy will be reserved
>> in advance for a maximum period of 36 months, requests for shorter
>> reservations will be accepted. The total reservation size will be
>> rounded up to a CIDR bit boundary.
>>
>> Each organization's reserved IPv4 space will be divided into one
>> portion per quarter. If a shorter reservation is requested such
>> that a quarterly allotment does not match a CIDR boundary, then
>> each quarter's allotment except the last quarter shall be
>> increased as needed to align on a CIDR bit boundary. The final
>> quarter will receive only the space remaining in the full
>> reservation.
>>
>> An org may request one reservation in a 36 month period under
>> each provision listed in section 4.10.4.
>>
>> 4.10.2 Addressing Plan
>>
>> Any organization wishing to recieve IPv4 addresses through this
>> policy must submit a detailed addressing plan for each request
>> made containing the following:
>> (a) Their addressing needs over the entire reservation period and
>> (b) Methods of meeting all requisite requirements (requirments are
>> explained in section 4.10.4.) over the entire reservation
>> period.
>>
>> If the submitted plan is accepted by ARIN staff as being in
>> compliance with section 4.10.4, a reservation will be established
>> and the first quarterly allotment of the organization's
>> reservation will be assigned.
>>
>> 4.10.3 Quarterly Obligations
>>
>> Once a reservation has been made by ARIN, the organization holding
>> that reservation may request one additional portion of their reserved
>> block each quarter until their reservation is exhausted or revoked.
>>
>> For purposes of this computation, space received under each
>> provision shall be considered separately if an organization has
>> received resources through multiple provisions.
>>
>> In order to recieve each additional portion, the organization must
>> submit proof that:
>> (a) The most recent 4.10 allocation/assignment is at
>> least 80% utilized.
>> (b) All utilization is permitted under the 4.10.4 category for
>> which it was initially requested.
>> (c) ll prior 4.10 allocation/assignments within the same 4.10.4
>> category are at least 90% utilized.
>>
>> Organizations must meet all obligations as above each quarter. An
>> organization that fails only on utilization do to unanticipated
>> address conservation shall not be penalized, but, such organization
>> shall not receive an additional quarterly allotment until all
>> obligations are met. An organization which does not receive a
>> quarterly allotment for three consecutive quarters shall forfeit
>> the remainder of their reservation and may reapply.
>>
>> If an organization does not meet all obligations in any given
>> quarter, that organization shall have their reservation reduced by
>> one quarterly allotment which shall be returned to the transition
>> pool.
>>
>> If an organization does not meet all obligations for three
>> consecutive quarters, that organization forfeits the remainder
>> of their reserved block.
>>
>> If an organization is using space received under 4.10 in a manner
>> contrary to 4.10 et seq. that organization forfeits their remaining
>> reservation and may have their entire allocation or assignment
>> revoked.
>>
>> All 4.10. space forfeited, revoked or otherwise reclaimed shall
>> be returned to the ARIN transition pool and shall be exempt
>> from any requirement to return space to the IANA.
>>
>> 4.10.4 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 per quarter 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 site 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 /23 per quarter
>> 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 IPv6 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 /29 and no larger than a /25 per quarter for
>> purposes relevant to their ability to deploy IPv6.
>> 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. IVI
>> e. DNS64 or other transitional DNS enablers
>> f. For other technologies of similar purpose
>> and scope.
>>
>> 3. A /10 from the final /8 shall be reserved for issuance
>> under this provision. In no case shall any addresses
>> from this /10 be issued for any purpose outside
>> of 4.10.4(c).
>>
>> (d) 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.
>>
>> (e) A content distribution network providing SSL terminations for
>> SSL application or content acceleration may receive space
>> under the following conditions:
>> 1. No organization shall receive more than an
>> aggregate /20 under this provision.
>> 2. For each /32 issued under this provision, there
>> must be at least 8 unique SSL named terminations
>> converted to dual stack. (A unique named termination
>> is one in which the certificate DistinguishedName
>> and/or SubjectAltName is unique as well as the IP
>> address terminating the connection). An organization
>> which can show that they have dual stacked 100% of
>> their SSL terminations shall be exempted from this
>> requirement.
>> 3. The total space issued under this provision shall
>> not exceed an aggregate /11 or equivalent.
>>
>> _______________________________________________
>> 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.
>>
> _______________________________________________
> 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/20100919/c91821cd/attachment.htm>
More information about the ARIN-PPML
mailing list