Monday, February 22, 2010

IPv6 design and deployment considerations for Microsoft's DirectAccess

One on the unique aspects about DirectAccess is the requirement of IPv6 for accessing internal resources. It requires that IT Pros get a lot more familiar with IPv6 and how and why they need to deploy it within their environment.

Much of Microsoft's current design guides and recommendation revolve around proof of concept deployments and not final design deployment models. I want to address that gap and give IT Pros some things to consider when discussing with their network teams the implementation of IPv6 they require for the POC vs what the final design might look like.

Currently Microsoft offers two main methods for internal IPv6 access methods within their design guides, the first is a transition technology called ISATAP and the second is to utilize Native IPv6. While ISATAP is a functional transition technology I believe it has several pitfalls that a POC overlooks and perhaps give a false impression of the potential deployment scenarios that might be supportable long term in an environment. First, since ISATAP is a tunneling technology and effectively looks like an overlay network it can be difficult to troubleshoot access problems. In addition, there are no specific management or monitoring tools for ISATAP requiring IT Pros to know all the areas where ISATAP could potentially have problems and how to diagnose it, I find that a tall order for many IT Pros given the general lack of knowledge regarding IPv6.

To top it off, ISATAP has an implicit sunset mechanism (if you host sees a Native IPv6 address it will use that first), it's really design to transition your network to Native IPv6, so the question I pose for IT Pros is:
Why not start with Native IPv6 and bypass these issues?

So what is involved with getting a Native IPv6 deployment working? There are several options available to start using native IPv6. Likely the easiest is to use a tunnel broker like Hurricane Electric to bring up a Native IPv6 network address range at you IPv4 location. Once you have this in place you have plenty of Native IPv6 address space to utilize in your network. The next logical step is to get full Native IPv6 transit services from a provider. With Comcast's recent announcement's around IPv6 and long standing IPv6 providers like Hurricane Electric there are options for both Enterprises and small businesses now.

I think serious consideration should be given to deploying Native IPv6 services as the solution for DirectAccess. It allows the greatest flexibility long term and avoids many of the pitfalls that may happen with an ISATAP deployment. I look forward to seeing if others feel differently.
- Ed

1 comment:

Anonymous said...

Hi Ed.

Even if one has IPv6 internal to one's network and an IPv6 IP address for all your connectivity to the Internet, aren't you still going to need to tunnel IPv6 through IPv4 because there is so little IPv6 framework on the backbone?

What is the cost to upgrade all the routers on the backbone and who is going to be willing to invest the money? My experience at one backbone provider is that they don't want to spend dime until they are forced to do so, at least in the US. Then add in all the third world where there is little money to invest in infrastructure and I see a long, slow process to get native IPv6 sufficiently deployed to be all that much use. Yeah, we are running out of IP blocks to assign, but NAT is cheap and can solve most, but not all of the problems. A 10.x.x.x used behind the scenes by the Telcos, Comcast means that all that they need is a few Gigabit connections to the backbone and pooled usage to cover a whole lot more growth

AFAIK, Japan is the only country with a significant IPv6 deployment at the moment and this makes it hard for the CFO types to be willing to spend the bucks proactively, and they hate doing it unless it has ROI on the quarterlies. Japan, which has traditionally taken a longer view, doesn't have this problem as badly.