Lazy network operators

> ...
> anyway, there will absolutely be NAT in ipv6 enterprise networks, but the
> reason for it won't be a shortage of globally unique address space.

Hmmm, or rather, there just wont be any demand for IPv6 deployment, at
least from the edges (consumers, small/medium networks). Why bother
changing if, despite the (almost indefinitely) availability of sparse
address space, one can not claim a tiny piece as ones' own? Which is
IPv4's only problem, at least as seen from the edges.

ipv6 solves problems that large providers have, or speculate that
they'll have, and at some point the edge/enterprise will adopt a dual
stack approach just to be reachable by 3G-etc, assuming that 3G-etc
ever stops having the 6to4/ISATAP/etc features it'll have to have
before it has v6 at all. so, theoretically, there's a tipping point
where dualstack or even v6-only will make sense even to someone who
refuses the lockins and stays with a NAT-based or proxy-based design.

Provider independence (to some degree, even by DNS A6 or otherwise)
for all should have been IPv6's biggest selling point. It doesnt have
it, judging by multi6 it's not likely it ever will, and hence it's
similarly unlikely there ever will be any real demand for v6.

provider independence is not a clear virtue in the eyes of those powerful
enough to sway vendors toward implementation -- that is, people with
billion dollar annual capital budgets. it may not even be a clear virtue
in the eyes of the edge/enterprise consumers who want to avoid lockin,
since they've gotten comfortable with NAT and proxies over the years, and
since in a post-CIDR world, everybody knows that the equilibrium between
can-route and can-qualify has to be more toward can-route and the people
who can't-qualify just need to make other arrangements.

i dearly wish i had understood this market equation at the time i was
pushing for A6/DNAME, since at that time i stupidly thought that this was
a technical problem and the people on the other side of the argument just
didn't understand the technical issues well enough. (oops.)