According to AfriNIC, APNIC, ARIN, LACNIC and RIPE NCC statistics as published on their respective FTP servers, they gave out 165.45 million IPv4 addresses in 2005. Out of 3706.65 million usable IPv4 addresses, 1468.61 million are still available as of january 1, 2006.
Read the article - posted 2006-01-01
Some people, such as D.J. Bernstein in his The IPv6 mess article and Todd Underwood in his Bashing IPv6 at TelecomNEXT blog post argue that the IETF made a critical mistake when creating IPv6 by not making the protocol "compatible" with IPv4. What they mean is that a system that only runs IPv6 can't communicate with a system that only runs IPv4. That indeed seems like a significant oversight: without this, it's necessary to run parallel networks for a long time, and there must be a significant amount of logic to determine which of the two protocols can and should be used for a particular communication session. The alternative seems so easy: just reserve some space for the 32-bit IPv4 address space somewhere in the enormous 128-bit IPv6 address space. For instance, IPv4 addresses could be expressed as IPv6 addresses where the first 96 bits are zero.
This way, an IPv6 host host with address 0:0:0:0:0:0:c000:201 (which we are allowed to write down as ::192.0.2.1) can communicate with an IPv4 host with address 10.0.0.1 as long as somewhere along the way, there is a router or gateway that takes the IPv6 packet and transforms it into an IPv4 packet or the other way around, a fairly simple process. At the same time, our IPv6 host with address ::192.0.2.1 can communicate with another IPv6 host that has 3ffe:2500:310:4::1 (well, for the rest of today, at least...) as per IPv6 conventions.
But... The problems start when 3ffe:2500:310:4::1 wants to communicate with 10.0.0.1. When the IPv6 packet arrives at the IPv6-to-IPv4 gateway, the 3ffe:2500:310:4::1 IPv6 address can't be translated into a 32-bit IPv4 address without loss of information. So hosts with "real" IPv6 addresses can't communicate with IPv4 hosts. Even worse, there is no way to determine whether a given IPv4-compatible address belongs to an IPv4 host or an IPv6 host. It gets really bad when a host can do IPv6, but it doesn't have IPv6 connectivity to the rest of the internet.
The solution is to forget IPv4 compatible addresses for IPv6 hosts. If an IPv6 hosts is going to get an IPv4 address in the first place, it's much simpler to let the IPv6 host generate IPv4 packets where appropriate. So such a host would simply have an IPv6 address to communicate over IPv6 and an IPv4 address to communicate over IPv4.
Communication between IPv6-only and IPv4-only hosts can be accomplished using a gateway as outlined above, with the addition of NAT functionality to allow multiple IPv6 hosts behind a gateway to share the gateway's IPv4 address. This is called NAT-PT (Network Address Translation - Protocol Translation) and it has the same downsides of regular NAT in that IPv6 hosts can connect to IPv4 servers, but not the other way around. So IPv6 is more compatible with IPv4 than many people think.
Todd Underwood concludes that "IPv6 is dead, and I think pretty much everyone already knows it" and "I guess that's just about enough time for the stubborn IPv6 camp to admit they're wrong and for all of us to come together and make something that we can easily migrate to." It continues to amaze me in what a hurry people are to declare defeat. I think Todd and others who think along the same lines massively underestimate the amount of time and effort a project like this takes. It's debatable at what point IPv6 was (or will be) mature enough to replace IPv4, but I don't think anyone can seriously maintain that it reached this point before 2002. So that's at least 7 years between publication of the first RFCs and barely adequate. By extension, any new effort won't be ready before 2013. I also fail to see what the critical difference between IPv6 and any new protocol could be: obviously, it has to stay fairly close to the IP we know to avoid unnecessary complications (which IPv6 does, for the most part at least) and even more obviously, it must support longer addresses (which IPv6 certainly does). So how would the new protocol be so much better to warrant the effort?
Permalink - posted 2006-06-06
Last week, ARIN, the organization in charge of distributing IP addresses in North America, changed its IPv6 address policy so it's now possible to get Provider Independent (PI) IPv6 address space.
According to the ARIN Number Resource Policy Manual:
This is both good news, and bad news. The good news is that if (in the ARIN region) you are currently connected to two or more ISPs for IPv4, you can now do this in much the same way with IPv6. Since IPv6 routing is almost identical to IPv4 routing, all of this should be fairly easy.
However, since both the routing protocols (including BGP) and the rules for getting address space are now mostly the same, this means that in the future, IPv6 routing will suffer from the same problems that have been plaguing IPv4 inter-domain routing: a "global routing table" that is much larger than necessary, requiring network operators to invest in bigger routers and causing unnecessary instability. It also means that multihoming (the practice of connecting to two or more ISPs) will never be possible for truly large numbers of internet users.
The Internet Engineering Task Force has been working on alternative ways to gain multihoming benefits in the multi6 and shim6 working groups. But the ARIN constituents decided not to wait for the completion of this work, which will likely have the effect that the shim6 mechanisms won't be adopted widely or quickly when they become available. One reason cited for moving ahead with a known problematic solution for multihoming was the statement by some organizations that they wouldn't adopt IPv6 in the absence of a multihoming solution. Prediction: they won't implement IPv6 with multihoming anytime soon either.
And unfortunately ARIN (and the other RIRs) still claim that you can filter out any IPv6 prefixes longer than /32 even though they give out micro allocations and now PI blocks that are longer than that, mostly /48. See my article from nearly three years ago.
Permalink - posted 2006-09-05
Iljitsch van Beijnum
The Internet Protocol Journal, Vol. 9, no. 3, pp. 16-29, September