[pdkl95]

> embed the "legacy" address space

They did. Every IPv4 address is in a reserved area of the IPv6 address space.

   a.b.c.d           # v4
   ::FFFF:a.b.c.d    # v6

http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding-2....

> software could be, technically, all-v6 all-the-time by now.

I started using v6 in the late 90s.

Software developed post-2000(-ish) should already be compatible. Unfortunately, there are a lot of developers that think this is hard/impossible (or they are lazy), and so we have software that is defunct by design.

> that address would be all you need

Regardless of how the address was represented, software would still need to be updated.

[cronjobber]

I stand corrected, RFC 4038 seems to be what I was looking for. But it seems to be a late addition, and OS support is optional. If developers think moving their apps to IPv6 is too complicated, I can't fault them.

[Avernar]

> If developers think moving their apps to IPv6 is too complicated, I can't fault them.

I can. I'm a developer and it's easy to add support for IPV6 to apps.

Parsing and displaying IPV6 addresses? There are many libraries and articles for that. Connecting to a host name? Call one function and loop through the list of address structures returned and connect like normal with them skipping the ones that failed. Accepting connections? A little more tricky but since you're writing a server it's not difficult in comparison. The tricky part is figuring out what order you should bind to the socket or if you should use IPV4 mapped addresses.

And if you're using a higher level language or library then it becomes even easier. You just have to worry about the larger size of the address in both binary and text representation if you care about that at all (connecting to a host name you don't have to worry).

The only difficult bit is convincing management it's a good idea to support IPV6. But then the problem shifts from the technical to the political.