[ppml] Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites - Last Call

[Vince Fuller]

> > Implementing this policy in the hopes that it will spur adoption of ipv6
> > smacks of the "tail wagging the dog", of doing *something* rather than the
> > *right* thing so that "progress" can be demonstrated. Such an illusion of
> > progress will only alleviate pressure to fix the real flaws in ipv6 (i.e.
> > co-mingling of the endpoint identifier and routing locator in a single
> > "address" field) that render it incompatible with the goal of a scalable
> > routing system.
> 
> Quite the opposite, actually.  Ten years of feckless work on the
> routing problem by the IETF has yielded zilch.  Perhaps the specter of
> routing table growth caused by actual adaptation of v6 will break the
> logjam.  Then again, maybe it will take a crisis like it did last time
> (CIDR) but the risk (or certainty if we're successful) of a crisis in
> the future is not an excuse for not moving forward.  Thomas Paine said
> "Lead, follow, or get out of the way".
> 
> By the way, speaking of "illusion of progress", every time I see a
> presentation on a paper solution with no reference implementation
> (shim6 anyone?), I have OSI-era flashbacks.  It's frankly
> embarrassing.

The IETF process failed ten+ years ago when a "solution" was picked that had
been clearly shown to be inadquate at solving the known, hard problems.
Since then, politics have triumphed over technology and all efforts to
design a real solution have been effectively surpressed in the name of
consensus-building around ipv6. There are some people, far brighter than me,
who continue to try to fight the good fight, but the entrenched interests
around ipv6 make that difficult-to-hopeless.

(OK, now I'm sure I appear to be a conspiracy theorist, so this will be my
last posting on this topic)

Without a clear message from the IETF contituency that ipv6 is fundamentally
flawed to the point of not being worth the time, effort, and expense of
deployment, there is exactly "zilch" chance that the established path will
be altered. "Moving forward" down a path that inexorably leads to a crisis
vindicates those that deny the existance of a problem (think global warming
here) while the existance of the problem is masked by the early, shallow
slope of the growth curve.

> How about a REAL solution from the IETF with a concentration on the
> "working code" part of "rough consensus and working code" so that we
> can get on with *repealing* 2005-1 after it's no longer necessary?

Without a commitment to the creation of a solution that obviates 2005-1,
this is a mistake. If there is one thing we've learned from the development
and deployment of CIDR, "temporary" solutions aren't, especially when there
is no clear direction to the "permanent" solution or even a clear
definition of the problem to be solved.

The Internet faces pressure for change today: the exhaution of the 32-bit
IP address space. Spending billions of dollars to deploy a band-aid that
will only trade this crisis for another one a few years down the road hardly
seems like a wise investment, especially when one considers that the
installed base, and thus the cost to deploy a fork-lift "upgrade", will be
orders of magnitude bigger in the future. Fix ipv6 now and you inconvenience
a few early adopters who have to roll-out new implementations; fix it later
(assuming there is a wide-scale deployment and transition from IPv4) and you
face a second, far bigger, multi-billion-dollar transition. Is that really
the best plan that the community can conceive? IMHO, disappointing, to put
it mildly.

In case it isn't obvious, this is a vote *against* adopting 2005-1.

	--Vince