[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 21:20:13 EDT 2012
>>
>> 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.
> You keep describing greater efficiency. And if the greater efficiency comes at the cost of extra inconvenience and effort, obtaining efficiency usually entails some effort.
>
You define efficiency by radically different criteria than I do.
To me, greater efficiency would mean providing the same capabilities with reduced consumption. That isn't what is happening.
What is happening is providing less and less capabilities to more and more users at greater and greater cost. That's pretty much my definition of the opposite of efficiency. The word I use for that is pain. Ever increasing pain.
> It wont get better by getting rid of ipv4 availability faster.
>
It will get better in the short term and it will not get any worse than it is going to be anyway in the long run. In fact, it will actually get worse by stretching it out because instead of providing good services and capabilities to as many as we can and then providing no services and capabilities to new users short of migration, your strategy leaves us continuing to provide less and less to more and more for longer and longer.
>> What I'm arguing against is the fact that people are actually suffering now.
>
> And how does your proposal help?
>
It reduces short term suffering.
>> 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.
>
> Back to the spade. IPv4 is lasting too long.
No. IPv4 is not lasting too long. The perception that there is IPv4 available is lasting too long. In reality, we've been operating under an IPv4 shortage for a long time already and continuing to draw that out longer and longer is causing additional harm.
>>
>> 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.
>
> These same managers would quite prefer a dollar tag, because the technical esoterica is actually much scarier to them.
>
> Most of them would rather ask one question and be told one answer when trying to obtain addresses.
>
> How much will it cost?
>
Well, the sooner there is no perceived free pool, the sooner they can have their wish. However, that's really not my goal here.
My goal is to stop punishing those who are running networks today (and by extension their customers) for the sake of preserving an IPv4 free pool to dole out little bits of rationed IPv4 to organizations that are currently vaporware or less and may never materialize.
>> 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.
>
> So why are you trying to hurry up RIR depletion? Are you looking forward to these consequences?
>
As I said, I'm not trying to hurry RIR depletion, I'm trying to reduce the extent to which we artificially slow it down slightly.
> Because they are not happening now.
Actually, they are. Just not on as noticeable a scale as they will later.
>> Have you thought through to the logical conclusion of the damage today's policy is causing today in the real world?
>
> Why cant you simply state what the damage is?
>
I have stated it several times. To make it very very clear:
The state of end-user connectivity today is a chronic provision of less and less useful service to more and more people with worse and worse constraints which further hobbles application development, innovation, and product generation. We have entire industry segments built around nothing but make-shift ways of overcoming these unnecessary artificial limitations.
Continuing to make the constraints and limitations worse in order to allow organizations to avoid making necessary changes is causing harm not only to the organizations that are avoiding the necessary changes, but, to everyone else as well.
We're heading for a world where end users will be connected through CGN gateways to gain what you would call "further efficiency". That's akin to calling the sharing of needles among junkies "greater efficiency" in their use of needles. I suppose, technically the term could apply, but, I would argue that the reduced public health cost of providing clean needles is far more efficient than needle-sharing.
Rationing IPv4 out to extend the free pool really is having a similar systemic effect at this point.
>> Have you thought through the silo effect
> Whats that?
>
> Be specific.
>
The APNIC region is moving forward with IPv6. RIPE is moving forward with IPv6. North America preserving a prolonged period of IPv4 dependency with more and more degraded IPv4 service instead of moving forward to IPv6 will isolate us into our own little broken internet silo. Unfortunately, because the internet is global, this will not only cause the local self-inflicted damage for which we can blame no one but ourselves, but, will also increase costs and degrade the user experience world wide as folks in those regions that have already migrated to IPv6 are forced to continue to cobble together ways to communicate with our dysfunctional region.
>> and the damage that is already causing?
> What damage?
>
> Be specific.
>
I have been very specific above and earlier in the thread.
>> I think that depends on the price at which they seek to monetize.
> Which in many markets, is $15 for 5.
$3/IPv4 address is actually cheap given that Micr0$0ft was paying $11/IPv4 address and I hear that whoever bought the registrations from Borders paid even more.
> If the price is too high, it will spur IPv6 adoption pretty well.
>
> Your gambling without even understanding your odds.
Huh? Be specific.
> 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.
>
> They wont be rare, they will be a member of the Xlarge club, and they will have a competitive advantage.
>
If the providers that have available IPv4 addresses for new and growing customers are not rare, then, they have no competitive advantage from this fact. The competitive advantage of which I speak specifically comes from the fact that having available IPv4 addresses is rare. As long as a bunch of providers have available IPv4 addresses to provide services, there is still a competitive landscape for those services.
>>
>> 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.
>
> Since that would not be in their best interest, one can assume they will make every effort not to do so intentionally.
>
>>
>> 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.
>
> FTFY
>
> Attempt to monetize IPv4 addresses at market bearing prices so that continuing efficiency of addressing adequately replaces
> the RIR system as the new NON-free pool for as long as they can benefit from the extra costs that they can impose.
>
I'm not sure how you see that working. I'm also not sure what FTFY is supposed to be an abbreviation for.
>
>
>>
>>
>> If they behave in some combination of those three ways, then, the end result is still the same...
>>
>> 1. IPv4 runs out.
>
> No it doesnt. There is the same amount of finite IPv4 as there always was. And the holders of the vast majority of it will be sitting pretty.
The ratio of IPv4 addresses to demand continues to shrink, if you prefer.
Since that ratio is already well below 0.25 (yes, I believe there are at least 4 addresses needed for every one available today) and demand is continuing to grow, it boggles my mind how you can deceive yourself into perceiving this as realistic.
>> 2. People faced with the rising cost of IPv4 and supply problems obtaining IPv4 addresses will turn to IPv6.
>
> You hope. Where is the evidence of that occurring, say, in the regions that have already run out?
http://www.cidr-report.org/cgi-bin/plota?file=%2Fvar%2Fdata%2Fbgp%2Fv6%2Fas2.0%2Fbgp-active.txt&descr=Active+BGP+entries+%28FIB%29&ylabel=Active+BGP+entries+%28FIB%29&range=--OR--&StartDate=1-jan-2010&EndDate=15-mar-2012&yrange=Auto&ymin=&ymax=&Width=1&Height=1&with=Step&color=auto&logscale=linear
There are a couple of steps in there, but, a market upswing after April, 2011 and another upswing appears to be starting.
(Upswing being used to describe the curve turning towards vertical from the linear average).
Note, the overall linear trend is markedly upwards and other than some very short-lived anomalies, tends to be increasing towards vertical overall as well. In fact, a parabola could be a relatively close curve fit with a slight curve inwards from about April/11 to December/11.
I'd say that's pretty strong evidence, actually.
>
>> 3. IPv4 deaggregation will make IPv4 routing more and more expensive to maintain.
>
> This is very possibly inevitable and this draft policy has nothing relevant to bear on this issue.
>
Not at all true. Forcing providers to get 4x as many prefixes per year has a lot to do with IPv4 deaggregation.
>>
>> 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.
>
> This is the crux of your rational, out in the open.
>
I think you mean rationale.
> Kill off IPv4 to drive IPv6 adoption.
>
That isn't all what I said. What I said was that pain is inevitable. We can move the pain around. We can increase the pain in intensity and in duration.
The only permanent relief available is IPv6 adoption. However, in terms of what we can do with IPv4, we can only provide small amounts of relief to some entities. However, to do so, we must inflict proportionately (or possibly disproportionately larger) amounts of pain on other entities.
> Except it is immoral, improper, and inaccurate.
Funny, that's pretty close to my view of continuing the 3-month policy.
>
>>
>>
>>> 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.
>
> That is great. So how is ARIN free pool availability negatively affecting them? And we both know that they are nowhere close to where they need to be and I dont believe we want to be in their position any sooner that we have to.
This is described in detail above.
>
>> 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.
>>
>> Owen
>
> Your analogy is flawed, even more so than most.
>
> 1) IPv4 is not consumable. It is recyclable.
>
It is only recyclable if you tear down the service that is depending on it.
> 2) When the doors were wide open, even when we well understood the coming scarcity, the hoarders grabbed their fill, repeatedly.
>
I don't share your belief here.
> 3) Nobody is padlocking anything. Gluttony is simply being discouraged.
>
I don't share your belief here, either. There is a very real cost to an organization to go through the ARIN process for getting more addresses. That cost is increasing as a result of this and other policies. One of the things I do is provide consulting services helping organizations to get their IP addresses from ARIN. The number of hours I spend on each of these has gone up as a result of other policies. Quadrupling the number of times an organization needs to pay someone to do this further increases those costs.
That is the economic equivalent of a padlock.
> 4) We absolutely know that under the previous burn rate people will not be able to get IPv4 from ARIN when they need it, prior to IPv6 being a real option for them. Under the current burn rate, there is a much better chance, a reason to hope again that this time we will make it in time.
>
We absolutely know that under the current policy, people who need IPv4 today are not able to get it from ARIN in a cost-effective manner. You have to factor the costs of processing an application into the thinking on this.
> Where it really falls down.
>
> The rational course to coming scarcity is not to consume as much as possible prior to its arrival, it is to preserve and restrict your consumption to the most efficient level possible that extends your longevity, even at a cost of a hungrier belly.
>
Agreed. We were at hungry bellies at 12 months with current policies. Now, we've moved past that towards starvation.
> When a community of individuals enters the dynamic, things change. The communities rational course is still efficiency. However, It is different for the individual, where the rational course is to consume as much as possible from the communal resources, and to preserve them in reusable and recyclable form for when there are no more to be had. And if such behavior generates a marketable surplus, so much the better.
>
Which is one of the many reasons I'm not thrilled about having an IPv4 market. However, it seemed less damaging than the available alternatives.
> The community is best served by limiting the individual tendency for this kind of behavior.
>
Which we were already doing before we set the allocation window to 3 months and which doesn't go away with putting it back to 12 months until we get closer to runout as intended.
> I got a better analogy, a car one! (The consumption aspect is still problematic, but gasoline as a resource is more renewable [at least for now])
>
> The needle has just started hovering above the E, past the 1/8th mark but still on the gauge line. The low fuel warning has not come on yet, but you dont recall if it comes on at 1 gallon or 2. You are on the highway in a mountaneous region. Its late at night and you last passed an open station hours ago. Some exits have signs posted for Service stations, but the last few you tried were all closed, a false hope. You know that in about 100 miles there is an open 24hrs station, right on the interstate, in the next state, where the prices are significantly cheaper. Your car is rated at 35mpg highway, but your driving experience is more usually at 22-25.
>
> I suspect most of us have been in situations very much like this one.
>
> Do you:
>
> A) press the pedal to the metal hoping to get as far as you possibly can, so that your nerves have to deal with this painful suspense for the shortest time possible. I cant drive 55.
>
> B) Drive as judiciously and as efficiently to get as far as you possibly can, using the terrain and keeping within your rpm/torque efficiency sweet spot, hoping you have closer to 3gals in the tank and that you will make at least 33mpg.
>
> [B1) Unload the wife and kids and all the luggage and hope you can come back for them with your increased fuel range]
>
> C) Drive as you normally do and hope for the best. Maybe you will make it, maybe you wont, maybe the next exit's service station will be open, maybe a passerby will see you stranded and give you a lift, maybe you have AAA.
>
> D) Detour through the empty streets looking for somebody awake who can point you to an open station and hope you dont get lost and stranded.
Your analogy is, IMHO even more deeply flawed than mine.
First, it generates the illusion that there are no other consequences to selecting option B (which makes it ideal for pushing your viewpoint, I realize). To match the situation with IPv4, selecting option B would have to include getting a ticket for driving too slow from every state trooper you passed along the way and include the additional gasoline consumed in the process of each start and stop process because of it.
When you consider those additional aspects on option B, using option C until the indicator light comes on (which may actually be a decent analogy for this proposal) and then switching to option B may well be an attractive alternative. Especially when you consider that under this proposal, the light comes on at 1 /8 remaining in the tank and we are currently at more than 7 /8s in the tank.
Owen
More information about the ARIN-PPML
mailing list