[ppml] NANOG IPv4 Exhaustion BoF

Geoff Huston wrote:
> ...
> So one can either say "the future is this big scary unknown place that
> we shouldn't tamper with", or you can do what you can to mitigate some
> of the more destructive potential outcomes and attempt to encourage
> some
> of the more beneficial ones. Now if your aim is to make IPv4 last
> forever then obviously we disagree about what is a net beneficial
> outcome for this Internet.


"this big scary unknown place" is one of the economic factors that has lead
us past the point where we could avoid the looming pain. There is a cost to
learning something new, and those that have not learned it will not be able
to justify their high salaries in the new world order. This makes it very
self-serving to seek out any excuse to maintain the status quo. 

The warped part of most of these discussions is that they are only concerned
with the address-assignment/routing part of the system, and they completely
ignore the costs associated with deploying and managing the
end-system/application environment. The perception that the edge network can
live with only one version is propagated by those in the core that have no
concept of what it costs at the edge. There will be an extended period of
overlap, despite exhaustion of the free pool. The space will fragment, with
or without transfer policies, and the cost for operating the IPv4 network
will rise. This will happen no matter what the price is for a block of
space. 

While I agree there needs to be a mechanism to keep the records straight, it
is not at all clear that there is any way to impose a historical perspective
of 'need' onto a trading market. For starters, the measure of 'need' is not
based on the amount of space, it is on the ability to get that routed. Just
as now, a site may need a /30, but if routing says that the smallest thing
that will pass a filter is a /24, then the site will not pass the test
without inflating their claim to the smallest routable block. If you are
really going to spend time on designing a market, design a market for
routing slots, then the addressing market will take care of itself.
Unfortunately, the RIRs are not in the business of routing, and the big ISPs
are more interested in killing off the little guys than building a market
that would sustain competition. BGP based TE is a prime example of
artificially raising the barrier to entry, and complete fragmentation of the
IPv4 pool only magnifies that effect.  

Before spending too much time on an optimal market design, look at the
winners and losers in each scenario, then look at who has influence over
which scenario gets picked. When you find the match between those with
influence and the scenario where they win, you will know which path we are
on...

Tony