And that was precisely my point.

A bit late in the discussion, but still. I have it you never implemented a TCP/IP stack on a barely capable embedded device, or you would understand why I call v6 a full bloat protocol rewrite.

Indeed, I haven't. I take it you have. Could you elaborate? Is the bloat due to having to support a dual stack on a tiny device, or are there concrete features/quirks in IPv6 that are difficult to implement in a constrained device? Pointers would be okay; I searched the web but nothing terribly relevant turned up.

You're right, but no solution is perfect. In this case I would be totally supportive if governments forced ISPs to deploy IPv6, but I would really like their involvement to end right there. It's complicated, I know.

Geez, why would you set up a market over such a resource as Internet addresses, which are scarce only by accident (i.e., the fact that someone chose the number 32 sometime in the past) and not by sheer necessity? I can understand a market as a way to efficiently allocate resources in the face of scarcity, but artificial scarcity is just evil.

Here's a hint: maybe not all problems in the world can be solved efficiently by a free market. Maybe in some cases you need some kind of external intervention to make sure the difficult decisions are made...

It becomes particularly not-so-funny when you have to constantly make the distinction between American and European billions (as is the case e.g. with money). If everyone agreed on using the giga and tera prefixes, that would never be a problem.

Well the speed of light can be measured fairly precisely

Actually, the speed of light is not the result of a measurement, because the meter is defined in terms of the speed of light. The speed of light, by definition, is always 299,792,458 metres per second.

They did do that (as one of the other replies points out). What I think you fail to grasp is that, no matter how "backwards-compliant" your extension is, you still have to teach everyone how to talk to the new-fangled addressed outside the original space, not just the machines that happen to be assigned the new-fangled addresses.

I'm not at all against IPv6. My perspective is just one of speculative curiosity: If IPv4 addresses were used at 100% efficiency (with inefficiency being defined as malware/botnets/spammers) how much longer would they have?

Okay, I apologise if my post came out as harsh (since you are not against IPv6, it wasn't really directed to you).

In regard to your question, I propose the following thought experiment: it seems at the point of IPv4 address exhaustion, IANA had been burning through about twenty /8's per year (source). Now, I know that addresses allocated by IANA are not immediately used by the RIRs, but I think we can safely assume that it's only a lag effect, since RIRs are not allowed to request more addresses from IANA unless they have used past allocations to a certain degree. So suppose that all 256 /8's in the IPv4 addressing space were usable (some are not, for various reasons) and that, due to address squatting, spammers or whatnot, half of the currently used addresses could reasonably be reclaimed. There are rougly 221 /8's usable for general-purpose addressing, so we are talking about roughly 110 /8's worth to be reclaimed. At an allocation rate of 20 /8's per year, you would be buying little more than 5 years. And, obviously, the fraction of reclaimable space is likely much smaller.

I should note that the crux of the above argument is that the allocation rate never slows down. (In fact, it has been increasing along the years.) We all should know that exponential growth processes cannot last forever in a finite world. However, considering that the world's population almost doubles the size of the IPv4 addressing space, and that in some regions of the globe there is already more than a single device per inhabitant connected to the Internet, I seriously doubt we are anywhere near the point where the growth curve flattens. There is a real need for a much larger address space.

One final thought: an Internet where every single IPv4 address does not go to waste is probably difficult to achieve for technical reasons. IP addresses do not serve only to identify particular machines; they are used to route packets to them, and the way we do that is by having the addresses of "nearby" machines share a common prefix. That way, routers on the Internet only have to store a handful (some thousands, perhaps) of prefixes in their routing tables, instead of a dedicated entry for every machine connected to the Internet. So there is also a case for a larger addressing space in that it allows you to keep the Internet routing table size small by making sure that you can still assign "nearby" addresses to "nearby" machines throughout the future.

I don't know where you get that IPv6 is a "full protocol rewrite" of IPv4. For the most part it does exactly the same as IPv4 except with more address bits, and in some cases it even simplifies its predecessor (e.g. no IP header checksum). Any person able to understand or implement IPv4 ought to be able to understand or implement IPv6, because there are no fundamentally new concepts. (I would venture that most people who criticise IPv6 don't even understand fully what IPv4 does, so they don't really know what they're talking about.)

I am also interested in hearing what a "simple extension of IPv4" would be, in your opinion. Odds are you will propose something to the tune of keeping the original IPv4 header and semantics, and tacking some extra address bits at the end. Except in that case you'd still have to teach every fucking router and end system in the world how to decode the new-fangled packets, which is not any different from IPv6 from a cost perspective. You might as well do it right and fix some of IPv4's warts (header checksum, autoconfiguration, node mobility, etc) instead of applying a band-aid solution.

NAT is hardly an acceptable extension of the IPv4 addressing space because NATted clients do not have the same capabilities of non-NATted clients. (Yes, I know about hole-punching techniques; they do not solve the problem fully, and in respect to what they do, they are defeated by many real-world NAT implementations.) If you don't understand the importance of this, I encourage you to read about the end-to-end principle. Finally, it is ludicrous to suggest that implementing NAT at the scale that will be required by the ever-growing Internet would be any cheaper than IPv6. Carrier-grade NAT doesn't exactly come for free.

Sigh. We've been over this countless times. Even if you managed to reclaim all IPv4 ranges that are not being completely used presently, you would buy yourself only a few more months (at current growth rates) until you ran out of addresses again.

I seriously have a hard time trying to understand why so many people on Slashdot seem to be militantly against IPv6. You'd expect more of an allegedly technologically literate audience.

Except for the one-time pad.

Surely you mean Mr Russell?

You are right that getting a complete working driver can be problematic for some of the "bigger" stuff like graphics, and perhaps near-impossible without strong vendor commitment; but, as you said yourself, once the driver is mainlined the kernel community will make sure it is not broken by future releases. That alone defeats the misconception that not having a stable ABI somehow creates trouble for vendors because they have to update their drivers every time a new kernel is released.

That said, there are trade-offs involved, and one of them is that some hardware vendors aren't willing to invest the effort required to maintain Linux drivers.

It's not even clear that maintaining Linux drivers entails that much of an effort. History has shown that, if vendors open-source their drivers (or at least document the hardware interfaces), the kernel community will happily take it upon themselves to maintain them.