[ppml] 2005-1:Business Need for PI Assignments

Randy Bush randy at psg.com
Wed Apr 20 16:42:44 EDT 2005


*nobody* likes to renumber, end users, isps, ...  and some of us
speak from serious experience doing so.

no organization wants to rely on any other organization for their
address space.  when viewed through very small glasses, it makes
perfect business sense.  end sites don't want to rely on isps.
isps would prefer not to have to go through the rirs.  rirs would
prefer not to go through iana.  and the iana does not want to be
responsible to anybody.  all nice, but give me a break.  this is a
global network; wear larger glasses.

the promises of easy renumbering etc. in ipv6 were total bs.  the
promises of routing table limitation in ipv6 have turned out the

no one who has been around the block is willing to bet one bowl of
ugali that the ivtf or anyone else is going to come up with routing
and multi-homing magic in the next five years.  some of us doubt
the problem will be solved at all usefully for real operations for
far longer than five years, though we would dearly and desperately
love to be proven wrong, and are contributing to the effort to
prove ourselves wrong.

no one actually knows, in a measurement sense, the elasticity of
the global bgp routing system.  but folk who are responsible for
budgets, engineering networks, and deploying routers do know that
being able to have enough horses to haul the load is having a
serious impact on capex, and are not made happy at the thought of
rampant routing growth on either their margins or on the technical
stability of the internet.  those of us with grayer and/or less
hair have actually seen real global routing crashes, and don't want
to explain them to the nyt, dhs, or clueless power grabbers in
well-cut suits again.

folk actually measuring ipv6 deployment know that the actual *use*
of ipv6 is negligible at best, in north america, south america,
europe, africa, oceania, and asia all rolled together.  read the
previous sentence again, actual use of ipv6 is negligible at best.
likely there are more ipv6 address assigned than there are packets
pushed in a day.  it's still research lab stuff.  

and we all know in our black little hearts that the most
significant factor in this is that ipv6 does not really offer the
u$er anything that they can perceive sufficiently to spend money to
start moving actual use or operations to v6.  the end user does not
know or care about address space, renumbering, nats, ...  they just
want their mtv, and are only willing to pay $19.95 a month for it.
in a sense, this is good, users should not have to care about all
the stuff we have to care about; you should not have to be a
mechanic to drive a car.

sure, we need to allow folk who really need and can justify (e.g.
see drc's msg of earlier today) end site allocations to get them,
both in v4 and v6, and in a consistent manner [ note that i have
been pushing micro-allocation in ipv4 for many years, with long and
strong resistance from cjw, and other folk now becoming more
liberal in the v6 world ].

but, as no one has yet to come up with any of the promised magic,
we really have no basis to predict the future other than some
epsilon off the lessons of the past.  and some of those lessons are
  o routing tables do make global messes when not treated with
    prudence and conservation.
  o when there is user and business incentive to do so, sites,
    isps, users, ... will go through the pains of dealing with
    rirs, provider space, ...
  o it is hard to find a good compromise in this space, but we have
    to do so, and have been doing so for a long while; do not
  o but imprudent blow-out of any one (or more) of the dimensions
    in tension, at the expense of the others, will lead to articles
    in the nyt, wsj, and people who wear strange clothes.

this is not easy.  there are no simple answers of which i am aware.
and progress will not be fast, certainly not enough to be a
marketing force for ipv6.  but, history tells us that if we are not
careful, we pay big-time in the long run.


More information about the ARIN-PPML mailing list