[arin-ppml] Fairness of banning IPv4 allocations to somecategoryof organization
Owen DeLong
owen at delong.com
Mon Oct 12 08:47:06 EDT 2009
On Oct 10, 2009, at 12:19 PM, Milton L Mueller wrote:
> I haven't intervened in this debate even though it is a highly
> interesting one. One element seems to be lacking from the
> discussion. To me, it is an incredibly clear demonstration of the
> complete breakdown of the needs-based allocation principle as soon
> as scarcity arises.
>
Or not...
> What Michael Dillon has been saying, in effect, is that
> organizations that can demonstrate a perfectly viable technical
> "need" for IPv4 addresses shouldn't get them.
>
And the rest of your argument proceeds from the assumption that this
is fact. Personally, I don't
think such a policy is a good idea. I think that it is far more
appropriate to continue issuing
IPv4 addresses on a needs basis until we run out. The community has
had plenty of notice
that the solution to address shortage is IPv6. In the meantime, I
agree that abandoning our
existing needs based criteria is not a good choice unless a clearly
better solution is
available.
I do not believe that a market based solution is superior, nor do I
believe that increasingly
invasive classification and prioritization is superior.
> Maybe this is so obvious to all of you that it's going unstated, or
> maybe its an unstated assumption and it will clarify debates going
> forward if this is more openly acknowledged.
>
> If you abandon "demonstrated need" and are _not_ willing to use
> prices or some other neutral, market-based rationing principle, then
> all that is left is finer and finer classification and
> prioritization of specific uses. And down that road lies a form of
> ever more intrusive central planning. I.e., the RIR has to step in
> and decide for organizations whether it is better for them to base
> their plans on IPv4 or to re-engineer their plans based on a
> migration to IPv6.
>
Yes, in my opinion, this is one of the best arguments stated so far
for preserving the existing
needs-based system rather than careening off into market or central-
planning systems.
> However you resolve such a debate, let's at least openly recognize
> and acknowledge that "need" is gone as a rationing principle.
>
Rationing only applies when you are attempting to forestall the
depletion of a scarce resource.
That is not necessarily the case here. While forestalling IPv4 runout
would be convenient for
many, it's not likely to be successful over a significant period of
time, and, there is an alternative
that is gaining acceptance and does not have the address scarcity
issues associated with
IPv4.
This reminds me of a recent discussion with a flight instructor about
a maneuver known
as a canyon turn. A canyon turn is an extreme maneuver designed to
make a course
reversal in as little lateral distance as possible. It is so called
because it is primarily
used in a situation where the pilot has flown up a canyon and cannot
climb above
the walls of the canyon.
The student asked "What do I do if there is not enough room to make
the canyon turn?"
The instructor replied "Then the accident has already occurred. The
pieces just haven't
stopped moving yet."
IPv4 runout is inevitable. No proposed rationing, reclamation, or
market scheme will change
that fact at this point. We may be able to change the date by small
amounts, or, we may be
able to change the speed at impact, but, the event will happen.
Returning to the aviation analogy, if you are faced with such a
situation, you really need to
know when there isn't enough room. A controlled attitude trip through
the trees will destroy
the airplane and likely injure the occupants, but, is survivable in
the vast majority of cases.
On the other hand, a canyon turn (60 degrees of bank, flaps extended,
and the elevator
pulled back hard (nearly to the stall point of the wings)) is likely
to result in a very deadly
impact if you don't have enough room.
With IPv4 runout, we just don't have enough room for even a canyon
turn. Let's land
straight ahead as best we can.
Owen
More information about the ARIN-PPML
mailing list