Owen,<div><br></div><div>So do you feel that this is bad all around or just the minimum allocation unit needs to be changed to something smaller?  Others out there?  What are your thoughts regarding a minimum/maximum allocation size for this last /8?  </div>
<div><br></div><div>----Cathy<br><br><div class="gmail_quote">On Mon, Jul 26, 2010 at 2:31 PM, Owen DeLong <span dir="ltr"><<a href="mailto:owen@delong.com">owen@delong.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Marty,<br>
        How do you expect anyone but the largest of the large and extra large<br>
organizations to qualify for a /20 of IPv4 space under this proposal?<br>
<br>
        This is a really interesting way to attempt to reserve the last /8 for use<br>
only by the largest organizations ARIN serves, but, I really don't think that<br>
is good policy.<br>
<font color="#888888"><br>
Owen<br>
</font><div><div></div><div class="h5"><br>
On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:<br>
<br>
><br>
><br>
> Hello PPML:<br>
><br>
><br>
> Since it seemed to have been very helpful to vet the global policy idea on<br>
> the list, I thought it might be helpful to use it to frame my non-support<br>
> for 109. This is, just like the last time, very raw, but I expect to solicit<br>
> some time during open policy hour to discuss a more polished version.<br>
><br>
> A few points.<br>
><br>
> - This idea takes us in the direction of actual transition<br>
> - Define an acceptable use list<br>
> - Seeks to address COSTS<br>
> - Levels the playing field between small and large<br>
> - Reserves an entire /8 for transition, not for business as usual<br>
> - Counters the high priced "market" that is emerging by deferring it's need<br>
><br>
> May not get us all the way through, but every month that we can avoid<br>
> sending people to markets is a month of reduced costs IMHO. And it is about<br>
> costs at this point. It's a given that it is going to happen.<br>
><br>
> Too soon for "for" or "against", but most definitely open to feedback. Don't<br>
> focus on the words, focus on the ideas. Feedback very much appreciated.<br>
><br>
><br>
> --draft, group working comments removed for ease of read<br>
><br>
> 1. Transition Pool<br>
><br>
> ARIN will set-aside the final /8 allocated form the IANA to facilitate<br>
> transition from IPv4 to IPv6. The resulting "transition pool" will become<br>
> immediately available for allocations under this policy. This pool will be<br>
> known as the "transition pool".<br>
><br>
> 2. Minimum and Maximum Allocation Unit<br>
><br>
> The minimum allocation unit will be a /20. The maximum allocation unit will<br>
> be /15.<br>
><br>
> 2. Allocation Method<br>
><br>
> ARIN will determine and utilize the best method possible for allocations<br>
> with the goal of maximizing what can be allocated balanced by minimum<br>
> deaggregation.<br>
><br>
> 3. Eligibility<br>
><br>
> An applicant will become eligible to receive IPv4 addresses from this pool<br>
> when they meet the following requirements:<br>
><br>
> 1. Applicant will provide a written plan detailing how the addresses will be<br>
> used and on what devices.<br>
><br>
> 2. Previous allocations or assignments under this policy must continue to<br>
> meet the justification requirements of this policy.<br>
><br>
> 3. Must have applied for, been approved, received and be utilizing an ARIN<br>
> allocated IPv6 allocation or assignment.<br>
><br>
> 4. All allocations or assignments made under this policy must be efficiently<br>
> utilized to a rate of 80%.<br>
><br>
> 5. Applicant must demonstrate that no other allocations or assignments that<br>
> they have received will meet their requirements.<br>
><br>
> 6. Applicants must provide documentation that demonstrates that the<br>
> addresses received under this policy will be used only on dual stack devices<br>
> that will have both an IPv4 and IPv6 address that will both be reachable<br>
> natively.<br>
><br>
> 7. Be in compliance with Section 4, Acceptable Use of Addresses.<br>
><br>
><br>
> 4. Acceptable Use of Addresses<br>
><br>
> 1. A single IPv4 /32 for providers to assign to 6 to 4 NAT gateways for each<br>
> each layer 3 contagious v6 only customer networks thereby enabling IPv4<br>
> connectivity for an IPv6-only customer networks. Customers must not have<br>
> available IPv4 addresses.<br>
><br>
> 2. A single IPv4 /32 for providers to assign to 4 to 4 NAT gateways for each<br>
> each layer 3 contagious v6 customer networks to deploy IPv4 RFC-1918 in<br>
> addition to (and NOT instead of) IPv6 thereby enabling IPv4 connectivity for<br>
> an IPv6-only customer networks.. Customers must not have available IPv4<br>
> addresses.<br>
><br>
> 3. Customer networks qualifying under 4.1 or 4.2 (above) may qualify for<br>
> additional IPv4 address to meet multi-homing traffic engineering needs or to<br>
> address stand-alone NAT devices as specified below:<br>
><br>
> A. A single IPv4 /32 for each interconnect for each mult-homed layer 3<br>
> contiguous customer network that requires traffic engineering. For example a<br>
> network with two interconnects to a single upstream provider can get one<br>
> IPv4 /32 for each of their two interconnects, and distribute their internal<br>
> hosts between the two outside NAT addresses for traffic engineering.<br>
><br>
> B. Customer networks that require stand-alone NAT devices (not integrated<br>
> into their CPE router) qualify for enough IPv4 addresses to number the<br>
> loopback addresses (if needed) for all edge routers that have one or more<br>
> connections to a transit provider, enough IPv4 addresses to number each of<br>
> the point-to-point links between those routers and their transit provider,<br>
> as well as the point to point links between those routers and directly<br>
> connected NAT appliances. As well as one IPv4 address for each of these<br>
> directly connected NAT appliances.<br>
><br>
><br>
> 4. Loopback addresses for edge routers that have one or more connections to<br>
> transit providers and/or peers<br>
><br>
> 5. Address for point to point links between edge routers and their transit<br>
> providers [why does it need to be unique v. 1918?] [that is an interesting<br>
> point... We use globally unique as a matter of not breaking routing by<br>
> accident. I have to think about if it would be generally acceptable to use<br>
> RFC-1918. Interesting question!]<br>
><br>
> 7. A /32 for routers in a greenfield network that are dual stacked.<br>
> [redundant to 3/5?] [this is not redundant... In this case I need an IPv4<br>
> routerID to make BGP work. If I want to be a green-filed IPv6 transit<br>
> provider I need one IPv4 address for each router]<br>
><br>
> 8. /32 for public facing name servers, NTP servers, SMTP servers and Web<br>
> servers which are dual stacked and reachable on IPv4 and IPv6 networks.<br>
><br>
> 9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per VPN aggregator<br>
><br>
><br>
> 5. Reservation Forecasting<br>
><br>
> An applicant may provide ARIN with a thirty-month forecast of IPv4 address<br>
> need. ARIN will reserve the requested size in compliance with Section 2 and<br>
> 3. When a reservation forecast is approved by ARIN, the applicant will then<br>
> be authorized to draw down from the forecast quarterly. Prior to requesting<br>
> reserved addresses, applicant will provide documentation to ARIN that they<br>
> have maintained utilization requirements for previous allocation. If<br>
> applicant fails to meet utilization requirements for two consecutive<br>
> quarters, ARIN will cancel the reservation and return unused addresses to<br>
> the pool.<br>
><br>
><br>
> Example:<br>
><br>
> Applicant applies to ARIN under this policy and submits a thirty-month<br>
> forecast requesting a /16. Using criteria established in the NRPM and this<br>
> policy, ARIN will determine if applicant is eligible and has need. If the<br>
> applicant meets the requirements for the allocation, they will reserve a<br>
> /16. The applicant will then be allocated 3/30th of the forecasted<br>
> requirement in a CIDR block or equivalent number of IPv4 addresses. ARIN<br>
> will round down allocations or assignments to the closest CIDR single block.<br>
> Rounding errors will be applied to the last allocation of the last quarter<br>
> of the thirty month period and allocated then.<br>
><br>
><br>
> 6. Dual Stack Requirement<br>
><br>
> Addresses from this pool may only be used on dual stack devices that are to<br>
> be reachable via both IPv4 and IPv6 networks.<br>
><br>
><br>
> 7. Application Frequency<br>
><br>
> Applicants may apply for address space from the transition pool once per<br>
> quarter. If an applicant has an existing thirty-month forecast that has been<br>
> approved by ARIN, they are ineligible to apply for more address space until<br>
> their reservation has been exhausted. If an applicant has had a reservation<br>
> cancelled due to policy compliance issues including utilization, they are<br>
> not eligble to apply for addresses.<br>
><br>
><br>
> 8. Post Exhaustion Refresh<br>
>> From the point of the issuance of the final /8 from the IANA, ARIN will<br>
> dispose of all address space that it may receive using this policy.<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>
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>
</div></div></blockquote></div><br></div>