[arin-ppml] IPv4 Run Out Proposals

[Chris Grundemann]

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.  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