Network World's IPv6 cheat sheet
If you're an ISP or a continuous consumer of fresh public IP addresses, then you will have to deal with v6 sooner rather than later. However, for most other networks, a slow and steady plan for getting to v6 will lessen both problems and costs. This isn't something you want to rush into.
First, it's true that the "free pool" of public v4 addresses is getting low and will soon run out. But then, most businesses don't need new allocations very often. In fact, many are still running today on the initial set of public addresses they got from their ISP or from a registry when they first connected to the Internet.
Not being able to get more public v4 addresses isn't a problem if you don't need any. Also, while each new computer attached to a network needs an IP address, these are usually RFC1918 IP addresses, not public addresses. For most typical circumstances, there is no shortage of these.
So perhaps there isn't a critical lack of public v4 addresses forcing you to v6. Should you go ahead and convert now anyway to get ahead of the curve?
If your network is typical, migration may bring more cost than benefit. After all, there are many existing network attached devices, such as printers, phones and cameras, that do not have any software provision to deal with v6 addresses. While we constantly update the software on our computers and have plenty of storage for that, printers and the like don't tend to get updated very often, if ever, and don't have a lot of extra storage for newer, more complex software.
The result is that, even after adding v6 to your network, you will probably still need to run v4 in parallel for quite some time while all of this legacy hardware ages out. How long that takes will depend on your industry. In education, for example, replacement cycles are typically five years or longer.
OK, you've decided to put v6 off for a while, at least until you've turned over a bit of hardware. How will your users get to those fancy new Web sites that are v6 only? There are at least two ways this problem gets solved. First, those sites don't really want to exclude potential customers, so there is a good chance they will set up a v4 proxy to handle requests from users that haven't converted yet. Then, as we get further down the road, there is one device in your network that should probably be the first one to get a public v6 address. Your firewall.
Under the heading of firewall, I would also include your VPN server if it is separate from your firewall. Your firewall has already been doing the job of translating from v4 internal IP addresses on your LAN to v4 external addresses on the Internet. It's not a big stretch to consider using it to translate from v4 internal addresses to v6 external addresses.
Your VPN server has been accepting connections from travelling workers on public v4 addresses and connecting them to your v4 internal addresses, so a similar upgrade would apply. Once these devices that deal with the outside world have been upgraded, the lifespan of your internal networking technology should be significantly extended.
How about all those futuristic applications we haven't thought of yet that will be enabled by that vast ocean of public IP addresses that v6 will bring us? Peer-to-peer applications we haven't even imagined yet. Of course, the peer-to-peer applications we have already thought of are the ones that choked your network until you taught your firewall to block them!
Now, don't ignore v6 completely when it comes to your internal network. It's definitely time to take future V6 upgradeability into account as a factor in purchasing decisions for network switches, routers and anything else attached to the network. But still, don't go turning on all that V6 capability right away. Odds are there will be more than a few bugs worked through by early adopters.
Hetzel founded Internet Atlanta, one of the first local ISP's in the Southeastern US, in 1993, which he sold in 1996 to Epoch Internet and become their director of network architecture until late 1998. He was Director of Sales Engineering at Level 3 1999-2000 and then VP of Network Engineering for Enron Broadband. Nowadays he does network engineering and consults for local school systems in his area.


