As you can see from the IPv4 Exhaustion Counter to the left (snapshot taken 7/16/2010, 7:30 pm PDT), IPv4 addresses are dwindling.
OK, so that’s perhaps a rather simplistic description of what’s going on – these are a count of the IANA blocks that have not yet been handed out to other providers. Usually what happens is that the IANA hands blocks out to regional network block managers, and they hand them out, piece by piece, to the local providers, who hand them out one (or more for larger organisations) at a time to consumers.
So, even when all these blocks have been handed out (known as “X-Day”), there will still be addresses to be handed out to consumers – but it is a key indicator to follow in realising that IPv4 is a dead-end strategy, and something else needs to be investigated.
Yes, we’ve had these calls to move to a new addressing format for years – back in 1993, when I first got on the Internet, there was a lot of discussion about “IPng – Internet Protocol, the Next Generation” (STNG was current then, you must understand).
Later, as IPv6 came along, NATs (Network Address Translators) were brought out as the saviour to IPv4. The idea was that we’d all use the same internal addresses as one another (so each company has their own local 10.* netblock behind the NAT), and a single external IP address for each NAT. To put it mildly, this is not a solution to the problem, it merely postponed it a little – if anything the fact that we have to use NATs is indicative that we have already run out of IPv4 addresses. Until you look into it, you really have no idea how much work we have already put into changing our applications to work with NATs in an effort to prop up IPv4, when we could have spent that time in adopting IPv6.
So we are closer to having to go to IPv6?
Sure – but hey, what’s not to like about IPv6? Unless you’re the developer of a piece of network software, it all just plain works.
Applications accessing file shares by name – can still access file shares over IPv6, without a line of change. Only if you’re dealing specifically with the IP layer and IP addresses will you see a problem. It doesn’t take a lot to turn an app from IPv4-only to IPv6-capable, and users will hardly notice a difference, if you expose names, rather than IP addresses. [It took me two hours to convert the underlying engine of WFTPD and WFTPD Pro to use IPv6. The user interface took/is taking me longer, because I’m not so good at UI, and haven’t had the focused time I need. But it’s coming.]
You have to reconfigure your routers a little – they at least need to either act as DHCPv6 sources, or handle DHCPv6 traffic to/through a redirector. Ask your router manufacturer what they recommend. And, since you won’t be using a NAT as an accidental firewall, you’ll want to make sure your routers have real firewall functionality.
Technology leaders should be asking to beta test our ISPs’ IPv6 support, and if your ISP isn’t at least beta testing IPv6 support, get them to catch up, or move to one that does. Good gracious, even laggard Comcast is testing IPv6 for its customers!
Some things to look forward to with IPv6:
- Multicast supported natively – maybe Internet radio stations will pick up on this and make their live feeds take up less global bandwidth.
- IPsec supported natively – no excuse any more.
- Because IP addresses are longer and impossible to remember, names will become more prevalent. That’s a good thing, because it discourages you thinking of numeric IP addresses as secure, static or necessary to know.
- Every machine now becomes a "first class citizen" on the Internet. This means FTP works, H.264 and other protocols that require transmission of IP address in the protocol. [That makes IPsec easier and more efficient, too]
- No more NATs. [Except for the pesky IPv4 <-> IPv6 translation layers] No more kludges to deal with NATs.
- There are currently a number of services that are either only available on IPv6, or are available for free on IPv6. That will only grow as time goes on.