How would end-user software deal with an IPv6 address though? Surely some of it is IPv6 capable already, but I would imagine that a lot of it makes assumptions about IPv4. If the OS were operating on a IPv6 network, would that software function correctly as long as the addresses were IPv4-compatible (i.e. within the IPv4 range, and not in IPv6 notation)?
They had enough time. This is not a new thing. Some ISPs were more proactive, some were not. Those invested man hours and hopefully they will reap the benefits while their competitors struggle.
Same with OS and software support.
In the end some will profit from this (even the lazy ones -- "quick, pay us for a new version that enables IPv6 support) and some will lose (they'll find competitors did a better job at IPv6 support).
Dual-stack, proxies, and (if absolutely necessary) actual tunnels can compensate for critical IPv4 apps. You can layer whatever you need to on top of IPv6.
Non-critical applications where people aren't willing to jump through any hoops... Well, it's not exactly news that sometimes old apps get left behind in technology transitions.
Of course it does, but not necessarily a publicly-routable one. Dual-stack is necessary because otherwise the IPv4 application literally won't run at all. How the packets actually traverse the public internet is a different matter addressed by things like NAT, proxies, or tunnels.
"It depends", is unfortunately the answer. For very old software where it's not possible to patch it for IPv6 support (this is rarer than you might think!) then some kind of IPv4 NAT or a DNS64 style "application layer gateway" is required.
You could also potentially add a specific wrapper for your application e.g. wrapping MySQL connections inside of stunnel allows them to run over IPv6 in version of MySQL built with v6 support, or for simple daemons you can do things like set up socat to proxy between an IPv4 socket and an IPv6 socket.
Almost no software you're likely to be running is incompatible with IPv6, though. Software support for IPv6 is way ahead of actual network implementation.
>Almost no software you're likely to be running is incompatible with IPv6, though. Software support for IPv6 is way ahead of actual network implementation.
How sure are you of this ?
Now, ofcourse all the major widely deployed software, be it browsers, web servers, mail servers and clients, remote file systems and similar are already IPv6 ready. What about all the many many millions of custom built systems and applications ? The kinds you will never see, that's hidden behind a corporate wall in use by 10-100 people.
Or all the devices that people have bought - all the wifi routers, IP cameras, network printers, DSL modems and so on ? It doesn't matter how much anyone says that these should have had time to support IPv6. If they arn't, it'll cost someone money to replace them - not all are willing to do that.
You can run both at the same time. Any software that is not IPv6 compatible would still be able to connect through IPv4 and just not have access to IPv6 addresses.
The bigger issue would be connecting to IPv6 only servers from an IPv4 program. The first question is how many IPv4 only programs exist in the wild. If you happen to have one, and cannot update it, then you still have the option of creating an IPv4 to IPv6 proxy for the specific site(s) you need.
We had some software that stored IP addresses in a field in a ':'-separated text line; luckily, the files were quite transient, so we could just change the separator into a semicolon and be done with it.
Elsewhere, the IP addresses were used as part of a file name on Windows; we replaced all colons in the IPv6 address with '!' to fix that.
There's bound to be lots of old software with similar problems around.
Deploy IPv6 today, it ain't hard.