I cannot support 2010-13 presently because it still seems to me to be overtly complex prone to misunderstanding.<div><br></div><div>One example: >ISPs can apply for /32s for customers as long as each customer<br>> meets the policy's detailed qualification criteria. As an ISP, I may not be too happy imposing detailed qualification criteria which will be a beyond my commercial requirement and may simply frustrate and complicate the process at all levels.<br>
<div><br></div><div>Rudi Daniel</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Wed, Sep 29, 2010 at 10:33 AM, <span dir="ltr"><<a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Send ARIN-PPML mailing list submissions to <br>
<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:arin-ppml-owner@arin.net">arin-ppml-owner@arin.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of ARIN-PPML digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Final draft of 2010-13 for Atlanta (Rev 1.55)<br>
(Hannigan, Martin)<br>
2. Re: Final draft of 2010-13 for Atlanta (Rev 1.55)<br>
(Chris Grundemann)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 28 Sep 2010 17:55:37 -0400<br>
From: "Hannigan, Martin" <<a href="mailto:marty@akamai.com">marty@akamai.com</a>><br>
To: "<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>" <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)<br>
Message-ID: <<a href="mailto:C8C7DC99.11B97%25marty@akamai.com">C8C7DC99.11B97%marty@akamai.com</a>><br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
<br>
<br>
I oppose this proposal. I think it's destructive; it's complicated and fails<br>
to establish any leadership and it's divisive; the reservation system and<br>
classes of requests create significant inequities for all that have need. It<br>
fails to allow anyone to plan. The end result is that we're going to pit all<br>
of our members against each other in open markets. Regardless of this<br>
proposal, that may happen still. When I supported the petition I had hoped<br>
that we could stretch this remaining space and provide some relief and<br>
define what's important with regards to continuing to grow the net while we<br>
transition. That is impossible with this proposal and perhaps impossible<br>
with any proposal and a single /8[1]. [ The recent CableLabs Draft is very<br>
interesting FWIW]<br>
<br>
This proposal still does not go far enough in offering some level of relief<br>
to all segments of the industry. I concur with the staff comments related<br>
and specifically comments related to the complexity.<br>
<br>
I did support "the concept" of the reservation system with different terms<br>
and provider relief with respect to CPE et. Al. The proposal fails to<br>
explain itself adequately with respect to both and if it were adequately<br>
explained it may seem less unfair if it were re-written. Transition not be<br>
without pain and some of us are already challenged by it.<br>
<br>
I don't have a suggestion other than a complete rewrite which is why I<br>
support completely abandoning it.<br>
<br>
<br>
Best,<br>
<br>
-M<<br>
<br>
<br>
<br>
1. <a href="http://tools.ietf.org/html/draft-weil-opsawg-provider-address-space-00" target="_blank">http://tools.ietf.org/html/draft-weil-opsawg-provider-address-space-00</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
On 9/27/10 4:02 PM, "ARIN" <<a href="mailto:info@arin.net">info@arin.net</a>> wrote:<br>
<br>
> Draft Policy 2010-13<br>
> Permitted Uses of space reserved under NRPM 4.10<br>
><br>
> Attached is the ARIN staff assessment of 2010-13. We assessed the 1.53<br>
> version of the draft policy (it's currently at 1.55). It is noted that<br>
> the time frame for reserves has been reduced from 36 to 24 months in<br>
> version 1.55.<br>
><br>
> This draft policy is open for discussion on this mailing list and will<br>
> be on the agenda at the upcoming ARIN Public Policy Meeting in Atlanta.<br>
><br>
> 2010-13 is below and available at:<br>
> <a href="https://www.arin.net/policy/proposals/2010_13.html" target="_blank">https://www.arin.net/policy/proposals/2010_13.html</a><br>
><br>
> Regards,<br>
><br>
> Communications and Member Services<br>
> American Registry for Internet Numbers (ARIN)<br>
><br>
><br>
> ## * ##<br>
><br>
><br>
> Staff Assessment of Draft Policy 2010-13 (version 1.53 dated 19<br>
> September 2010)<br>
><br>
> Permitted Uses of space reserved under NRPM 4.10<br>
><br>
> 1. Proposal Summary (Staff Understanding)<br>
><br>
> This policy modifies the existing NRPM policy 4.10 (?Dedicated IPv4<br>
> block to facilitate IPv6 Deployment?). It sets aside in its entirety<br>
> the last /8 ARIN receives from the IANA for issuance to networks<br>
> transitioning to a dual IPv4/IPv6 network rather than the /10 currently<br>
> cited in NRPM 4.10. Any IPv4 address space returned to ARIN (and not<br>
> subject to a global or regional transfer policy) will be added to this<br>
> transition pool. Under this policy there are four major classes of<br>
> requestors:<br>
><br>
> - ISPs can apply for /32s for customers as long as each customer<br>
> meets the policy's detailed qualification criteria.<br>
><br>
> - Any operator can apply for /32s for issuing to devices used to<br>
> serve-up internet facing content, within the constraints of the defined<br>
> qualifying criteria.<br>
><br>
> - From the /8, a /10 will be set aside so that any operator can<br>
> request space for use in infrastructure numbering for the purposes of<br>
> deploying IPv6. Space can be issued from this /8 for applicants who<br>
> qualify under ARIN's Micro-allocation Policy (with additional<br>
> restrictions).<br>
><br>
> - Finally, space can be issued from this /8 for applicants who<br>
> operate content distribution networks, again, within the context of the<br>
> policy's qualifying criteria.<br>
><br>
> Organizations can request address space to meet their 3-year needs.<br>
> Space is allocated/assigned in quarterly installments. After the first<br>
> quarter, the requestor can only return to ARIN if they have utilized 80%<br>
> of the most recent assignment, and 90% of past assignments (issued under<br>
> this policy). The organization must have also assigned all IP addresses<br>
> issued under the policy to uses that are acceptable under the policy.<br>
> If the organization fails to meet the utilization criteria for four<br>
> consecutive quarters, then the policy directs ARIN staff to reduce the<br>
> amount of space reserved.<br>
><br>
> 2. Comments<br>
><br>
> A. ARIN Staff Comments<br>
><br>
> ? The policy text has become very complex and complicated and the<br>
> general community will have a very hard time understanding the concepts<br>
> and criteria proposed within the policy.<br>
><br>
> ? It seems to be out of order ? it starts out with reservations<br>
> before ever mentioning the initial qualifying criteria. The author<br>
> might want to consider re-ordering to start with the essential<br>
> qualification criteria first.<br>
><br>
> ? Section 4.10.2 suggests that all allocations made under this policy<br>
> will initially be made from a 3-year reservation. In light of the<br>
> imminent depletion of IPv4 address space, it doesn't seem fair to allow<br>
> some organizations to retain/reserve this valuable resource for up to 3<br>
> years while others will be denied.<br>
><br>
> ? The policy text in (in 4.10.3) appears to contradict itself, as it<br>
> first directs staff to remove one quarter's worth of reservation, and<br>
> then, if the organization continues this practice for three consecutive<br>
> quarters, remove the organization's reserves completely. Later, it<br>
> explicitly directs staff to revoke addresses issued under this policy<br>
> that are used by the organizations for purposes not permitted under this<br>
> policy.<br>
><br>
> ? This proposal will essentially supplant the recently ratified<br>
> policy "Waiting List for Unmet Resources". That list will consist of<br>
> people waiting for resources to be returned or revoked so that ARIN can<br>
> then reissue them to requestors in need of IPv4 address space. This<br>
> proposal says that any IPv4 address space that comes back to ARIN<br>
> immediately goes into the IPv6 transition pool and can only be used for<br>
> that purpose.<br>
><br>
> ? Under 4.10.4.B5, how would staff be able to verify that x percent<br>
> of an organization?s content is IPv6 reachable?<br>
><br>
><br>
> B. ARIN General Counsel<br>
> This policy is unlikely to cause any legal issues of any importance.<br>
><br>
><br>
> 3. Resource Impact<br>
><br>
> This policy would have moderate to major resource impact. It is<br>
> estimated that implementation would occur within 6 to 9 months after<br>
> ratification by the ARIN Board of Trustees. The following would be<br>
> needed in order to implement:<br>
> ? Changes to the way ARIN manages reverse DNS (to handle in-addr.arpa<br>
> delegations for blocks smaller than /24)<br>
> ? Updated guidelines<br>
> ? Staff training<br>
><br>
><br>
>> -----Original Message-----<br>
><br>
>> From: Owen DeLong [mailto:<a href="mailto:owen@delong.com">owen@delong.com</a>]<br>
><br>
>> Sent: Thursday, September 23, 2010 7:26 PM<br>
><br>
>> To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a> List; policy<br>
><br>
>> Subject: Final draft of 2010-13 for Atlanta (Rev 1.55)<br>
><br>
>><br>
><br>
>> Changes:<br>
><br>
>><br>
><br>
>> 1. Set maximum reservation period to 24 months. This avoids creating<br>
><br>
>> a 4-year reservation by CIDR-rounding 36 month reservations.<br>
><br>
>> 2. Reduced minimum size for 4.10.4(b) to /28<br>
><br>
>><br>
><br>
>> These changes will make the policy more balanced and reduce the extent<br>
><br>
>> to<br>
><br>
>> which larger organizations could be disadvantaged relative to smaller<br>
><br>
>> smaller organizations if reservations have to be resized.<br>
><br>
>><br>
><br>
>> The change to a 2-year system resolves an issue with the CIDR-Rounding<br>
><br>
>> where a 36-month reservation is mathematically guaranteed to become a<br>
><br>
>> 48-month reservation. The other alternative was to round-down instead<br>
><br>
>> of<br>
><br>
>> up which would have mathematically converted all reservations to 2<br>
><br>
>> years.<br>
><br>
>> As such, a 2-year reservation system seemed the cleanest and most<br>
><br>
>> straightforward approach.<br>
><br>
>><br>
><br>
>> Owen<br>
><br>
>><br>
><br>
>> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10<br>
><br>
>> Proposal Originator: Owen DeLong, Chris Grundemann<br>
><br>
>> Proposal Version: 1.55<br>
><br>
>> Date: 23 September 2010<br>
><br>
>> Proposal type: modify<br>
><br>
>> Policy term: permanent<br>
><br>
>> Policy statement:<br>
><br>
>><br>
><br>
>> Remove section 4.1.8 (Unmet requests) from the NRPM.<br>
><br>
>> Replace the text of section 4.10 in its entirety (including the name)<br>
><br>
>> with:<br>
><br>
>><br>
><br>
>> 4.10 IPv4 Transition Pool Post IANA Regular Pool Depletion<br>
><br>
>><br>
><br>
>> When ARIN receives its /8 IPv4 allocation from IANA under the<br>
><br>
>> global policy titled "Global Policy for the Allocation of the<br>
><br>
>> Remaining IPv4 Address Space" ratified by ICANN Board<br>
><br>
>> on 6 March, 2009, that /8 will form a dedicated pool to<br>
><br>
>> facilitate IPv6 Deployment.<br>
><br>
>><br>
><br>
>> Addresses returned to ARIN and not subject to a regional or<br>
><br>
>> global transfer policy will be reserved for utilization in the<br>
><br>
>> transition<br>
><br>
>> pool.<br>
><br>
>><br>
><br>
>> Allocations and assignments from this block must be justified by<br>
><br>
>> IPv6 transition requirements.<br>
><br>
>><br>
><br>
>> ARIN will use their discretion in determining whether a<br>
><br>
>> particular<br>
><br>
>> application meets the spirit of this policy.<br>
><br>
>><br>
><br>
>> 4.10.1 Addressing Plan<br>
><br>
>><br>
><br>
>> Any organization wishing to receive IPv4 addresses through this<br>
><br>
>> policy must submit a detailed addressing plan for any request<br>
><br>
>> that is made containing the following:<br>
><br>
>> (a) Their addressing needs over the entire reservation period<br>
><br>
>> and<br>
><br>
>> (b) Methods of meeting all requirements (requirements are<br>
><br>
>> explained in section 4.10.4.) over the entire reservation<br>
><br>
>> period.<br>
><br>
>><br>
><br>
>> 4.10.2 Reservation System<br>
><br>
>><br>
><br>
>> Initially, all space assigned or allocated under this policy will<br>
><br>
>> be<br>
><br>
>> reserved in advance for a maximum period of 24 months, requests<br>
><br>
>> for<br>
><br>
>> shorter reservations will be accepted. The total reservation size<br>
><br>
>> will be rounded up to a CIDR bit boundary.<br>
><br>
>><br>
><br>
>> Each organization's reservation amount will be divided<br>
><br>
>> into quarterly allotments. Allotments will be rounded up<br>
><br>
>> to a CIDR bit boundary. The final quarterly allotment will<br>
><br>
>> contain only the remaining space from the full reservation.<br>
><br>
>><br>
><br>
>> An organization may request one reservation under each provision<br>
><br>
>> listed in section 4.10.4. Once a reservation has been satisfied,<br>
><br>
>> another may be requested.<br>
><br>
>><br>
><br>
>> 4.10.2.1 Reservation Requests Prior to Initial ARIN Free Pool<br>
><br>
>> Depletion<br>
><br>
>><br>
><br>
>> Reservations will be accepted from the time that this policy<br>
><br>
>> is adopted until the day that ARIN can no longer fill regular<br>
><br>
>> requests from<br>
><br>
>> space allocated to ARIN by IANA. At that time, if necessary, all<br>
><br>
>> reservations<br>
><br>
>> will be reduced by an equal amount to allow them to fit within<br>
><br>
>> the total space available in the transition pool. No reservation<br>
><br>
>> will be reduced lower than the minimum quarterly allotment for<br>
><br>
>> it's category. Each organization may decide whether to adjust<br>
><br>
>> the reservation period or the allotment size (within the stated<br>
><br>
>> range) when reservations are reduced. Organizations must make<br>
><br>
>> this decision within 30 days of announcement and may not alter<br>
><br>
>> their choice once made. Any space added to the transition<br>
><br>
>> pool during this time will cause a final recalculation of<br>
><br>
>> reservation sizes. Once all necessary adjustments are<br>
><br>
>> made, all reservations are guaranteed and the first quarterly<br>
><br>
>> allotment is issued to each org.<br>
><br>
>><br>
><br>
>> 4.10.2.2 Reservation Requests Post ARIN Free Pool Depletion<br>
><br>
>><br>
><br>
>> Reservation requests received after ARIN free pool depletion<br>
><br>
>> as defined in 4.10.2.1 will not be guaranteed. If approved, such<br>
><br>
>> requests will be placed in a queue. As space becomes available in<br>
><br>
>> the transition pool it will be used to provide allotments to<br>
><br>
>> organizations with reservations in the queue on a first-approved<br>
><br>
>> first-served basis. Partially filled allotments will remain at<br>
><br>
>> the<br>
><br>
>> front of the queue.<br>
><br>
>><br>
><br>
>> 4.10.2.3 Abandonment of Reservation<br>
><br>
>><br>
><br>
>> Any organization may abandon their remaining reservation at any<br>
><br>
>> time by informing ARIN of their desire to do so. Upon<br>
><br>
>> abandonment,<br>
><br>
>> the remaining space in the reservation will be returned to the<br>
><br>
>> transition pool.<br>
><br>
>><br>
><br>
>> 4.10.3 Quarterly Requirements<br>
><br>
>><br>
><br>
>> Organizations with approved reservations and address plans<br>
><br>
>> are entitled to quarterly allotments. In order to receive each<br>
><br>
>> additional allotment, an organization must submit evidence of<br>
><br>
>> compliance with the following sub-sections:<br>
><br>
>> (a) The most recent 4.10 allotment is at least 80% utilized.<br>
><br>
>> (b) All prior 4.10 allotments within the same 4.10.4<br>
><br>
>> category are at least 90% utilized.<br>
><br>
>> (c) All utilization is permitted under the 4.10.4 category for<br>
><br>
>> which it was initially requested.<br>
><br>
>><br>
><br>
>> For purposes of this computation, space received under each<br>
><br>
>> provision shall be considered separately if an organization has<br>
><br>
>> received resources through multiple provisions.<br>
><br>
>><br>
><br>
>> If an organization does not meet all obligations in any given<br>
><br>
>> quarter, that organization shall not receive that quarter's<br>
><br>
>> allotment<br>
><br>
>> and shall have their reservation reduced by one quarterly<br>
><br>
>> allotment.<br>
><br>
>> If an organization does not meet all obligations<br>
><br>
>> for three consecutive quarters, that organization forfeits the<br>
><br>
>> remainder<br>
><br>
>> of their reserved block.<br>
><br>
>><br>
><br>
>> Utilization requirements (a) may be delayed at ARIN's discretion.<br>
><br>
>><br>
><br>
>> If an organization is using space received under 4.10 in a manner<br>
><br>
>> contrary to 4.10, that organization forfeits their remaining<br>
><br>
>> reservation and may have their entire allocation or assignment<br>
><br>
>> revoked.<br>
><br>
>><br>
><br>
>> All 4.10. space forfeited, revoked or otherwise reclaimed shall<br>
><br>
>> be returned to the ARIN transition pool.<br>
><br>
>><br>
><br>
>> 4.10.4 Specific types of transitional uses have specific<br>
><br>
>> requirements:<br>
><br>
>><br>
><br>
>> (a) An ISP/LIR may request a block no smaller than a /25 nor<br>
><br>
>> larger than a /18 per quarter to be used to provide single<br>
><br>
>> IPv4 /32s to their customers which could justify a /28 or<br>
><br>
>> more of IPv4 under ARIN policies in effect at the time of<br>
><br>
>> IANA depletion.<br>
><br>
>> 1. No customer site may receive more than a single<br>
><br>
>> IPv4 /32 per 1,000 Internet connected hosts upto 8<br>
><br>
>> /32s.<br>
><br>
>> 2. The customer site must not have any IPv4<br>
><br>
>> addresses not issued under this policy.<br>
><br>
>> 3. The customer site must use the /32 to provide<br>
><br>
>> IPv4 connectivity for hosts which have IPv6<br>
><br>
>> addresses with IPv6 connectivity to the ISP/LIR.<br>
><br>
>> 4. The ISP/LIR must demonstrate that it already<br>
><br>
>> provides IPv6 addressing and connectivity to at<br>
><br>
>> least one additional existing customer site for<br>
><br>
>> each /32 requested, up to 90% of all customer sites<br>
><br>
>> served (across all customers).<br>
><br>
>> 5. An ISP/LIR customer which is not large enough to<br>
><br>
>> qualify<br>
><br>
>> under this provision and has no unassigned IPv4<br>
><br>
>> addresses<br>
><br>
>> may receive an appropriate number of /32s from their<br>
><br>
>> upstream provider for reassignment to their customers<br>
><br>
>> under the terms of 4.10.4(a).<br>
><br>
>> 6. A customer site which terminates multiple connections<br>
><br>
>> from the same provider on separate routers may<br>
><br>
>> qualify<br>
><br>
>> for one /32 per unique router with a direct<br>
><br>
>> connection to<br>
><br>
>> the provider, up to a total of 8 /32s.<br>
><br>
>> 7. The total space issued to all organizations under<br>
><br>
>> this provision shall not exceed an aggregate /9<br>
><br>
>> or equivalent per /8 placed into the transition pool.<br>
><br>
>><br>
><br>
>><br>
><br>
>> (b) An ISP/LIR or End user organization may request a block<br>
><br>
>> no smaller than a /28 and no larger than a /18 per quarter<br>
><br>
>> to provide single IPv4 /32s to each physical server used<br>
><br>
>> to provide Internet reachable content.<br>
><br>
>> 1. Space issued under this provision is an assignment,<br>
><br>
>> not an allocation. An LIR may not distribute this<br>
><br>
>> space to their customers.<br>
><br>
>> 2. No server may receive more than a single IPv4 /32<br>
><br>
>> under this provision.<br>
><br>
>> 3. The server must have IPv6 addresses with IPv6<br>
><br>
>> connectivity (must be dual-stacked).<br>
><br>
>> 4. The receiving organization must demonstrate that it<br>
><br>
>> already provides IPv6 addressing and connectivity<br>
><br>
>> to at least one additional existing server<br>
><br>
>> (organizations which can show 100% dual stack are<br>
><br>
>> exempt from this requirement).<br>
><br>
>> 5. The receiving organization must IPv6 enable all of<br>
><br>
>> their content on the following schedule:<br>
><br>
>><br>
><br>
>> + 25% of content IPv6 reachable within six<br>
><br>
>> months of receiving their first addresses<br>
><br>
>> under this policy<br>
><br>
>> + 50% of content IPv6 reachable within one year<br>
><br>
>> of receiving their first addresses under this<br>
><br>
>> policy<br>
><br>
>> + 75% of content IPv6 reachable within 18 months<br>
><br>
>> of receiving their first addresses under this<br>
><br>
>> policy<br>
><br>
>> + 90% of content IPv6 reachable within 24 months<br>
><br>
>> of receiving their first addresses under this<br>
><br>
>> policy<br>
><br>
>> 6. A network providing SSL terminations for applications<br>
><br>
>> or content acceleration may receive a /32 for each<br>
><br>
>> distinguished name by following all requirements in<br>
><br>
>> this provision, substituting "distinguished name" for<br>
><br>
>> "server."<br>
><br>
>> 7. Networks using these addresses for authoritative<br>
><br>
>> DNS servers can use 2 /32s per 1,000 authoritative<br>
><br>
>> domains served up to 128 /32s total per organization.<br>
><br>
>> 8. The total space issued to all organizations under<br>
><br>
>> this provision shall not exceed an aggregate /9<br>
><br>
>> or equivalent per /8 placed into the transition pool.<br>
><br>
>><br>
><br>
>> (c) An ISP/LIR or End user organization may request a block no<br>
><br>
>> smaller than a /29 and no larger than a /25 per quarter for<br>
><br>
>> purposes relevant to their ability to deploy IPv6.<br>
><br>
>> 1. Space issued under this provision is an assignment,<br>
><br>
>> not an allocation. An LIR may not distribute this<br>
><br>
>> space to their customers.<br>
><br>
>> 2. Space issued under this provision must be used to<br>
><br>
>> provide the required public IPv4 address(es) for<br>
><br>
>> transitional technologies operated by the recipient<br>
><br>
>> organization.<br>
><br>
>><br>
><br>
>> Specific examples of permitted uses are:<br>
><br>
>> a. Large scale or "Carrier Grade" NAT<br>
><br>
>> b. NAT-PT<br>
><br>
>> c. DS-LITE/B4/AFTeR<br>
><br>
>> d. IVI<br>
><br>
>> e. DNS64 or other transitional DNS enablers<br>
><br>
>> f. Other technologies of similar purpose<br>
><br>
>> and scope.<br>
><br>
>><br>
><br>
>> 3. A /10 from the final /8 shall be reserved for<br>
><br>
>> issuance<br>
><br>
>> under this provision. In no case shall any addresses<br>
><br>
>> from this /10 be issued for any purpose outside<br>
><br>
>> of 4.10.4(c).<br>
><br>
>><br>
><br>
>> (d) Applications which would qualify for IPv4 under section 4.4<br>
><br>
>> of<br>
><br>
>> the NRPM (critical infrastructure) may qualify for IPv4<br>
><br>
>> space<br>
><br>
>> under this policy if they meet the following criteria:<br>
><br>
>> 1. The critical infrastructure to be numbered must also<br>
><br>
>> have IPv6 addresses and must provide all services<br>
><br>
>> provided on IPv4 over IPv6 on the same time table.<br>
><br>
>> 2. Assignments under this provision shall be the<br>
><br>
>> smallest technically feasible size for the critical<br>
><br>
>> infrastructure in question.<br>
><br>
>> 3. The total space assigned under this provision shall<br>
><br>
>> not<br>
><br>
>> exceed the equivalent of a /14.<br>
><br>
>><br>
><br>
>> </pre><br>
><br>
>><br>
><br>
>> <pre><br>
><br>
>><br>
><br>
>><br>
><br>
>> Rationale:<br>
><br>
>><br>
><br>
>> The current terminology in section 4.10 is vague and could allow a<br>
><br>
>> variety of interpretations which could lead to allocations or<br>
><br>
>> assignments being made to ISPs intending to misuse the space for<br>
><br>
>> general deployment by using IPv6 overlay technologies as a "IPv6<br>
><br>
>> deployments" requiring IPv4 space for transition. For example, the<br>
><br>
>> current policy could be interpreted to enable an ISP to require IPv4<br>
><br>
>> addresses for all IPv6 customers to roll IPv6 out as 6rd to customers<br>
><br>
>> who would be otherwise unable to get IPv4 space. This is clearly<br>
><br>
>> outside of the original intent of the proposal which created 4.10 (6rd<br>
><br>
>> was not yet envisioned at the time that was written). This proposal<br>
><br>
>> seeks to clarify that intent and tighten up the requirements for<br>
><br>
>> organizations seeking to get space from this limited final resource so<br>
><br>
>> that it truly is available to facilitate transitional technologies.<br>
><br>
>><br>
><br>
>> Additionally, there are a number of community segments that are not<br>
><br>
>> well served by the original intent of 4.10 and several community<br>
><br>
>> members requested a mechanism for providing a certain amount of<br>
><br>
>> certainty with regards to obtaining space at the end. While it would be<br>
><br>
>> impossible to guarantee organizations all the space they need as runout<br>
><br>
>> is upon us, this policy seeks to provide a way for organizations to<br>
><br>
>> sign up for and receive a reservation from the final space<br>
><br>
>> proportionate to their need. The policy also includes guidelines<br>
><br>
>> intended to ensure that this vital community resource is given only to<br>
><br>
>> organizations working towards a smooth transition to IPv6 to the<br>
><br>
>> benefit of the full community.<br>
><br>
>><br>
><br>
>> In order to meet these needs, this policy has become very complex. It<br>
><br>
>> is an unfortunate artifact of the complex issue it seeks to address. A<br>
><br>
>> great deal of effort has been made to simplify the policy as much as<br>
><br>
>> possible, and, special thinks go out to several members of the<br>
><br>
>> community for their assistance in this matter.<br>
><br>
>><br>
><br>
>> One provision in this draft policy calls for utilization criteria which<br>
><br>
>> may be waived by ARIN staff discretion. The intent of this clause is to<br>
><br>
>> allow staff to avoid penalizing an organization for successful address<br>
><br>
>> conservation efforts.<br>
><br>
>><br>
><br>
>> Runout is upon us. IANA will run out of the IANA free pool and issue<br>
><br>
>> the last /8 this policy seeks to regulate before the next ARIN public<br>
><br>
>> policy meeting. If we are to make any attempt at fair distribution for<br>
><br>
>> the sake of IPv6 deployment, this is our final opportunity to do so<br>
><br>
>> outside of an emergency action by the ARIN board.<br>
><br>
>><br>
><br>
>> Timetable for implementation: immediate<br>
><br>
>><br>
><br>
>> For reference, here is the current text of 4.10<br>
><br>
>><br>
><br>
>> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment<br>
><br>
>><br>
><br>
>> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous<br>
><br>
>> /10 IPv4 block will be set aside and dedicated to facilitate IPv6<br>
><br>
>> deployment. Allocations and assignments from this block must be<br>
><br>
>> justified by immediate IPv6 deployment requirements. Examples of such<br>
><br>
>> needs include: IPv4 addresses for key dual stack DNS servers, and NAT-<br>
><br>
>> PT or NAT464 translators. ARIN staff will use their discretion when<br>
><br>
>> evaluating justifications.<br>
><br>
>><br>
><br>
>> This block will be subject to a minimum size allocation of /28 and a<br>
><br>
>> maximum size allocation of /24. ARIN should use sparse allocation when<br>
><br>
>> possible within that /10 block.<br>
><br>
>><br>
><br>
>> In order to receive an allocation or assignment under this policy:<br>
><br>
>> 1. the applicant may not have received resources under this<br>
><br>
>> policy in the preceding six months;<br>
><br>
>> 2. previous allocations/assignments under this policy must<br>
><br>
>> continue to meet the justification requirements of this policy;<br>
><br>
>> 3. previous allocations/assignments under this policy must meet<br>
><br>
>> the utilization requirements of end user assignments;<br>
><br>
>> 4. the applicant must demonstrate that no other allocations or<br>
><br>
>> assignments will meet this need;<br>
><br>
>> 5. on subsequent allocation under this policy, ARIN staff may<br>
><br>
>> require applicants to renumber out of previously allocated / assigned<br>
><br>
>> space under this policy in order to minimize non-contiguous<br>
><br>
>> allocations.<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 29 Sep 2010 08:32:59 -0600<br>
From: Chris Grundemann <<a href="mailto:cgrundemann@gmail.com">cgrundemann@gmail.com</a>><br>
To: "<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>" <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)<br>
Message-ID:<br>
<<a href="mailto:AANLkTimUxYeYO-F8gm-WA3_VyMakaZ1O8BJZ7k1fkr_A@mail.gmail.com">AANLkTimUxYeYO-F8gm-WA3_VyMakaZ1O8BJZ7k1fkr_A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
I think the fact that ARIN Staff is concerned that this policy may<br>
favor organizations who are granted reservations too much and Marty<br>
believes that it does not go far enough to provide relief to those<br>
same organizations illustrates that we have actually found a pretty<br>
decent compromise.<br>
<br>
On Tue, Sep 28, 2010 at 15:55, Hannigan, Martin <<a href="mailto:marty@akamai.com">marty@akamai.com</a>> wrote:<br>
><br>
> This proposal still does not go far enough in offering some level of relief<br>
> to all segments of the industry.<br>
<br>
The simple fact is that we are running out of IPv4 space. Absolutely<br>
no policy can change that. Advancing transition to IPv6 across the<br>
board is the best way (perhaps the only way) to ease all of our<br>
growing pains going forward.<br>
<br>
> On 9/27/10 4:02 PM, "ARIN" <<a href="mailto:info@arin.net">info@arin.net</a>> wrote:<br>
>><br>
>> ? A. ? ?ARIN Staff Comments<br>
>><br>
>> ? ?? Section 4.10.2 suggests that all allocations made under this policy<br>
>> will initially be made from a 3-year reservation. ?In light of the<br>
>> imminent depletion of IPv4 address space, it doesn't seem fair to allow<br>
>> some organizations to retain/reserve this valuable resource for up to 3<br>
>> years while others will be denied.<br>
<br>
I would like to point out that although the initial reservations are<br>
for [now two years], there is a built in "fairness valve" as well.<br>
Please see section 4.10.2.1 in the draft policy, which starts thus:<br>
<br>
Reservations will be accepted from the time that this policy<br>
is adopted until the day that ARIN can no longer fill regular requests from<br>
space allocated to ARIN by IANA. At that time, if necessary, all reservations<br>
will be reduced by an equal amount to allow them to fit within<br>
the total space available in the transition pool.<br>
<br>
So everyone who is granted a reservation before run-out gets *some*<br>
reservation, although it is not likely that anyone will get the full<br>
reservation requested. I think this is the best balance of<br>
predictability and inclusiveness possible.<br>
<br>
Also note the second phase, post-exhaustion, detailed in section<br>
4.10.2.2 which reads:<br>
<br>
Reservation requests received after ARIN free pool depletion<br>
as defined in 4.10.2.1 will not be guaranteed. If approved, such<br>
requests will be placed in a queue. As space becomes available in<br>
the transition pool it will be used to provide allotments to<br>
organizations with reservations in the queue on a first-approved<br>
first-served basis. Partially filled allotments will remain at the<br>
front of the queue.<br>
<br>
So, *everyone* gets a shot at the transition space, and it comes down<br>
to how much space ends up being available.<br>
<br>
Overall, I think we have come up with the best possible (most fair)<br>
soft-landing policy under the current constraints (constraints which<br>
will only get tighter).<br>
<br>
~Chris<br>
<br>
>><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
><br>
<br>
--<br>
@ChrisGrundemann<br>
<a href="http://weblog.chrisgrundemann.com" target="_blank">weblog.chrisgrundemann.com</a><br>
<a href="http://www.burningwiththebush.com" target="_blank">www.burningwiththebush.com</a><br>
<a href="http://www.coisoc.org" target="_blank">www.coisoc.org</a><br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
ARIN-PPML mailing list<br>
<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
<br>
End of ARIN-PPML Digest, Vol 63, Issue 32<br>
*****************************************<br>
</blockquote></div><br><br clear="all"><br>-- <br><img src="http://api.ning.com/files/60Dc*7fMSnOD5inYWvnElhieb2y*e2O798iHVa48vgYOJUmz33g1MSmWAGQs0M2C7g4LXqAu0KvJ0c99k3kSouZfig33AnNo/emaillogo.jpg"><br><div>Rudi Daniel<div>
<i><a href="http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774" target="_blank">danielcharles consulting</a><br></i><b><span style="font-size:large"><font color="#006600"><a href="http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774" target="_blank">1-784 498 8277</a></font></span></b></div>
<div><font color="#006600"><span style="font-size:large"><b><br></b></span></font><div><span style="font-size:large"><br></span></div></div></div><br>
</div></div>