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

Matthew Wilder Matthew.Wilder at telus.com
Tue Mar 24 14:35:15 EDT 2009

On Mar 24, 2009, at 10:46 AM, Owen DeLong wrote:

> I think it would be closer to 1%.  Let's look at that in real terms, 
> however.
> For an organization that has an effective /10 worth of space, 1% is more 
> than 40,000 addresses.  On the other hand, for an organization that has 
> a /22, 1% is 10 addresses.  I really don't think the argument that this 
> is an equal impact on the small provider and the large one holds in such 
> a comparison. True, as a growth percentage, the effect is roughly the 
> same, but, in real terms, 1% of a /10 allows the large ISP to add a 
> number of large customers, lots of medium customers and/or a whole lot 
> of small customers. On the other hand, for the small provider, those 10 
> addresses, even if we're generous and bump them up to a /28 
> 16 addresses) to make things line up are probably nearly useless.  
> First, they can only add one small customer or a handful of home users.  
> Second, it's unlikely they can even get the prefix routed, so, maybe 
> they can't even do that.
> Even if we use 10%, the numbers are still pretty skewed.  True, the 
> small provider now gets, essentially, a /25 to use for growth.  They 
> might even be able to put 8-16 small customers into that space.  There's 
> even a small chance they could get it routed.  But, the large ISP with 
> a /10 under this system gets a nice juicy /13 or so (more than 400,000 
> addresses).
> However, with 24 x-large organizations (many of whom have more than a 
> /8, not just a /10 under their control) vying for this remaining /9, 
> at 10%, I don't think you'll get anywhere close to a year.
> You do raise some interesting questions.  It would be good to get a 
> sense from the community of:
> 1.	How long would the community like rationed IPv4 to last?
> 	A.	Brick Wall -- allocate as we have until it's gone.
> 	B.	Ration by some mechanism to last 1 year
> 	C.	Ration for 2 years
> 	D.	Ration for 5 years
> 2.	How would the community prefer to ration?
> 	A.	Percentage of existing space
> 	B.	Nobody gets more than a /x every 6 months
> 	C.	A graduated table based on your org. type:
> 			(example only:
> 					x-large		<=/18 every 6 months
> 					large		<=/19 every 6 months
> 					medium		<=/20 every 6 months
> 					smaller		<=/22 every 6 months
> 			)
> 3.	How does the community feel we should balance the conflicting needs
> 	of large quantities of addresses for large ISPs vs. large numbers of
> 	smaller organizations needing fewer addresses each?
> I don't really have a strong opinion on how this should go.  But, I think 
> it is important we have the discussion and come to a deliberate decision 
> as a community in the near future.
> Owen


Great points.  I should have done a few calculations before throwing out a percentage, but I agree we are looking at low single digit percentage.  I like the questions and options you lay out for the community, and I will provide my preferences and opinions:

1. B/C - I think a reasonable extension of IPv4 availability would be 1 to 2 years.  More than that and you may introduce a reason for organizations not to move toward IPv6 (especially when paired with generous transfer policies that would likely be surfacing at the time of IPv4 rationing).

2. C - A Graduated limit on allocations offers exactly the balanced limitation that I would hope for in this kind of policy.  ARIN's mandate is unbiased with respect to large versus small organization, and so any policies should continue to support relative needs-based allocations.

3. Another way of balancing the conflicting needs is to partition the last of the IP address space so that a portion is reserved for organizations with different address requirements.  For example, roughly 50% could be reserved for the extra-large allocations, and the other 50% reserved for all other allocations, or something along those lines.


You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
Please contact info at arin.net if you experience any issues.

More information about the ARIN-PPML mailing list