Short version: Nothing has changed in the last 15 years or more:
The IPv4 Internet is separate from the IPv6 Internet.
There is not enough impetus to develop and test the
protocols, end-user device software, server software
and to deploy the servers required to make IPv6-only
connectivity sufficiently useful to most, or any,
users that there is a real demand for it.
If an end-user device already has IPv4 connectivity,
included behind NAT, there's little or no advantage in
also having IPv6 connectivity, since everything of
importance can already be done via IPv4.
Finally, some pertinent quotes from Eric Fleischman
and Noel Chiappa.
The problem with IPv6 deployment and utilization is not so much the
costs but the fact that the IPv6 Internet is a separate Internet from
the IPv4 Internet. A computer with only an IPv6 address cannot
communicate directly with any computers which have only IPv4 Internet
addresses.
Indirect communications via a protocol such as SMTP will work because
the protocol does not involve direct end-user computer to end-user-
computer communications. Messages go via mail servers and as long as
the sender's or the recipient's mail server has both IPv4 and IPv6
connections, the message will be delivered.
Other messaging protocols which rely on servers could be - and in some
cases have been - made to work with the end-points being on different
Internets. Likewise file storage systems such as Dropbox - though a
year ago it didn't:
http://www.forwardingplane.net/2012/12/a-day-with-only-ipv6/
A web server with IPv4 and IPv6 addresses can be controlled from either
Internet and serve pages to clients on both Internets.
IPv4 with NAT works well enough that there's little or no attraction for
providing an Internet service which has an IPv6 address but no IPv4 address.
The only way I can imagine there being sufficient impetus to giving
large numbers of users IPv6-only connectivity would be if, for some
reason, such a body of users could have many, most or maybe all their
communication needs met by IPv6-connected servers, including those which
transacted the users' communication with IPv4-only end-points.
One way would be via the end-user's applications running IPv4, in which
case the so-called IPv6-only connectivity is just being used as a
tunnelling mechanism to a global unicast IPv4 address, or more likely a
behind-NAT IPv4 address. This is not really IPv6 adoption. I am trying
to find reasons why an end-user would be happy with IPv6 only
connectivity and applications, or even a reason why they would want IPv6
apps and connectivity when they already have IPv4 apps and NATed IPv4
connectivity.
Maybe, if there was a language or cultural group somewhere who didn't
care to (or was not allowed to) access any of the web servers which are
currently not IPv6 connected, and if there was some economic or
political advantage in not giving them even NATed IPv4 addresses, a
large enough body of IPv6 end-users might emerge that there was impetus
for some or many currently IPv4-only servers to gain IPv6 connectivity
in order to communicate with this body of users.
Maybe in China or North Korea an IPv6-only service might be launched,
for instance due to the government preferring a NAT-less service where
every user has a unique IP address, so their activities can be more
reliably monitored. It hasn't happened yet, because such a service
would not be much use to people who expect to be able to access any web
server in the world - and as far as I know most of the web servers are
connected only to the IPv4 Internet.
For years IPv6 promotion has been along the lines of the impending
disaster of running out of IPv4 addresses, coupled with IPv6 being
something like the next version of "the Internet" with boundless address
space. I do not recall these efforts at promotion explicitly stating
the truth that the IPv6 Internet is a separate Internet from the IPv4
Internet.
Some communication protocols can handle this and make the differences
between the two Internets irrelevant for all users. To do this I think
three conditions must be met:
1 - The client protocols must be defined and work well for IPv4, IPv4
with NAT and IPv6. This includes situations in which
connectivity changes rapidly between IP addresses, such as
when a mobile device connects to a different 3G/4G/WiFi
system and the device gets a different IPv4 or IPv6 address
including switching between NATed and unNATed IPv4 addresses.
Ideally sessions would survive these changes, including between
IPv4 and IPv6 if (as is not currently the case) a significant
number of users' devices are sometimes connected only to IPv6.
The client protocols and the client software itself has to cope
with this and with having both IPv4 and IPv6 connectivity at the
same time. There must be no need for end-user decisions,
adjusting settings etc.
(See John C Klensin's message in this thread regarding similar
difficulties in developing protocols and software.)
2 - The client software needs to be written for all the relevant
operating systems including at least: x86 Windows, x86 GNU/Linux,
ARM iOS and ARM GNU/Linux/Android.
It also needs to be tested and debugged on all these OS's in
all the combinations of connectivity mentioned above so that
it is reliable in all these settings without any end-user
intervention.
3 - The communications need to take place via one or more
intermediate servers which collectively interwork between
the IPv4 and IPv6 Internets.
There are nested chicken-and-egg problems in the above. Why would
anyone bother to develop both IPv4 and IPv6 client protocols and all the
end-user and server software for both Internets, especially considering
the demands of developing and testing on multiple operating systems?
They would need extraordinarily strong motivation. They would not be
able to achieve this level of testing and robustness without a
substantial body of users and probably a year or two's work.
This at cannot be achieved at present because there are no users
anywhere (as far as I know) whose Internet access is IPv6 only.
This is because, with the exception of email and I guess some other
messaging protocols, the major communication protocols have not achieved
all three steps above - making IPv6-only connectivity not worth having.
The answer to the IPv4 address shortage is NAT for end-user devices.
Servers need global unicast IPv4 addresses. Client protocols need to
work in some way behind NAT - outfoxing the NAT system in some way to
communicate end-user-device to end-user-device and/or by communicating
via a server.
Every widely used end-user protocol, application or whatever needs to
cope with these IPv4 requirements, and be developed and tested for three
or four operating systems.
It would take extraordinary extra effort to extend this to the three
points above which are necessary to make the protocol or service work
seamlessly for end-user devices with IPv4 only, IPv6 only or both kinds
of connectivity. With the exception of email and I guess a few other
protocols, there has never been sufficient reason to do this extra work.
As far as I can tell, nothing I wrote here is new compared to the
situation 15 years ago, except that end-user device NAT is now
ubiquitous whereas perhaps it was not so then.
The widespread adoption of billions of Internet-connected mobile devices
and the exhaustion of fresh, never-used, paddocks of IPv4 addresses
doesn't alter the situation for end-users, ISPs or protocol/application
developers materially from what it was in the late 1990s:
There is a separate IPv6 Internet, but there's no compelling reason
to use it.
An IPv6-only service would be of so little value that customer
support calls would devour whatever revenue might be gained from
selling it.
Finally, here are two quotes from discussions on the IRTF Routing
Research Group list regarding IPv6 adoption:
On 2013-11-20, Eric Fleischman wrote:
It's currently a lonely job in many large corporations to be an
IPv6 specialist. I can't help but wonder how many large
corporations have plans to migrate away from IPv4?
The view from my knothole is that RFC 1687 is as true today as
it was in 1993 when I first wrote it. It's more than just
inertia – it's also a very strong perception that IPv4 serves
us very well.
On the same day, Noel Chiappa wrote, quoting Scott Brim:
> the IETF has said it doesn't want to come up with any more clever
> ways to help organizations continue to squeeze more life out of
> IPv4 addresses. It will help with transition away from IPv4.
Just like with NAT. The IETF would rather stick its head in the
ground - thereby ensuring that whatever happens, it will be done
by individual actors, in an incoherent way.
Like the Bourbons, the IETF has learned nothing, and forgotten
nothing.
- Robin http://www.firstpr.com.au/ip/ivip/