[arin-ppml] IPv4 Run Out Proposals

[Chris Grundemann]

On Tue, Jul 28, 2009 at 09:26, Chris Grundemann<cgrundemann at gmail.com> wrote:
> On Mon, Jul 27, 2009 at 17:37, David Farmer<farmer at umn.edu> wrote:
>> On 27 Jul 2009 Chris Grundemann wrote:
>>
>>> On Mon, Jul 27, 2009 at 13:31, Ted Mittelstaedt <tedm at ipinc.net> wrote:
>>> >
>>> > David Farmer wrote:
>>> >> 1. Should they be merged together and move forward as a single Draft Policy?
>>> >>
>>> >
>>> > yes.
>>>
>>> +1
>>>
>>> My recommendation is that proposal 94 is merged into proposal 93,
>>> leaving the fairly arbitrary date based method of reduction behind in
>>> favor of a remaining resources based implementation (and limit it to
>>> IPv4 explicitly); such as "when ARIN receives its last /8, an
>>> organization may choose to request up to a 6 month supply of IPv4
>>> resources" or some more finely graduated but similarly triggered
>>> reduction.
>>>
>>> $0.02,
>>> ~Chris
>>
>> I think I see what you are getting at;
>>
>> How about something like this;
>>
>> IANA pool down to X /8s, triggers 9 month allocation window
>> IANA pool down to Y /8s, triggers 6 month allocation window
>> IANA pool down to Z /8s, triggers 3 month allocation window
>> ARIN gets last /8, triggers maximum allocation of up to one quarter of ARIN
>> free pool per allocation.
>
> Yes, this is exactly what my intention was.
>
>> Maybe with X=25, Y=15,  Z=10, but I need think about the numbers more.
>
> Some facts to help the discussion (correct me if I am wrong):
>
> There are currently 30 /8s Unallocated by IANA.
> So far 4 /8s have been allocated this year.
> In 2008 IANA allocated 9 /8s.
> In 2007 IANA allocated 13 /8s. [1]
>
> There have been an average of 207 /24s requested from ARIN per month
> this year. [2]
> The average for 2008 was 200 /24s per month.
> The average for 2007 was 197 /24s per month. [3]
>
> So if we make things simple for ourselves we could say that 10 /8s
> will last about a year and that ARIN hands out about 10 /16s in that
> year.  These numbers are admittedly fuzzy and of course become even
> less absolute once we get closer to free pool exhaustion and start
> playing with the allocations but I think they work ok for my purposes
> here, at least for the moment.
>
>
> The original text set the policy to start limiting the allocation
> window a year from now, I think that is reasonable and if we want to
> stick close to that, I think X=20.
>
> Then, imo, we should stagger into the next two reductions,
> incrementally shortening the time that we keep each subsequent
> allocation window.  So perhaps Y=12 (leaving us at a 9 month window
> for 8 /8s) and Z=6 (keeping the 6 month window for 6 /8s) and then
> trigger the maximum allocation at 1 /8 (having maintained a 3 month
> window for 5 /8s).

I forgot to account for the End Policy; when IANA reaches 5 /8s
unallocated, we will drop to zero.  Allowing for that, maybe a better
set is: X=20, Y=15 and Z=10.  Or perhaps we should take less steps and
go from a 12 month window to 6 and then to the 1/4 maximum.

~Chris

> There obviously needs to be some further discussion around these
> triggers but those tweaks could happen after the merged policy is
> presented in Dearborn, imho.
>
>
>> The one advantage of setting arbitrary dates for the allocation window
>> changes are everyone knows when they will happen.
>>
>> With something like this you won't have arbitrary dates anymore, but you
>> won't know exactly when the changes will hit either, and the threshold of
>> number of /8s left are probably somewhat arbitrary instead of the dates.
>
> I am sure some (perhaps many) will complain that dates are more
> predictable and that businesses can better plan for them, etc. But I
> think that the remaining available space is so much more relevant to a
> policy such as this that it outweighs that bit of uncertainty.  I
> would also point out (again) that the prudent business plan here
> should be a migration strategy to a network which is IPv6 capable (I
> did not say exclusive), not solely an IPv4 address request tactic.
>
>> So which would people prefer?
>>
>> 1. Well known dates, or;
>> 2. Triggers based on the actual resources left
>>
>> I really need feed back on how people want to see this, and if you support
>> this kind of proposal or not.
>>
>> There was a bunch of discussion on the ARIN-Discuss list last week about
>> recovering legacy space, it is much easier to set policy on how we are going
>> to divvy up what is left of the IPv4 space than it is to get anyone to give any
>> back.  So maybe we can put as much energy into creating policy about the
>> IPv4 space that is left than was put into the discussion about trying to
>> recover space last week.  Personally I'm much more optimistic that we can
>> do something about Run-Out policies than I'm about the chances to get
>> people to give back space.
>>
>> Thanks
>>
>> ===============================================
>> David Farmer                                      Email:farmer at umn.edu
>> Office of Information Technology
>> Networking & Telecomunication Services
>> University of Minnesota                Phone: 612-626-0815
>> 2218 University Ave SE                 Cell: 612-812-9952
>> Minneapolis, MN 55414-3029             FAX: 612-626-1818
>> ===============================================
>>

-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org