Migrating to IPv6 with Windows Server 2008

Posted on July 14th, 2008 by Brian Nelson

As we discussed before (Windows Server 2008 IPv6 — the Future of Internet Protocol) the new IPv6 protocol is coming and there is no stopping it.

However, no one expects this to be a quick transition. IPv4 support will likely be necessary for years or decades to come.

Luckily, Windows Server 2008 comes equipped with standard features to help with the move to a new network protocol.

Allowing for interoperability between IPv4 and IPv6 networks is not a trivial process. Fortunately, the designers of IPv6 have already come up with most of the framework to handle the interplay.

At the top of the list is Intra-Site Automatic Tunnel Addressing Protocol or ISATAP (ah, more acronyms).

With ISATAP, when a network in your site that is running IPv6 needs to talk to a network running IPv4, a properly enabled router will encapsulate the IPv6 packets inside of IPv4 packets and in the reverse, add IPv6 headers to incoming IPv4 packets.

The best part is that there is nothing for the workstations or servers to do. For all they know, they are talking to the same kind of network.

What if your organization is all about IPv6, but they have to communicate over a non-IPv6 network like the Internet?

Another technology known as 6to4 automatically creates tunneling between the networks by temporarily packaging the IPv6 packets inside IPv4 packets and then returning them to their original state when they arrive at their destination.

What about an application that uses IPv6?

For that, Microsoft utilizes Teredo. In Windows Server 2003, Teredo wouldn’t work with domain member computers. Not any more. Now, Teredo is supported on domain member computers and domain controllers so there will be no seams in the IPv4 and IPv6 networks from an application standpoint.

What Do I Have to Do?

So far, there isn’t any work for the average systems administrator here. "Hey, what are we waiting for?"

Well, besides the network guys freaking out (this will be tougher on their end), there are a some Windows Server functions you’ll have to get right first.

One of them is DHCP. Right now, all of your DHCP servers are configured with IPv4 scopes and happily doling out those addresses to all comers. Windows Server 2008 supports DHCPv6 which is, of course, DHCP using IPv6 addresses.

Although a Server 2008 DHCP server can send out both kinds of addresses, there is still no way to “translate” how an IP address is assigned, so you’ll have to re-create your scopes to get the right IPv6 addresses out there to the right systems.

The tough part will be making sure that systems you want getting IPv6 addresses get IPv6 addresses and the others get the IPv4 addresses.

DNS is another tricky spot. IPv6 addresses will be AAAA (quad-A) records in your tables. Obviously, your IPv4 DNS servers won’t have any idea what those are.

Also, since there is no way the average non-photographic memory systems administrator will be able to memorize IPv6 addresses of more than a couple of severs (if any), name resolution is going to have to be more robust than ever.

To this end, all domain controllers will host DNS which will complicate your efforts to define who contacts which DNS process.

The good news is that configuring these services will be pretty much the same as it is now, only the input field will take IPv6 addresses instead of the four blanks separated by periods (and since IPv6 address can be abbreviated, there will be no more automatic cursor movement to the next field, so the backspace key will actually work if you fat finger part of the address instead of stubbornly refusing to move back to the previous dotted section).

For example, manually configuring an IP address takes place in the same way, on the same screen. You’ll put in the default address and default gateway in the same fields. The only difference is that you will be typing a lot more.

Benefits of IPv6

There is more in the move to IPv6 for you than just saving the Internet (a noble goal in and of itself).

The IPv6 standard allows for TCP to be offloaded down one level. So, your new network cards will handle TCP at the hardware level, and your old ones will still benefit from processing occurring in the miniport.

This means less work for your servers and more power for your users.

Another huge benefit is that you will finally be able to get rid of WINS!

A newer more robust service that works tightly with DNS called GlobalNames Zone will handle all the simple name (non-fully qualified) resolution for your network. In fact, this may be where you want to get started with your migration.

The biggest time saver will be the ability to make network configuration changes on the fly without a reboot.

IPv6’s stack allows for the ability to retain configuration settings so those late workdays where you have to stay just to make sure a reboot goes through are over (at least for IP configuration changes).

