IPv6 Deployment

OK, so you are now convinced that you need to deploy IPv6 in your network. Just how do you go about it?


Stop Buying Obsolete Network Products

First, you should stop buying network hardware or software that doesn't support IPv6. Anything that doesn't is going to have a very short lifetime before it will have to be replaced or upgraded. It is not sufficient for a vendor to have IPv6 "on their roadmap" somewhere in the misty future - virtually every vendor has IPv6 on their roadmap - some of them have had it there for 10 years or more without any actual progress. If you do find a vendor that somehow has completely missed the boat on IPv6, you should be looking for a new vendor. "Roadmaps" are marketing tools, not actual development schedules. Ever try to get a vendor to agree in writing, with penalties, to their "roadmap"? Good luck with that. They know that those are only "targets" that they hope to hit. The estimates are almost always "optimistic" (to be kind). Sales people are notorious for selling vaporware, then asking the developers if they can create it. Yesterday.

Every organization does hardware (and software) refresh, sometimes continuously as needed, sometimes in cycles. Find the person or group that oversees this and make sure they understand the importance of requiring that all equipment purchased supports IPv6, starting now. It will definitely save you money later. This is a compelling argument for CFOs and CEOs.


Demand the "IPv6 Ready" Label (not the Union Label)

It is one thing to claim IPv6 support. A vendor's marketing people will claim all kinds of interesting things. There is a very simple way to determine if the IPv6 support on their products is real - it is called the IPv6 Ready Logo Program. This involves subjecting a product to literally hundreds of tests and verifying it is in full compliance with every MUST and SHOULD item of relevant RFCs. There are also tests for interoperation with several known compliant products. There are thousands of products, of every kind, from a wide range of vendors, that have already been certified as fully IPv6 compliant by this program (including SolidGate and SolidProxy). There are a number of labs around the world that can do this testing (I used to run one of those labs). Vaporware can't be tested. Only products that actually exist in the real world can. The list of certified products is available here, and can be searched by product type, vendor, etc. This should be your shopping list. Add a requirement that only network products that bear the IPv6 Ready logo can be purchased, without a specific exception from a C level executive. This will save the organization a great deal of money later, when it is no longer an option to deploy IPv6 - it is a matter of corporate survival.


Number of Hits on Various Terms in IPv6 Ready Approved Products List

As of 8 September, 2013 there were 1518 items in the Phase 2 (Gold) list. The following terms got the listed number of hits (which gives you an indication of how many products of that type there are).

Router 358
Firewall 64
Switch 196
DNS 14
Web 53
Mail 16
VoIP 31
Printer 104
Scanner 15


Stop Putting it Off

The longer you delay deploying IPv6, the more painful, expensive and disruptive it is going to be, and the poorer the quality of the results will be. IPv6 is kind of like a tooth going bad in this sense. It is only going to get worse the longer you wait before addressing the problem. IPv4 is already at End-of-Life. We are already years overdue for widespread IPv6 deployment, and the transition has already become more difficult because of this. We should have been mostly done when IANA ran out of IPv4  in February 2011. IPv6 has been around since 1995, and mature since about 2005. More and more "bad engineering" has been done, and is still being done, to keep IPv4 alive (albeit "on life support") for just a few more months. This started with NAT44 and private internets (which should never have been used for more than 10 years while IPv6 was maturing (the term "temporary measure" was all over these RFCs). This is now being compounded with NAT444 and IPv4-only CGN. I personally consider Layer 3 translation (NAT-PT and NAT64/DNS64) to be really bad engineering as well. The IETF has already agreed with me on NAT-PT (it was deprecated years ago).

One of the main problems is lack of knowledge about IPv6 on the part of networking professionals. There is no excuse for this. It is like network engineers refusing to move on from IPX/SPX long after it lost its dominant market position to TCP/IP. The world finally left those engineers behind. Some of them who did move to TCP/IP are now griping that they made one transition (from IPX/SPX to TCP/IP) and now just 10 years later we are asking them to make another transition (from TCP/IPv4 to TCP/IPv6). Any system engineer who wouldn't move on from Windows 2000 was quickly replaced. Even Windows XP / Windows Server 2003 is finally beginning to fade into history (in no small part because its support for IPv6 is very poor - Microsoft was just learning IPv6 then - it is doing a much better job with IPv6 today). With the Sixscape website, network engineers can no longer claim the information is not available, or too expensive. Anyone can afford free.

There are some techniques (like Layer 7 proxy translation) that can allow existing web browsers to access IPv6 websites, and allow external IPv6 browsers access your legacy web servers, at very low cost and with very few changes to your existing legacy infrastructure. This can literally be done overnight. It is not much more difficult to make your legacy e-mail dual stack as well. This will give your users a taste of IPv6 immediately, and make sure your web servers are available to anyone. It will also help your network engineers to start learning IPv6 in a relatively painless way. This is a very good first step that anyone can take today. You may be facing mandates to make your outward facing infrastructure (web and email) IPv6 compliant. This will satisfy those mandates quickly and cheaply. It will also help your organization appear to be "up with the times". Announce that your web site is now available over IPv6. This is a real marketing win - makes you look more competent than your competitors (unless they already beat you to this easy win).


But My ISP Doesn't Offer IPv6 Service Yet

Yes it does (even if they don't know they do). You can get IPv6 service today regardless of who your ISP is. Just in some cases, you will need to use a tunnel to reach through your ISP's legacy IPv4-only infrastructure to get to the emerging IPv6 Internet. There are a number of sources of free tunneled IPv6 service available today. These are accessible from anywhere in the world. If you've got IPv4 service, you can get IPv6. It's easier if you have at least one of the precious remaining IPv4 public addresses, but even that is not strictly required. The projects on this website will talk you through how to do this today, at little or no cost.

In the early days of IPv4, we reached through the legacy voice telephone network (with modems) to get a tiny trickle of IPv4 service (56Kbit/sec, anyone?). Not being able to afford a T1 line at our homes didn't stop us from getting IPv4 service. It's the same thing all over again, except now the legacy infrastructure is typically already available 24x7 at speeds of 1 Mbit/sec or faster. You don't even have to tie up your family phone to use it. Reach out and touch the IPv6 Internet. Right through your existing IPv4 ISP account. Your ISP might not even be aware you are doing it (it is completely transparent to them - they don't have to change a thing). I've had full dual stack Internet access in my company and home networks since 2004, using tunneled service. Come on guys, this is 2013. It's time for you to get on board.


But I've Got a Ton of IPv4-Only Equipment in my Company Network!

First off, shame on you. You should have put an "only IPv6 compliant" policy in place years ago. Nobody told you this was coming? Well, except for numerous warnings from IANA, the IETF, all five RIRs, etc.

Second, surprise! You might find that much of your equipment is already IPv6 compliant, and just needs to be configured. Or maybe you just need to upgrade to the latest firmware (which you should probably do anyway). In some cases, really old equipment (like Cisco 2400 routers) can't be upgraded (not enough RAM or ROM to hold the firmware with IPv6 support). Anything that old should probably be put out to pasture anyway. For years, Cisco only included IPv6 support if you paid a lot extra for the "Advanced IP Services" option in iOS. Today, IPv6 is included at no additional cost in the base level of iOS. Likewise, Juniper equipment has included support for IPv6 for years.

More good news! Almost all Open Source software supports IPv6 (BIND, dhcpd, Apache, Nginx, FreeBSD, and Linux) have long had good support for IPv6. Almost all recent software from Microsoft (except Azure) is fully IPv6 compliant.

Bad news. Virtually all cloud providers are IPv4-only. This is particularly annoying since IPv6 is a natural for clouds. On the other hand, you can put a Layer 7 translating web proxy in front of an IPv4 cloud website (or any other IPv4-only website) and it will be available everywhere, dual stack.

Another good surprise - all your NICs and Layer 2 ("dumb") switches have always supported IPv6 (from the first moment there was IPv6). They work at the DoD Link Layer (L2) or below, so they can't even tell the difference in IPv4 and IPv6. It's all just Ethernet packets to those devices. IPv6 only makes a difference at the Internet Layer (L3) and above. And before you ask, your network cables and wiring panels are IPv6 compliant too. No need to replace them with "Cat 7" cables or somesuch. Any wiring that IPv4 works on is just dandy for IPv6.


Configure, Upgrade or Replace your Layer 3 Devices

You will probably have to reconfigure or upgrade any Internet Layer (L3) devices, like routers, firewalls, Layer 3 "smart" switches, etc. If there is no upgrade available (or insufficient RAM/ROM) you may have to replace them. If you have DNS/DHCP appliances, those will also have to support IPv6. DNS needs to both allow managing AAAA and PTR/128 resource records, and support access over IPv6. DHCPv6 is an entirely new protocol and server. These services work at the Application Layer (L7).

If you have legacy network devices like printers, scanners, or even IP phones that only support IPv4, those will work fine in a "dual stack" network (one that supports both IPv4 and IPv6 in parallel). You can continue using them as IPv4-only devices until it is time to replace them (and when that time arrives, please don't replace them with more IPv4-only devices). You won't be able to use them from IPv6-only devices, but there are not many of those at this point. Eventually there will be, so don't buy any more IPv4-only products.


When Will They Shut Off IPv4 Service?

When they pry the last IPv4-only device from the cold, dead fingers of some recalcitrant network engineer, maybe 10 years from now. Maybe we will keep a small IPv4 Internet consisting of only a handful of nodes, running in some museum somewhere. We could even provide 4in6 tunneled access to it, for people who run antique Operating Systems that still have IPv4 support. ("Wow, look at those addresses - aren't they dinky and quaint?")

The reality is that IPv4 is going to be around for a long time, running in parallel to IPv6. IPv4 deployment is already starting to "peak", then will start decreasing. IPv6 deployment is growing very rapidly. At some point, it will inevitably exceed IPv4 traffic. Maybe we should start running predictions of when the traffic on the IPv6 Internet exceeds that on the IPv4 Internet, like we did as to when IANA and the RIRs would run out of IPv4 public addresses - we are nowhere close to that now. Cisco estimates that in 2013, some 3.1 percent of all Internet traffic is IPv6. By 2017, they estimate 23.9 percent will be IPv6. The exact date that IPv6 traffic exceeds IPv4 will be difficult to measure, but at some point it will become obvious that IPv6 is dominant, just like TCP/IPv4 eventually eclipsed IPX/SPX on LANs.

Not many people are aware that there was a first Internet, before the current IPv4 Internet. This used a protocol called the "Host to Host" protocol (specified in RFC 1), more commonly called the NCP protocol. It used 8 bit addresses for a maximum of 256 nodes. This Internet lasted from 1969 (when the first four nodes were linked together) until December 31, 1982, when NCP was shut off. As of Jan 1, 1983, IPv4 was used. That approach is called a "flag day". We cannot do this with the IPv4 to IPv6 transition. For one thing, there were maybe 1,000 people using the NCP Internet at the end, and they were mostly technically savvy engineers and researchers. Today there are over a billion people using the IPv4-Internet. Not many of them can be considered tecnically savvy. During the transition to IPv4, they broke world wide email for a month or so. It was a pretty rocky transition. We can't afford to do that today. Entire national economies would suffer badly if parts of the Internet stopped working for an extended period (an "Oops - sorry" is not going to cut it).

IPv6 was designed from the beginning to play nicely with its neighbors (i.e. IPv4). A lot of the RFCs related to IPv6 are concerned with transition. Several mechanisms are available: Dual Stack (running both IPv4 and IPv6 on nodes or entire networks); Tunnels (sneaking IPv6 through IPv4-only infrastructure, or IPv4 through IPv6-only infrastructure); and Translation (convering IPv4 to IPv6, or vice versa, on the fly).

There are really two Internets (due to the fact that IPv6 is not backwards-compatible with IPv4): the IPv4 Internet (that most people are using today) and the IPv6 Internet (that will someday replace its older sibling).

Currently, it is mostly an IPv4 "ocean", with little emerging "islands" of IPv6. People are linking those IPv6 islands together with "undersea cables" called tunnels. Over time, those islands are going to continue to grow, until they begin overlapping. At some point it will be a hodge-podge of IPv4 and IPv6, like a giant swamp. Then the IPv4 regions will begin to shrink, and the IPv6 continue to expand, until it becomes an IPv6 "ocean" with shrinking "islands" of IPv4. Inhabitants of those islands will use 4in6 tunnels to link them together, just like 6in4 tunnels were used in the early days. Eventually, the last IPv4 island will disappear, and transition will be complete. It doesn't really matter when that happens, and it won't be for quite a while.


OK, I've Done All of the Above - I'm Ready to "IPv6" My Corporate Network

Unless you are a real radical or revolutionary, you won't be switching to IPv6-only, you will be introducing IPv6 into a working IPv4 network. Your goal should be to wind up with a Dual Stack Network.


IPv6 Readiness Survey

The first step is to find out what shape your network is in now - an IPv6 Readiness Survey. If you already have a list of all your network equipment, including model numbers and firmware versions, then you can just make sure it is up to date. If not, make that list now. You need to pay special attention to any routers, firewalls and "smart" (L3) switches.

For each Layer 3 device, determine if it already has support for IPv6. If it doesn't see if a firmware upgrade is available with IPv6 support. If so, obtain the firmware upgrade and install it. If not, consult the list of approved products at IPv6 Ready for a replacement device that does support IPv6.


Design Network Architecture

You should also locate the network architecture diagram that shows the subnets and current IPv4 address blocks used in each (including gateways and possibly static routes). Verify that it is up to date (they rarely are). If it isn't up to date, bring it up to date now. There is no network architecture diagram? Well, first create one of the current network to use as a starting point.

You also need to determine if your current ISP offers native or tunneled IPv6 service. If not, you will have to tunnel through them to the IPv6 Internet. This is not a big deal. Your ISP (or "virtual ISP" if you obtain tunneled service) will determine the IPv6 address block you get. You may have a choice of block size, from a single /64 to a /48 (65,536 /64 blocks). If you have multiple subnets, you will need a /64 block of IPv6 for each one. If your current border gateway is IPv4 only, and you can't replace it, you may need to deploy a second, dual stack router or firewall between the existing border gateway and the rest of your network.

If you plan to use a 6in4 tunnel, you will need a dual stack gateway (preferably a firewall) that supports 6in4 tunnels. You will also need a source of tunneled IPv6. You can use one of the free sources for now (e.g. Hurricane Electric's tunnelbroker.com). Of course, if they shut it down, you can hardly complain - it's free. If you want more control and reliable service, you can get a rack in a co-location center that provides commercial native dual stack, or at least rent a server in one. You can use this as your own source of tunneled service. Any firewall or router that supports 6in4 tunnels can be either end of the tunnel (6in4 tunnels are symmetric - there is no "server" end or "client end", just "endpoints").

You will need a public IPv4 address on the WAN interface of your dual stack gateway (and that gateway must support 6in4 tunnels). If you have to deploy a second router or firewall inside your existing one, you will need to find some way to route at least one public IPv4 address through the external gateway to the WAN interface of the internal gateway. This can be accomplished in various ways. If you currently have more than one public IPv4 address, you are already routing an IPv4 block to your inside network. In that case, use one of those for the WAN interface of your inside gateway. Make sure that protocol 41 is not blocked by the external gateway. If you have only one public IPv4 address, you need to put your existing gateway (probably a modem/router CPE) into bridged mode. This means it just passes all addresses straight through to the LAN interface. You may need your ISPs help to do this. You may not even have the necessary access permission to do it yourself.

Alternatively, you can use TSP to tunnel IPv6 into your internal network (instead of 6in4), and use a private IP address on the WAN interface of the internal gateway.

Each internal subnet will need both an IPv4 address block (e.g. 172.20/16) and an IPv6 address block (e.g. 2001:470:3d:3000::/64). All IPv6 address blocks must fall within the overall address block being routed to you by your ISP. If you have nested subnets, each router will need to route an address block sufficient for all downstream subnets.

Taking this into account, create an address plan. For starters, you can use the same subnet divisions for IPv6 that you are currently using for IPv4. Sixscape (or other consulting groups) can help you with this, if you are not sure how to proceed.



You should go gradually, introducing IPv6 into one subnet or department at a time, or whatever makes sense for you. It should be coupled with training (this website will help, but may be overkill for non-technical users). Each subnet needs a source of Router Advertisements, that publishes the IPv6 prefix for that subnet.

Most workstation nodes running Windows, Linux, FreeBSD or Mac OS-X will simply start working with IPv6 (with SLAAC) with no further effort. For workstations, SLAAC is OK to begin with, but for the long term, each node should have a fixed, managed IPv6 address, and it should be registered in DNS.

Later, you can think about removing IPv4 (if there are no legacy devices that you can't upgrade), and using a translating web proxy to let your users access the remaining sites on the IPv4 Internet. An all-IPv6 subnet is a lot cleaner, more reliable, and cheaper to manage than a Dual Stack subnet. ARP and broadcast cause many problems on networks that include IPv4 (including Dual Stack networks).