Planning Your Cutover to IPv6 for your Microsoft Windows Environment

Getting to IPv6 in a Managed and Orderly Manner

In this blog post on IPv6, I’m going to cover what we’ve found to be a well organized and managed process of getting from an IPv4 environment to an IPv6 environment, effectively putting the chicken and the egg in the right sequence…

This is the eighth blog post on IPv6 in this series of hands-on best practices.  I’ve covered everything from basic understanding of IPv6 addressing and acquiring an IPv6 address block to configuring Static IPv6 addresses on Windows 2008 R2 servers, Windows 7 workstations, and configuring DNS, to configuring DHCPv6 for dynamic addressing of IPv6 addresses in a Windows networking environment to configuring Active Directory to Support IPv6, to configuring IPv6 Routing through IPv4, to best practices at migrating application servers to an IPv6 environment.

If you are interested in any of these topics, go to http://www.networkworld.com/community/morimoto where I cover a wealth of practical hands-on implementation techniques on actually creating IPv6 addressing schemes, implementing IPv6, and configuring Microsoft Windows-based systems for IPv6…

So for this point, this is about planning and organizing your shift from IPv4 to IPv6 along with tips and guidance along the way.

Step 1: Getting your IPv6 Address BlockAs I covered in my blog post “IPv6 Addressing, Subnets, and Private Addresses”, you need to get your IPv6 address block so you know what addresses you plan to use for your IPv6 implementation.  If you plan to use Unique Local Addresses (ULAs) in IPv6, similar to private (internal) addresses in IPv4, that blog post covered how those addresses worked in an IPv6 environment.  But effectively, having an IPv6 block of addresses is the first place to startStep 2:  Architecture Design for IPv6 MappingThe next step is determining how you want to setup your IPv6 architecture, effectively how you plan to subnet your IPv6 environment.  A word of caution is to not just take your existing IPv4 subnetting configuration and apply the exact same subnets for IPv6.  Take a moment to stop and think about your design.  It’s not any harder to change your IPv6 subnet structure if you want to, and now would be the time to do so.

Few things to take in consideration is that IPv6 does not have the same limitations as IPv4 had regarding subnet masks.  If you were using a Class C addressing space in IPv4 using a 255.255.255.0 subnet mask giving you address space for 256 devices, with IPv6, your device boundary is 18-quintillion devices per subnet, so “masking” is no longer a barrier.  However, with IPv6, we haven’t changed the laws of physics nor the limitations of Ethernet collisions, so even if you were to put 18-quintillion devices on a single physical subnet, the devices likely won’t be able to communicate at all because of the etherent collissions occurring on the subnet. So there’s a happy medium of not having a mental barrier of keeping subnets “the same” just because, to trying to stuff too many devices on a single subnet that creates collision in communications.

If you have virtual LANs (VLANs) setup, you can redo your VLAN structure when you switch to IPv6, and with many devices, you can have separate VLANs for IPv6 traffic than you have for IPv4 traffic, so with the same switch and router infrastructure, you can change your subnetting when you merely add IPv6 routing and communications to your environment.  Again, there’s a whole process of sitting down and putting together an IPv6 architecture that makes the best sense for the way your organization is currently structured, and not mirror the design that may have been setup for IPv4 years (or decades) ago.

Step 3:  Implementing your First IPv6 ServerSince everything really depends on authentication and name resolution, the first servers that typically get implemented with IPv6 in an environment are Active Directory Global Catalog (GC) and Domain Controller (DC) systems, along with DNS servers.  If your AD and DNS are still running on Windows 2003 / Active Directory 2003, this is where a migration from AD/2003 to AD/2008 R2 comes in.  You would complete your migration off of AD/2003 into a fully IPv6/IPv4 ready AD/2008 R2 environment.  It’s not difficult to do, takes a little planning to make sure all of your applications support AD/2008 R2 and the schema, and then you advance your environment to AD/2008 R2.  Get all of your GCs and DCs and DNS servers up on IPv6 so you know your naming and authentication structure is setup and working properly with IPv6.

In my blog post on “Configuring Active Directory to Support IPv6”, I provide step by step guidance on how to move an organization from AD/2003 or AD/2008 to AD/2008 R2.

Step 4:  Static AddressingThe next step is to statically address all servers and devices that you want to have IPv6 statically addressed.  This is typically your application servers like Exchange, SharePoint, Web Servers, accounting servers, ERP servers, etc, both servers on Windows and servers not on Windows.  Don’t worry about upgrading “everything” to IPv6, this is not a requirement at this point, so if you have some old application that is running Windows 2000, or a version of Linux that doesn’t support IPv6, don’t sweat it.  The whole purpose of statically addressing stuff with IPv6 addresses is so that when you get to the next step and put in a DHCPv6 server, that those servers that have been waiting for a DHCP issued addressed are statically addressed the way you want to address them.

