The IPv6 Mess

The real problem facing IPv6 is/was glacially slow adoption. Internet protocols are not adopted by fiat; they are adopted when the protocol offers each incremental adopter enough benefit compared to the burden of adoption. IPv6 blew it on both counts: compared to competing IPng proposals it does not provide enough benefit to the incremental adopter and it is too burdensome to implement.

Excessive Incremental Burden

I worked as an undergrad intern for Sun Microsystems in the late 90's. My job was to implement parts of the Solaris IPv6 stack. It was such a nightmare that they couldn't get any of the full-time engineers to do it.

Insufficient Incremental Benefit

Clearly if we all switched to IPv6 tomorrow we would all reap great benefit. But the Internet doesn't work that way. Early adopters will only switch if they can gain some benefit before all but a tiny fraction of the population has switched.

Here's the crux of the problem:

If you have no IPv4 address and my ISP will not issue me an IPv6 address, we cannot communicate.

A good IPng proposal should not have this flaw.

Furthermore, a good IPng propsal should:

Declare that every IPv4 address is a valid, routable IPng address (perhaps by concatenating with some fixed string).

This means that any holder of an IPv4 address can receive IPng packets without requiring the cooperation of his/her ISP or payment to some third-party “tunnel provider” (bandwidth isn't free!).

Make access to a IPng-to-IPv4 NAT mandatory, and declare that IPng addresses without access to such a NAT must be considered to be “private networks” (like 10.x.x.x).

Ideally one could calculate the IPv4 address of one's NAT by simply dropping all but the first 32 bits from one's own address, and the NAT's IPng address from that (see previous point). This eliminates the need for any kind of configuration mechanism – one less thing that can malfunction.

Require that all IPng-to-IPv4 NATs support tunneling. In other words, if a packet with IPv4 packet-type X arrives at the IPv4 side of a NAT (where X is some currently-unused IPv4 packet type), the NAT must treat the payload as an IPng packet destined for some host on the IPng side of the NAT. Conversely, if a packet arrives at the IPng side with a non-IPv4 destination address D which is not on the private side of the NAT, that packet must be tunneled to D's NAT, whose address can be calculated using the procedure described in the previous point.

As originally proposed, IPv6 has none of these properties. The 2002::xx addresses do not meet the first criterion – they are not routable.

In the last 3-4 years the IPv6 folks have cobbled together a bunch of hacks (6over4, NAT64) to offer the services in the last two points. Unfortunately none of these are mandatory, so it is not safe to assume that every IPv6 host has access to these services. The protocols for these hacks are also hideously complex, mostly because they weren't designed into IPv6 from day one. Even if you know that a given IPv6 address has access to NAT64, 6on4, 6in4, etc, you cannot calculate the address of its NAT simply by looking at its IPv6 address. This in turn requires complicated “discovery” mechanisms.

Had IPv6 included the properties above from day one, it would be the case that an IPv6 address would be at least as useful as a IPv4 address behind a NAT. Slightly more useful, in fact, since the IPv6 address space would provide a standardized way for hosts behind different NATs to find each other (something we don't have with IPv4). I speculate that peer-to-peer software like Skype would then have become the driver for IPv6 adoption (well ahead of IPv4 exhaustion!) because IPv6 would have become the preferred way to do tunneling through NATs, something people have valued for many years now.

As it is, an IPv6 address is considerably less useful than a NATted IPv4 address. I can't see why anybody would want to go through the effort of acquiring an IPv6 address.