[arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves

[David Farmer]

On 24 Mar 2009 Matthew Wilder wrote:

> Hi Owen,
> 
> I agree that there should be some amount of rationing of IP Addresses
> in the IPv4 endgame.  I simply question the fairness of a policy that
> says everyone can have what they need in IPv4 addresses except those
> who need more than a /20 every 6 months.
> 
> Fairness itself is a loaded word in these discussions.  To me,
> fairness in this case fundamentally implies equal access to IPv4
> addresses.  The question then becomes the definition of equal access. 
> Is that access to an equal amount of space per organization?  Though
> that sounds good, that answer ignores the philosophy of needs-based
> allocations.  And what about equal amount of space per EU organization
> represented by an ISP?  

You are right, much like art, fairness is in the eyes of the beholder.  But like 
another famous quote about art, I think we know fairness when we see it.  
There is another measurement of fairness, when everyone is unhappy 
maybe you are there (at fairness).

> That would imply that the large ISPs should
> still have access to the majority of IP Addresses, since they
> represent the vast majority of internet users in North America.

I'm with Mr. Sprunk on this one the bigger you are the more effect you can 
have on IPv6 adoption. But, there isn't only an fairness issue between big 
and small, if we don't do something one big ISP could get the last bit of IP 
space and leave none for the other big ISPs too. 

> The starting point for this policy has to be some kind of target
> objective.  If the objective of the policy is to make the last /9 of
> space last around one year before depletion, without consideration of
> consistent limitation to vastly different organizations, I think this
> policy fits the bill.

I don't think we have an exact target, but that is the general idea, make what 
is left last some amount of time, a year plus or minus a few months seems 
about right, but I don't have a specific.  We would also like to avoid a run on 
the bank so to speak.    Another way to describe this is make sure everyone 
can get some of the crumbs at the bottom of the bag of the potato chips.  
The only truly fair way is to get the next bag of potato chips off the shelf (you 
could think of that as IPv6), but short of doing that how should we dole-out 
the crumbs.

> I think there is a way of making the last /9 last for a year without
> unequally affecting different organizations.  I think the way to
> implement such a policy more fairly is to limit allocations to a
> certain percentage of space an organization already has allocated to
> it.  Thus, each organization can have equal geometric growth to their
> IPv4 address space, and thus everyone has the same limitations placed
> on them.  I don't know the numbers that would accomplish a goal of 1
> year spreadout of the last /9, but I would bet it is in the 5-10%
> ballpark.  Note that this kind of policy would prevent a run on ARIN
> by smaller ISPs and EUs that can request a /20 which might double
> their IPv4 address space.

Personally I'd like to do something like what you are talking about, but I think 
it is to hard.  Maybe the important thing is to make sure everyone to feels 
some of pain.  But, given the realities of base 2 mathematics and the other 
constraints we have to work with it is impossible to have everyone feel the 
pain equally.  The big guys will always have more pain, they have further to 
fall.  Remember, "the bigger they are, the harder they fall."

I propose the following tiered methodology, based on your justified need 
under current process and procedures, you would get the following;

Justified Need, what you get
/11 or greater, you get a /20
/12 to /14, you get a /21
/15 to /17, you get a /22
/18 to /20, you get a /23
/21 or smaller, you get a /24

While not as concise and elegant as the current policy, it is reasonably 
understandable and shares the pain down to the smaller guys too.

Note: Currently, the minimum allocation for all End Users and ISP in the US 
and Canada is /20, Caribbean and North Atlantic Islands sector ISPs only is 
/22, and Micro-allocations are /24.  So, only Micro-allocations at /24 actually 
get 100% of their need meet and that is probably OK, they are suppose to be 
"critical" after all.

See the following Google Doc Spread Sheet and charts, I had to generate 
the charts with Excel, and provide them as JPEGs because I couldn't  figure 
out how to get Google Docs to do log graphs.

Spread Sheet
http://spreadsheets.google.com/pub?key=pMNgPs6H0qPUlVFsG30_Zfw

Chart1
http://docs.google.com/Doc?id=dg794v8b_2gs5v3hcg

Chart2
http://docs.google.com/Doc?id=dg794v8b_0dc7k2xgc

The draw backs are;
1. More complicated than the proposed policy
2. Allocating blocks smaller than /20 or /22, but that can probably be 
contained to the last /9 or so.
3. More small blocks causing route table growth, but this is probably self 
limiting anyway.
4. The other RIR are basically doing much the same as the current policy 
proposal, so in some ways this tiered approach maybe more fair, but maybe 
not if you compare the ARIN region to other regions.

> I look forward to hearing your thoughts on these ideas!

What do you think?

> Cheers,
> Matthew

Personally, I'm ok with this either way, if people can get over the slight 
unfairness of /20 it is way simpler and is way all the other RIR seem to be 
going too.  That doesn't make it right, but it does cut down on the regional 
differences.  Which is why I backed down in the AC discussions on this 
issue.

And, either way we are going to be out of IPv4 addresses long before most 
people are ready for IPv6, I hope I'm wrong on this one, but!


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