My blog post on “IPv6 Static Addressing” covers this topic on a hands-on step by step guidance manner.

Effectively, take a good inventory of all of your systems, statically address stuff you can, and have a list of servers, systems, devices that haven’t been addressed yet that you’ll need to get to at some point down the line.

Step 5:  Configuring DHCPNow that you’ve statically addressed servers that you can address, you can setup DHCPv6 in your environment to push out IPv6 addresses for dynamic devices.  This will get Windows Vista, Windows 7, Apple Mac Leopard and SnowLeopard desktops and laptops with a qualified IPv6 address.

My blog post on “Setting up DHCPv6 to Dynamically Issue IPv6 Addresses in a Network” covers this topic on a hands-on step by step guidance manner.

At this point, your client systems will be able to communicate IPv6 with systems on the subnet with IPv6 enabled.  If your servers are on the same subnet as the client systems, you now have end to end IPv6 communications going internally.

Step 6:  Implementing IPv6 Remote AccessAt this stage of an IPv6 initiative, implementing something like Microsoft DirectAccess is a great tool that leverages IPv6 that has been put in place in the previous 5 steps, but can work in an existing IPv4 environment through the implementation and use of Microsoft Unified Access Gateway (UAG) 2010.  By implementing an IPv6 application and leveraging the policy-based VPN-less remote access capabilities of DirectAccess, an organization can start seeing and receiving the benefits of having IPv6 in the environment.

It’s usually by this step that the organization needs something that users can see and use that utilizes IPv6, as the next step of getting to the InterNetworking piece is a longer / drawn out process, so using IPv6 through DirectAccess is a good addition at this point.

My blog post on “Configuring IPv6 Routing through IPv4” has a whole section on step by step implementation of DirectAccess along with configuration guides and an implementation video

Step 7:  Configuring Internetworking for IPv6With client systems and servers configured to communicate IPv6, the next step is to inventory, identify, and configure InterNetworking devices such as switches, routers, appliances, gateways, WiFi access points, and other devices to support IPv6.  As much as you can get your InterNetworking devices all updated prior to even turning on IPv6 on your servers and clients, if you wait until you get the InterNetworking all setup before you get your servers and clients setup, it could be a long time before you get IPv6 going in your environment.

With IPv6 enabled clients and servers, for devices that are already IPv6 ready, a quick configuration of the device(s) and you now have IPv6 communications, so for this chicken and the egg, we usually start with Windows servers and clients, and then get to the Internetworking devices in the configuration process.

Usually for upgrading or configuring internetworking devices, start with Core Routers and Internet connections so that your main points of communications are setup and working properly with IPv6.  Eventually you get to wireless access points, remote sites, and other devices such as printers, fax gateways, and the like.

This could be a time consuming process, for some very large organizations, the InterNetworking piece can be months or several months to address IPv6 addressing and routing.  In many cases, devices that don’t have IPv6 support will need to be replaced (if they can’t be updated).  So having an inventory of all devices and systematically walking through the process of updating the device, setting proper IPv6 addresses, configure IPv6 routing, buying new hardware to replace old hardware, and the like will be a task of organization and coordination.

Step 8: Final Assessment of IPv6 CompletionBy this stage of the process, the organization will have IPv6 pretty well implemented throughout the environment.  A task of going through and taking an inventory of all devices and validating that all devices are communicating over IPv6 is a scan of the internal environment to confirm configuration and operation of IPv6 (and not IPv4).  For organizations that have very old systems, devices, and other equipment that is not and will not be IPv6 compatible, workarounds can be devised to continue to allow IPv4 for those specific systems or applications.  Just knowing the state of the environment is helpful so that the organization has clear isolation of what is not switched over to IPv6.

That’s the process…  There are a lot of little things that go on during and inbetween steps, but thse are the larger items in the process.  With the various blog posts I’ve made on the topic of IPv6, there are planning guides, configuration guides, and step by step implementation guides on getting IPv6 working in your Microsoft Windows-based environment.

I need to think of other stuff that might be helpful to cover about configuring IPv6 in a Microsoft Windows environment, the whole impetus of this blog post series…  If I missed stuff, please leave a comment on this post of what else I can write on, and I’ll blog more content ongoing…

I hope this series was helpful!  I really wanted to put a real world spin on HOW to actually implement IPv6 in a Windows network environment, something that I was surprised the Internet has sorely lacked comprehensive step-by-step guidance on the matter in a straight forward manner.

I will be speaking at Microsoft TechEd 2011 in New Orleans (May 16th-19th, 2011) http://northamerica.msteched.com on IPv6 and DirectAccess among other topics.

Cheers!

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Take IDG’s 2020 IT Salary Survey: You’ll provide important data and have a chance to win $500.