“The Real IPv6, Part 1 of 13″ - Microsoft Direct Access

  Over the next few months, we plan to articulate the real-world applications of IPv6 right now.  This is not going to be one of those discussions that highlight beautiful IPv6 features stuck in the theoretical and things that don’t actually exist in nature (mandated IPSec, QoS, etc).  We are going to show you what is actually happening in the industry currently and what applications are leveraging IPv6.  Obviously, this is going to help everyone’s business case to drive adoption further along.  Without further ado, the juiciest use of IPv6 today: Microsoft’s Direct Access  Enjoy!

Real-World Feature #1:  IPv6, IPSec and Microsoft’s Direct Access

Direct Access from Microsoft solves the following problems with remote access VPNs, IPv6 and IPSec:

  1. VPNs are hard to manage from a client and server side.  Servers need to be maintained by qualified personnel, and clients need to be individually configured with clunky third-party software (ie Cisco VPN client).
  2. IPSec in either IPv4 and IPv6 is not at all automated.  Sure there are ways to automate key exchange, but each of those parameters need to be configured (type, encryption key, integrity, lifetime, re-key, etc.)  See the IKEv2 RFC for details on this. The only thing close to this is PKI for the DoD. However, even that has not been integrated with IPSec and IPv6 yet.
  3. IPv6 deployment is difficult for some to manage.  In the meantime, there are ways to transition into it.

So given these problems, how does Direct Access solve it?  Direct Access automates the VPN process.  How on earth can it do this anyway?  Well, if you have the soon-to-be released Windows 7 client and a Microsoft Server 2008, Release 2 then it’s all ready to work out of the box.  I am sure open source implementations are soon to follow.  In fact, if anyone in the Blogospere, Twitterverse or Facebookland have any ideas about this, please let me know!

Currently, host to server VPNs don’t really use layer-3 IPSec.  In fact, IPSec is usually sandwiched between the data and a TCP or UDP header.  Not the most efficient use of IPSec.

How does Direct Access work anyway?  Taken from the great folks at Microsoft is a diagram that shows the full session:

  1. You boot up the Windows 7 client
  2. It begins to configure IPv6.  If it can’t configure a native IPv6 address it wil attempt other mechanisms: 6to4, Teredo, and a new encapsulation technique called IPv6-in-HTTPS.  So native IPv6 is not required.  Word of caution here is the enterprise network should decide on the mechanism to use and not expose the network to others.  The reasoning for this is because there are huge security holes in having these tunneling mechanisms open and not being used and monitored.
  3. Once the IPv6 connection is made, the Windows 7 client automatically negotiates the IPv6 IPSec session (either in tunnel or transport mode).  The great thing about this mechanism is that the DoD’s PKI and CAC-enabled system can be integrated very easily!
  4. Now the client is a permanent fixture of the local network.  So virus updates to Active Directory policies can be pushed to these remote users just like they were on the local segment.

Take a look at the picture below to get a visual understanding (Courtesy of MS Technet).

Direct Acces transformation

“Transforming Your Edge Network with DirectAccess

References

Here’s a list of further reading on Direct Access and how IPv6 is integrated into it!

What’s next??  Part 2 will discuss “Global enterprise
instant messaging AKA IPv6 Multicast messaging
.”

Until later..

Jeremy

Update 24 July 2009: Added drawing from Tom Basham’s blog on DirectAccess, IPv6 and IPv4 Networks on My Digital Life

Leave a Reply



Creative Commons License
Command Information Weblog by Command Information is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.