<HTML>
<HEAD>
<TITLE>Re: [arin-ppml] Set aside round deux</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
And a minor correction please. I meant proposal 116 v. 109 when I referenced it.<BR>
<BR>
<BR>
On 7/26/10 4:37 PM, "<a href="cja@daydream.com">cja@daydream.com</a>" <<a href="packetgrrl@gmail.com">packetgrrl@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Owen,<BR>
<BR>
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? <BR>
<BR>
----Cathy<BR>
<BR>
On Mon, Jul 26, 2010 at 2:31 PM, Owen DeLong <<a href="owen@delong.com">owen@delong.com</a>> wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>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><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="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">http://lists.arin.net/mailman/listinfo/arin-ppml</a><BR>
> Please contact <a href="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="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">http://lists.arin.net/mailman/listinfo/arin-ppml</a><BR>
Please contact <a href="info@arin.net">info@arin.net</a> if you experience any issues.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>