[ppml] Version think... was: alternative to 2005-1

[Tony Li]

Paul,

> It's no less practical than IPv4, and look how much bigger the current IPv4
> internet is than could be guessed at by _its_ original architecture.  

It actually is significantly less practical, in the sense that the
routing subsystem overhead for IPv6 is much higher on a per-prefix basis
than it is for IPv4, and because so much of the v6 topology is simply a
subset of the v4 topology.  Since both versions draw from the same
finite pool of routing subsystem resources, one has to ask whether those
resources are being most efficiently exploited by adding v6 in its
current state.

It should also be noted that the v4 architecture blossomed and grew
precisely because the architecture was adaptable and fungable, with the
blessings of the IAB precisely because they understood that mutation was
necessary for evolution.  The reticence of the current IAB to accept
reality and morph to meet the need results in an architectural rigidity
that dictates that v6 will never be more than exactly what we have today.


> The decision to poor good money after bad on IPv6 was made early on, and then
> re-made, and will yet be re-made, many times over its lifetime.  I'm struck by
> the fact that while all practitioners of routing knew that "without rapid
> renumbering, IPv6 is undeployable", the IAB did not know this and no doubt
> still does not know this.  Perhaps the fundamental flaw in this architecture
> came about when the RIR communities were _not_ directly involved in vetting
> it, and if so, simply passing the problem back to the IETF will at best cause
> the same errors (or compatible errors) to be repeated.


The point that I am trying to make is that right here, right now, is an
opportunity for the RIR community to vet the result, and return it for
revision if necessary.


> In that sense, there is hope.  While we expect the absolute number of
> endpoints to grow under IPv6, most of the growth will be in handhelds and
> TV remote controls other locked-in devices, not in home LINUX servers or in
> multihomed enterprises.  A policy like 2005-1 that allowed the dwindling (as
> a share of the total) number of endpoints to receive multihomable/rehomable
> PI space might actually be "all it'll take" to "solve" this whole problem.
> Sadly, we won't know what it'll take until we get there or get close, and
> as long as we reject PI requests for multihomable/rehomable space, we're
> holding IPv6's head underwater.  2005-1 is experimental, with a limited number
> of total allocations, and a sunset clause.


My concern is that the proliferation of wireless technology, the
continued rapid deployment in countries that are population dense and
Internet poor (e.g., India & China), the increasing reliance of all
sites on Internet technology with the subsequent increased interest in
multihoming point me to a rapid increase in multihoming, not a decrease.
If this does happen while we lack a real multihoming solution, we will
end up in a situation of imminent implosion very quickly.

I should note that fixing this problem is NOT impossible.  The IETF has
the technology in its archives to remedy these issues.  I know that
arguing about what to do and how to do it will take some years, but the
actual implementation of what has been suggested (e.g., 8+8,
address-agile transport protocols) seems like it still relatively minor
compared to the amount of work still to be done in deploying v6.

Tony