The UK has an entire IPv4 /8 that it isn't using

Then there's software. Many web apps don't support IPv6 (db fields limited to ipv4 format, or code assuming ipv4 format). For instance, Internet Brands is too busy with important business, like frivolous lawsuits, to fully support IPv6 in vBulletin. [1]

Some webapps have 3rd party hacks (or even first party hacks) to "support" ipv6 without modifying a lot of ipv4-dependent code, typically by hashing the ipv6 address, taking 32 bits, and using that as the ipv4 address. It's both disgusting and funny.

There's a long way to go before IPv4 is dead.

[1] http://tracker.vbulletin.com/browse/VBIV-9397 (you need a vbulletin.com forum login, unfortunately, and maybe also a linked license; in summary, it's a 2-year-old bug for full support of IPv6, it has no comments from vbulletin devs and no assignee.)

It's happening.

Sort of, and sort of not right? Fiat allocation of a fixed resource, sure, but ISO does fiat allocation of OID space and it works because folks are free to grow as much as they want below it. As I recall one of the original 'next gen' IP proposals was like a huge address translation cloud, IPs were encapsulated in yet another layer which provided 'context' for the IP address inside. Basically every entity got their own 32 bit address space and ingress/egress to the Internet resulted in encapsulation and some additional router magic. One of the arguments against was the huge additional bandwidth cost. Of course we didn't realize at the time that few protocol changes could waste as much bandwidth as SPAM does.

The other challenge is that a functioning liquid market for IP addresses would most likely lead to speculation in IP address blocks. Worse is buying an address block from someone in Germany so that packets have to go to Germany first (top level static routing) to the router where they are re-allocated and then to their 'real' destination router. All very inefficient.

I, like other folks at Sun, was a big fan of a more modest 64 bit address proposal for V6, but alas it was not to be. That the conversion has taken as long as it has (and still isn't "here" nearly enough for a lot of users) really illustrates the dangers of the argument to 'permanently' fix things[1]. But innumeracy aside, the confounding issue is that IP addresses are 'structural' like telephone numbers and managing mobility of structural identifiers is always challenging (the cellular market deals with this all the time) so creating a truly liquid marketplace for these identifiers would ideally include fixing the structural issues which would allow the constraints to be fixed and thus eliminate the market.

Bottom line, it would have been great if folks had thought of that first, but they didn't and while future protocol developers can (and should) benefit from that experience, we're stuck with V4 address blocks that are stuck in various regions of the world.

[1] The most persuasive argument against 64 bit addresses was that this would only push the problem down the road, whereas 128 bit addresses fixed things once and for all.

I agree with you strongly that the 128 bit IP address is a huge design mistake, one that has unnecessarily retarded the deployment of IPv6 (I personally believe fatally so). Even in the '90s, a 64 bit number was still a scalar on most platforms you'd care about. And even in 2012, 128 bit numbers aren't. I think people drastically underestimate the amount of work it's going to take to upgrade the huge amount of software built on the assumption that you can store an IP address in a scalar.