Thanks to the translation protocols provided at the router level and the fact that all Windows Server 2008 systems will have fully integrated IPv4 and IPv6 stacks means that the migration to IPv6 will be as painless as possible.

Of course, there is no way it will be pain free. Then again, if it was easy, everyone would do it, and you would get paid a lot less.

Related Posts:

Tags: , , , ,

3 Responses to “Migrating to IPv6 with Windows Server 2008”

  • Dave Lawlor Says:

    July 14th, 2008 at 12:12 pm

    Just a few clarifications -

    GlobalNamesZone is NOT dependent on a switch to IPv6 and can be implemented with IPv4. It IS tied to Server 2008 DNS though, but also recognize that while you can kill off WINS with GlobalNamesZone you have to manually update records while if you still leave WINS, the client currently updates itself, not a big deal for small networks, but with large ones could be a pain.

    Also this part:
    “The biggest time saver will be the ability to make network configuration changes on the fly without a reboot.”

    I can make IPv4 changes without rebooting server now, can you clarify that benefit?

    While there is a great need for external IP to be migrated to IPv6, I just don’t see the current need to mess around with it internally. You can put edge servers in place to handle all your external facing IPv6 work and do a NAT to internal networks. There are a lot better places companies can spend their limited IT dollars at the moment.

    Dave

  • Brian Says:

    July 17th, 2008 at 10:03 am

    Dave,
    Thanks for your comment. You are correct that GNZ is not dependent upon IPv6, but the article is about moving to IPv6 and you cannot use WINS on IPv6, so GNZ becomes necessary when migrating. You could implement GNZ prior to moving to IPv6. This is what I was alluding to when I said that GNZ might be where you want to start your migration. No one will pull off the move to IPv6 overnight, so you could be using GNZ for some time before flipping the switch. As someone who has experienced far too much frustration with WINS (particularly as it was coming up through the versions) I perhaps have an overdeveloped sense of derision for it.

    Regarding the need to migrate to IPv6. You are right that as of today there is no impending doom for those that choose not to do so. That was the point I made regarding how long IPv4 would need to be supported as the move the IPv6 takes place.

    However, I would submit the following to thoughts for consideration:

    First, it is common to get used to the status quo as normal. While it is true that many organizations have no compelling reason to move to IPv6 today, there may be those that consider its coming to be a huge relief to issues they may currently have.

    The infrastructure you describe would indeed work for a great many enterprises. However, it might prove less than optimal for others. While you don’t see the need to mess around with IPv6 internally, it would be equally valid for another administrator to say that he doesn’t see the need to mess around with edge servers and NAT just to keep his internal network running IPv4.

    Second, I always say, “We can make it work until we can’t make it work.” It may be years or even decades before the last IPv4 network is swept away. However, if history has shown us anything it is that we are pathetically ill equipped to predict what future technologies will bring. Twenty years ago, the concept of high-speed network access to individual homes would have fallen into the “I don’t see the need” category. Now, of course, the need is very great and some might say that certain providers were late getting there. Will something come along that makes IPv6 more compelling, or even necessary? Maybe, maybe not.

    All technology changes, especially the difficult or expensive ones, move forward on the basis of the carrot or the stick. Either there is something so beneficial in the new paradigm that business can’t afford not to move, or there is something so bad that will happen if they don’t move that they are forced to. We are at neither spot for the majority of organizations, but I have no doubt that the number with a need or benefit will increase as time goes by.

    For the mean time, I think that understanding the implementation that Microsoft has provided in Server 2008 allows organizations of all sizes and maturity levels to make the decision that is right for them. Perhaps a new start-up will use IPv6 right out of the gate and then they’ll never have to use NAT or edge servers. I’m sure there are other examples as well.

    I’d keep an eye out for case studies and white papers as companies make the move to see what benefits they are able to extract from IPv6.

  • R. Roberts Says:

    April 1st, 2010 at 7:00 am

    This was written on 2008 and needs to be updated. Most of what is stated here is incomplete and outdated.

Leave A Comment: