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

[Paul Vixie]

# ..., I'd like to suggest that this is neither the time nor the place to be
# doing architectural development.  Yes, there are a myriad number of delicate
# issues with the assignment of PI space under the current routing
# architecture.  If we cannot find a reasonable compromise under those
# circumstances, it is only rational for us to consider whether or not that
# architecture is practical.  If we find that the architecture is impractical,
# then rather than solve it here, it makes sense to bring the issue to the
# appropriate forum (IETF).

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.  Whether
something is practical isn't apriori knowable, it depends on the level of
desperate effort that its practicioners are willing to put into it.

# It has been suggested that we are in a situation where we have no choice
# except to deploy IPv6, and thus this question is moot.  I'd invite those
# folks to consider the amount of investment still to be done in IPv6 and
# whether, in the long run, any time would be lost by simply skipping over
# a broken incarnation and the stutter step associated with an aborted,
# failed deployment.

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.

(Thomas Narten correctly pointed out that the rapid renumbering requirement
wasn't written down anywhere... I guess it felt "too obvious" to bother
writing it down... Ouch.  I'm hoping Bill Manning's archives are better than
mine on this point.)

That having been said, I agree that it's out-of-scope for the PPML community
to invent technology to make IPv6 more deployable.  At best we can invent
allocation rules and processes to make it more deployable.

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.

To that end, I support 2005-1 as written.