Thus spake "Keith Moore" <moore@xxxxxxxxxx>
Dual-stacking hosts is a non-problem. For the majority of
deployed hosts, it is already done.
That depends on the definition you're using. Many hosts are
v6-capable, though I'd still debate whether it's the majority.
Very, very few of those hosts have working v6 connectivity
because there's some device(s) or provider(s) between the
host and the DFZ that are v4-only.
agreed, but you were talking about hosts.
I do not consider a host dual-stacked, regardless of whether it's
v6-capable, unless it can actually talk to remote hosts via v6. That may be
imprecise on my part, but it's all that matters in the end.
It's humans and software, not hardware, that is generally the
problem getting v6 deployed.
agreed about humans - mindshare is the hardest thing to
overcome. the software/hardware question is a distinction
without a significant difference. if the products (you think) you
need to secure your network aren't shipping, it doesn't matter
much whether what you need is new hardware or a software
upgrade. often, that's just a matter of packaging.
Ah, but there is a difference. Hardware is purchased in a 3+ year cycle,
and generally involves significant capital outlay. Most hardware is
v6-capable by this point, though apparently there's still issues in the
load-balancer space that are preventing major content sites from
dual-stacking.
OTOH, v6 software is still not available from the majority of vendors, but
if they do release it, it could be a free update (perhaps within the terms
of a service contract) and deployed at any time.
The distinction is moot, I'll agree, in parts of the market like consumer
CPE where the vendors have a history of only releasing new software on new
hardware, so a v6 upgrade will require hundreds of millions of people to buy
new boxes even though their existing boxes would do v6 just fine if the
vendors bothered to release new code for them.
There's a lot of focus on NAT-PT for v6 sites to access
remote v4-only sites; I'm focusing on the case of v4-only sites
using NAT-PT to access remote v6-only sites.
that's certainly an important case, but there are better ways
than NAT-PT for v6-only sites to provide services to v4-only
users.
Perhaps. However, every other model I've seen assumes that all of those
v6-only sites should pay the cost of making their services v4-accessible.
That puts the cost in the wrong place, since it's v4-only sites that should
be penalized for being laggards -- not the v6 early adopters, and also
assumes that v4 addresses will remain available for them to implement those
solutions. In a few years, that will no longer be true.
There are basically two incentives to support IPv6: one is
more addresses, the other is a better behaved network that
is capable of supporting a wider range of applications at
lower cost. If NAT-PT is widely deployed, the second
incentive is removed.
No, the second incentive remains. Fully deploying v6 is still
a good idea because it removes the problems inherent to
NAT-PT, which I've already acknowledged.
yes, but everyone else's NAT-PT boxes still keep you from
getting most of the benefit from your upgrade to full IPv6.
In the short term, yes. OTOH, if everyone deploys NAT-PT today, then
tomorrow it will _appear_ that the entire Internet is v6-capable, and I can
convince management that deploying v6 "for real" is worth the effort.
Today, there is virtually nobody I can reach with v6, so management isn't
interested, resulting in a chicken-and-egg problem.
IETF is useless if it doesn't try to describe what will work well
in the long term.
We all agree on the long-term vision. What we disagree on is what is the
best method to get there from where we are today. I think that NAT-PT is no
less evil than the v4 NAT we're using now and will get us to a NAT-free
v6-only Internet faster than other strategies proposed. The shorter the
transition is, the better things will be for all of us in the end.
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf