While an idealized IPv4 to IPv6 transition (one where IPv6 is completely backwards compatible with the IPv4 network) is impossible, it's possible that IPv6 could have done some things differently to make the transition easier. The outline of the theoretical easier transition goes like this.

First, you officially embed the IPv4 address space into the IPv6 address space, so that every IPv4 address is a valid IPv6 address inside a known area of the IPv6 space. You also need to add a rule that permits operating systems to make IPv4 connections to these addresses provided that suitable conditions are made (both endpoints have IPv4 addresses, you have IPv4 connectivity, and no IPv6-only flags are set).

With this, operating systems can immediately start adding system calls that accept IPv6 addresses, even before they actually have an IPv6 protocol stack; the only IPv6 addresses and options that are accepted are the IPv4 subset, and the operating system just talks IPv4 to them. In turn this allows applications to immediately start being modified for IPv6, and in fact to only use IPv6 addresses and system calls if that simplifies their lives. As operating systems get actual IPv6 stacks, the system calls can start accepting general IPv6 addresses and talking IPv6 to them.

In effect, you would turn IPv6 into an easy superset of IPv4 from the perspective of programs (and somewhat for system administration). Programs would only deal with IPv6 addresses and you would mostly only bother configuring IPv6 on systems; it's just that some of the time you would be using a limited subset of IPv6 addresses and might have limited or no connectivity to non-subset addresses.

The goal of all of this is to shortcut the chicken and egg problem that dogs IPv6 deployment today; you could have gotten IPv6 enabled programs and systems out in the field much earlier than we have, and gotten them talking IPv6 in live deployments. Once you had a critical mass of IPv6 systems deployed and talking IPv6, general IPv6 addresses are much more useful and easier to deploy.

This is a nice theoretical approach, but it has some practical engineering issues:

• you really want a protocol that IPv6 enabled stacks can use to find out if they can talk actual IPv6 to those special IPv4 subset addresses, or if they have to keep talking IPv4 to them behind the scenes. You can fake this for TCP (you can try IPv6 first and fall back to IPv4 if you get nowhere), but you need an actual way to tell for UDP et al.

• you more or less permanently complicate IPv6 routing tables, because you necessarily embed in them the large and baroque IPv4 ones.

• despite programs being nominally IPv6 ready, you don't know if they can really deal with unrestricted IPv6 addresses until you start feeding such addresses to them. Since programs start out only dealing with a very restricted subset of IPv6 addresses, they may have committed all sorts of convenient hacks and quick conversions.

• similarly and more alarmingly to system and network administrators, you don't know what lurking security issues are waiting for you to turn on real IPv6 connectivity and start talking to arbitrary IPv6 addresses. You can't assume that just because your programs and systems are secure with IPv4-in-v6 addresses that they'll stay that way for general addresses.

I suspect that the engineering issues are enough to sink this as a practical idea (or were, if anyone proposed something like it back at the dawn of IPv6).

(This entry and last entry were both sparked by reading DJ Bernstein's the IPv6 mess and then scratching my head. I still don't see how his desired transition would actually work.)