[arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool

Owen DeLong owen at delong.com
Thu Mar 15 16:31:56 EDT 2012

On Mar 14, 2012, at 11:35 PM, Joe Maimon wrote:

> Morizot Timothy S wrote:
>>> -----Original Message-----
>>> Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool
>>> Draft Policy ARIN-2012-4
>>> Return to 12 Month Supply and Reset Trigger to /8 in Free Pool
>> I'm very much in favor of a policy change that will speed ARIN runout to bring it more in line with APNIC and RIPE, but with the IPv4 resources going to those who are actively using them.
>> I remember the world of scarcity and silos Geoff Huston recalls and am concerned that an extended period of time with ARIN significantly out of step with the other two large RIRs could easily lead to some of the scenarios he describes. We must make the transition to IPv6 or end up with a very different Internet than the one to which we've become accustomed. And the longer ARIN draws out its runout, the greater the risk to that goal.
>> As we've been seeing on arin-discuss today, an attitude that IPv6 can be put off and a lack of urgency about transition seems to continue to pervade our region. If I saw a long-term view driving IPv6 adoption in our region, I would think it would be a good thing to slow our rate of IPv4 consumption to make our transition less painful. But I don't see that. Instead, I just see organizations continuing to put it off until they are forced to act.
>> Scott
> How about someone be specific, and point out what kind of specific issues that the ARIN region may experience due to its expanded ipv4 availability, thanks in no small part to a decreased burn rate and greater efficiency, brought to you by three month soft landing?

I will start by specifically pointing out the flaws in the above assumptions...

First, the assumption that the three month soft landing has caused greater efficiency and that the decreased burn rate has resulted from that greater efficiency and not from other factors.

In reality, that decreased burn rate represents not greater efficiency, but, greater pain inflicted upon organizations struggling to get by with what they have because the effort involved in obtaining 3 months worth of address space and the costs associated with doing so exceeds the revenue those addresses are likely to produce. It represents real customers suffering under degraded services and increased pricing as a result. That's not greater efficiency, it's just greater pain.

> Misery loves company?
> If all you have to whine about is that people deserve to suffer for not racing to adopt IPv6 and by golly we are going to make sure they do, I am really tired of hearing that.

This is a very interesting way to characterize my argument. What I'm arguing against is the fact that people are actually suffering now. Even people who have adopted IPv6. Not because they failed to adopt IPv6, but, in part because others have failed to do so, but in larger part because our current flawed policy is inflicting additional unnecessary pain in the name of making the free pool last mythically longer.

> And you are not thinking things through to their rational end.
> Do you really think that IPv4 address availability and consumption will dry up and vanish right along with RIR pool depletion?

Quite the contrary... However, when the RIR pools are depleted, the cost of failing to deploy IPv6 will start to be expressed in terms that seem to be better understood by managers, whereas today they are expressed in technical esoterica that does not seem to get through as well. Further, the post RIR depletion fragmentation of the address pool and subsequent consequences to the routing table will serve as a further driver. I have very much thought this through to its logical conclusion.

Have you thought through to the logical conclusion of the damage today's policy is causing today in the real world? Have you thought through the silo effect and the damage that is already causing? Have you thought through the extent of the damage to the concept of ubiquitous network communications world wide that will evolve from north america being so completely disjoint from the rest of the world?

> Consider where the vast majority of IPv4 addresses will be post ARIN runout. Hint: It is where they already are.
> What do you think it will do to IPv6 adoption, when a couple dozen organizations control the vast majority of IPv4 - and get to monetize those holdings in ways we are only seeing the beginning of?

I think that depends on the price at which they seek to monetize. If the price is too high, it will spur IPv6 adoption pretty well. If the price is low enough, it will create some minor additional costs associated with the migration and delay it by a few months or maybe even a year or two.

> Do you really think the suits at these organizations would be so eager to work against their own immediate interests?

This conclusion is opaque to me. I absolutely expect them to work in their own interests. However, I see their interests falling into one of three behaviors:

	1.	Hoard what they have and try to be the rare provider of IPv4 that still has addresses to give in order to gain
		competitive advantage.

	2.	Attempt to monetize IPv4 addresses at such a high asking price as to strongly motivate potential customers
		to use IPv6 as an alternative wherever possible.

	3.	Attempt to monetize IPv4 addresses at low enough prices that a one-time redistribution of addresses replaces
		the RIR system as the new free pool until the readily available monetizable addresses are redistributed and
		we are faced with runout once again.

If you see some other behavior as being in their interests, please do tell.

If they behave in some combination of those three ways, then, the end result is still the same...

1.	IPv4 runs out.
2.	People faced with the rising cost of IPv4 and supply problems obtaining IPv4 addresses will turn to IPv6.
3.	IPv4 deaggregation will make IPv4 routing more and more expensive to maintain.

If you have other logical conclusions from these actions (or different behaviors), please do tell.

> Or do you eagerly anticipate that all these pain factors combined will generate enough network effect to bootstrap IPv6?

I don't know that I would say "eagerly", but, I do anticipate that these pain factors (which, by the way cannot really be mitigated, only moved around from place to place a little bit) which can only continue to increase will increase until such time as we generally deploy IPv6.

Faced with an ever-increasing level of pain becoming ever more widespread and continuing to spread and to increase until such time as IPv6 is widely deployed, it is utterly absurd to believe that making that process last longer will somehow reduce the level of pain. All it can do is transfer more of the pain to some organizations in order to reduce or postpone that pain for other organizations.

> How are things working out in the depleted regions? Or is that ARIN's responsibility as well?

The depleted region is still in the transfers are available stage, but, even so, there is a significant increase in IPv6 deployment efforts in that region. There is also a significant increase in IPv6 deployment efforts in the RIPE region which, while it hasn't run out yet is close enough that it is pretty clear they will be the second region to run out.

> It is completely irresponsible to gamble in this fashion - even were the ends to justify the means.

I guess that depends on how you perceive gambling. I think it is completely irresponsible maintain a padlock on the granary in front of all the hungry villagers and post armed guards to watch them starve slowly gambling on the likelihood that more villagers arrive next month.

You seem to think it is irresponsible to feed the people who are hungry today gambling on the possibility that the number of people starving next month will be about the same. 

I prefer to feed the people in front of me at the risk that more people MIGHT be hungry tomorrow vs. keep people hungry today based on such an uncertainty.


More information about the ARIN-PPML mailing list