[arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
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,
> 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
> 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.
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