[arin-ppml] IPv4 Run Out Proposals

[Ted Mittelstaedt]

Chris Grundemann 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).
> 
> 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. 

While this is fine for policy I think it cannot be underestimated the
impact that an actual date has on the general public - and consider
your CEO's members of the general public when it comes to this issue.

Ted