> From: "Tony Hain" <alh-ietf@xxxxxxxx>
> You seem to have missed the point. ... You will never hear a consumer
> demanding IPv6 .. You won't hear ISP's demanding IPv6 unless their
> customers are demanding apps that run over IPv6 (even then the consumer
> is more likely to use an automated tunnel and make the clueless ISP
> irrelevant). You won't get new apps unless the development community
> sees a viable path to personal riches.
Tony, I think you're the one missing the point - although you're half-way
there in your later comments above.
IPv6 simply isn't going to get deployed "as a replacement for IPv4". It's just
not enough better to make it worth switching - and you can flame all day about
how NAT's are preventing deployment of new applications, but I can't run an
SMTP or HTTP server in my house because my provider blocks incoming SMTP
connections unless I pay for business service, and I personally find that a
lot more problematic than the limitations of NAT.
IPv6's only hope of some modest level of deployment is, as the latter part of
your message points out, as the substrate for some hot application(s). Somehow
I doubt anything the IETF does or does not do is going to have any affect on
whether or not that happens.
Of course, that still doesn't get you to the "general replacement for IPv4"
stage. I don't think that goal is reachable - IPv6 just isn't enough better
(i.e. more functionality) than IPv4. It's ironic that one of IPv6's big
concept points ("the IPv4 architecture is fine, we just need to fix a few
details") turns out to be IPv6's Achilles' heel. (Although some of us
predicted that at the time IPv6 was adopted....)
Now if basic IPv6 (and basic IPv6 applications) were reworked so that it's
IMPOSSIBLE to tell, from looking at the packet, what kind of service it's
going to - e.g. by using random TCP ports for applications servers, and having
the ICP include a service name (the field for which is encrypted so
middle-boxes can't read it) to do the rendezvous - that would be the kind of
thing that might interest a few more people.
And while we're at it, you probably want to make it impossible for the ISP to
even tell if it's a TCP SYN, otherwise they'll probably just filter them *all*
out incoming...
> Continuing work on IPv4 only creates the illusion that it is a viable
> protocol for application developers to rely on for future income.
Continuing work on IPv6 only creates the illusion that it is a viable protocol
for the network as a whole to rely on for the provision of ubiquitous datagram
substrate service.
In anything even vaguely like its current form, that goal is completely
unreachable for IPv6, and the continued chanting of "IPv6 is the future" only
prevents work on *feasible* upgrades that will allow the continued provision
of ubiquitous datagram substrate service.
Noel