--On Friday, November 22, 2013 11:46 -0500 Noel Chiappa
<jnc@xxxxxxxxxxxxxxxxxxx> wrote:
> > CGNs are expensive. Why would people prefer to maintain
> them if the > IPv6 infrastructure was working?
>
> Cheaper than customer service calls.
>
> Even if the ISP's system does something clever like allocate
> the customer only an IPv6 address if it only sees IPv6 traffic
> from them, if the customer tries to reach an IPv4 only asset,
> the ISP is going to have to have a NAT device of some kind
> anyway (else customer service calls will ensue). Once you have
> to have a NAT anyway...
In addition, an important part of the customer service cost
story is the training and skill level required of the support
people. Having customer service support for two network
technologies (or, of you prefer, two networks) is vastly more
expensive than supporting one. And, once one figures out how to
train and organize people to support CGNs, much of that cost is
sunk: while there is turnover and one therefore has to keep
training new people, the costs are entirely different from
retraining everyone again to support a pure IPv6 network.
Looked at purely from the standpoint of economic incentives,
forklift upgrades to an end state are an expensive and risky
step. The right time to do one is as early as possible after
the target technology seems stable and the transition strategy
seems clear. And the right transition strategies to promote
that are actual transition strategies, not "keep bad things from
happening for a while longer while we make a plan" ones. As
soon as one goes significantly down the path of delaying making
real changes, those strategies tend to take on their own inertia
because, on any given day, it will almost certainly be cheaper
to put up with the problems they cause and continue tolerating
the pain (both of which one has presumably gotten used to) than
make a major change. One can argue that those delay mechanisms
won't scale or won't last forever for other reasons and probably
be right, but scenarios based on those assumptions strongly
resemble frog-boiling and the outcomes when there are no choices
other than to change something may not be the one that one likes.
I'd be more optimistic right now if a highly fragmented set of
networks, with duplicate or overlapped address spaces,
interconnected by application-layer gateways, were beyond the
state of the art. But, unfortunately, we know perfectly well
how to do those, even down to the level of running code.
For the record, I've never been an IPv6 hater. Because of the
economic and incentive arguments, I think we would have been
better off with protocol design elements that would either have
provided an easier and more obvious transition strategy or more
compelling advantages for conversion than a "running out"
scenario. I said so at the time, but deferred to people who I
thought understood the issues better than I did. I still hope
that it all works out, that people make the right decisions when
faced with the scaling and other problems and that we end up
with an IPv6-based network with good end to end properties. I
just think it is important that we be as realistic and
clear-headed as possible about where we are now as a basis for
what we do, or encourage others to do, next. That state, to
paraphrase Randy, is not a happy one, nor one that will be
significantly improved by cheerleading.
john