Windows DevCenter    
 Published on Windows DevCenter (
 See this if you're having trouble printing code examples

IPv6 and IPsec in the Enterprise Today

by Mitch Tulloch

As a follow-up to my previous articles on Windows DevCenter about the enhanced IPv6 and IPsec support in Windows Vista, I wanted to share with readers the following interview I had with William Dixon, president of V6 Security and former Microsoft program manager for Windows Networking. I asked William a number of questions about the current state of IPv6 deployment around the world and the changing use of IPsec in enterprise environments. Here are his answers.

Tulloch: William, ever since IPv6 was developed, it seems to me that most network administrators have pushed it to the back of their minds as something they may or may not have to deal with someday. Is this mindset changing?

Dixon: Yes, I hope it is clear to network administrators that IPv6 is finally deployable. But there are different scenarios. For example, it can be used only on the internal LAN, to communicate between peers on the same switch. Or some hosts can be IPv6-accessible while others are not (using dual-stack hosts). Network admins should definitely review Tony Hain's analysis that indicates new IPv4 address allocations may not be available in as soon as five years. So large organizations simply must start planning the transition.

IT admins in the United States have probably heard that the U.S. Department of Defense and federal government have mandates to buy IPv6-capable systems and to transition to IPv6-capable networks within a few years. Windows XP SP2, Windows Mobile 5.0, and Mac OS X support IPv6 now, though not all platforms support a full IPsec implementation. A deployable IPsec implementation for IPv6 should be in Windows Vista. So administrators will start seeing IPv6 on their network soon if it isn't already there.

Related Reading

Windows Server Hacks
100 Industrial-Strength Tips & Tools
By Mitch Tulloch

I also would expect software developers to realize they have to make their applications IPv6-capable and thus have an IPv6 environment for testing. Microsoft has published the Checkv4.exe tool for developers to check whether IPv4 dependencies exist in their source code. It is not sufficient to just test between two IPv6 peers on the local link. They should test with routed native IPv6-to-IPv6 and the major transition scenarios of 6-to-4, ISATAP, and Teredo (if home users are intended to use the software). Microsoft has said they plan to make IPv6 active and preferred by default in Windows Vista. So they should pay particular attention to this in their testing of the Vista beta release. Microsoft recommends home gateways have 6-to-4 on by default. So both host and network admins are going to have to spend the time to understand the basics, just like they understand how to provide and manage IPv4 connectivity today. This would include VPN remote access. There is an opportunity now to avoid the cost and management burden of VPN tunnels by using native IPv6 IPsec capabilities. But it will take some planning to achieve the same level of safety with IPv6 IPsec.

Companies with personnel traveling to Asian countries should expect to ramp up on IPv6 faster. When your employee is trying to connect from a hotel in Tokyo, for example, they may get an IPv6 address instead of an IPv4 address. This means IT admins are going to have to test the IPv6 compatibility of applications and internet services used on laptops, PDAs, and tablet PCs, and contact their software vendors about IPv6 compatibility. They will also need to train the Help Desk personnel to recognize this situation. Imagine all the networked equipment, wireless internet, and cellular service needed for staff, participants, facilities, and attendees at the 2008 Beijing Olympics where IPv6 will be dominant.

Tulloch: If large enterprises are starting to consider IPv6 deployments, what about small and mid-sized businesses? Are they facing any pressure to deploy IPv6?

Dixon: I don't think small companies have any special pressure to deploy other than what I mentioned above. But because their networks are less likely to be managed, they are more likely to be using IPv6, at least between peers on the local LAN. The transition should be seamless if the applications aren't IPv4 dependent. Sometimes you will get an IPv4 address; sometimes you get an IPv6 address; hopefully you won't care.

Tulloch: Which parts of the world are experiencing the most growth in IPv6 deployments? Why?

Dixon: Asian countries have the greatest deployment and growth of deployment now because of three factors: strong government support for transition, many more people going online, and a rapid adoption of wireless and small network devices in their online population (cellphones, PDAs, VoIP phones, gaming consoles). Japan, South Korea, Taiwan, and China are the ones heavily on board with IPv6 for all types of networking. I would expect the growth of IPv6 approximates the growth of online users, but it will be even greater as IPv4 services in Asian countries convert. Based on figures from Internet World Stats, Asia has 3.6 billion total population, and Europe and North America have about 1.1 billion combined. If Asia continues a 200% increase in online users in the next five years, it will have 40% of its population online, 1.47 billion people, about 500 million more than Europe and North America combined (896 million).

I made several assumptions in that calculation and it could be wrong. It would be better to measure devices online rather than people, for example. But you can see that IPv6 growth will be more significant in Asia for many reasons. I would expect them to be using only IPv6-capable products. So in many cases they would not want to pay the cost of providing legacy IPv4 connectivity to what will be an increasingly small fraction of users. As I mentioned earlier, new allocations simply won't be available for new networks they deploy. So IPv4 service, if available, would go through multiple layers of NAT and consequently have numerous application compatibility issues.

Tulloch: What difficulties are companies finding in moving from IPv4 to IPv6? How are they overcoming these difficulties?

Dixon: There is the initial learning curve required to adopt a new networking technology. We might think that IPv6 deployment in Europe and North America would be strong as IPv4 providers add IPv6 service. The IPv6 prefix allocations in Europe and North American registries seem to indicate this. However, it is hard to define a business model where you make more money for essentially the same service (end-user connectivity). An October 2005 presentation by the Cooperative Association for Internet Data Analysis (CAIDA) reported that many major internet service providers in North America and Europe may not have the financial resources necessary for investment in infrastructure to push IPv6 to the consumer (see this PDF).

If this is true, then small companies will start using IPv6 internally, and configure 6-to-4 gateways with a firewall to the IPv4 internet service provider. For getting ISP-routed IPv6 service, it seems industry partnerships will be needed to help ISPs fund the network investment. This would be based on easily marketable new applications that require IPv6, like efficient multicast music or video streaming and peer-to-peer video chat.

Tulloch: Can you point administrators thinking of planning IPv6 deployments to any good resources, online or otherwise?

Dixon: I have found two books to be incredibly useful:

Otherwise, Microsoft provides a ton of free guides, for example how to set up a test lab, how to assess application compatibility, etc.

Tulloch: What about IPsec usage in the enterprise? There seems to be a solid move afoot to use IPsec to secure internal traffic on enterprise networks as opposed to traditional VPN remote-access uses. Why this shift in thinking?

Dixon: Two things are happening. First, it's a realization that servers on the internal IPv4 network need to have much higher protections against network attacks. IT security professionals are using IPv4 IPsec to help meet Sarbanes-Oxley, HIPAA, FISMA, and other regulatory compliance requirements that mandate tighter controls and auditing for access to data. Server hardening and firewalls just don't reduce the attack surface sufficiently because reconnaissance and attacks are directed at ports that must be accessible for required applications and services. So by using IPsec (for IPv4 or IPv6), only trusted client machines are allowed TCP/IP network access to the server. IPsec adds a whole new layer of defense, mutually authenticated machine trust, to normal user authentication. Further, it strongly protects every packet against man-in-the-middle attacks. This dramatically reduces the potential sources from which an attack can reach the applications on the server. This function of IPsec performs only authentication and authorization of traffic. It doesn't have to encrypt the traffic unless you require encryption. You can even extend the idea of protecting the server to protecting all clients as well. Thus only trusted machines can gain network access to other trusted machines. You can even define a specific group of client machines and authorize only that group of machines for access to a specific server. Clients and servers can have dynamic IP addresses. So IPsec is serving a simple host firewall, only IPsec authentication is used to allow trusted machines inbound access through the firewall. For the highest level of control over host access, you would use an IPsec policy in combination with a host firewall policy.

Second, IT admins are realizing that IPv4 IPsec is already available in their Windows 2000 and later platforms. So there is no additional client license cost. And it is fairly easy to use. By that I mean, administrators centrally manage IPsec configurations (called policies) in Active Directory, and assign it using normal Group Policy; it authenticates using Windows domain trust (Kerberos, and works cross-forest), many types of PKI certificates, or a preshared key; and it is transparent to the applications, and works over the existing IPv4 network. If you are encrypting traffic then affordable client and server IPsec acceleration network cards are available, such as the Intel Pro 100 S adapter family.

The best case study is Microsoft deploying IPsec to 210,000 domain members to protect these machines from about 100,000 non-domain internal systems, visitors, attackers, and potential breaches in perimeter security. Windows IPsec transport mode is capable of being used through PPTP or L2TP/IPsec VPN tunnels as well as over 802.1x authenticated network connections for both wireless and wired. Sometimes people want to choose between 802.1x or IPsec. But they do different things. IPsec protects access to the internal host and each packet end-to-end in ways defined for that host and application traffic. While 802.1x is great for controlling access to the internal network, not all buildings have 802.1x-capable switches. And 802.1x controls don't protect against authenticated machines and users (e.g. a worm or malicious user) attacking internal systems. So host-based IPsec gives them a way to tightly lock down access to sensitive data servers, encrypt if necessary, audit host access, and require machines to be members of their managed domains.

Tulloch: What difficulties do network administrators face when they implement IPsec on their internal networks like this?

Dixon: Often there is some confusion related to their experience with IPsec used for router-to-router tunneling or VPN remote access. The client-server scenarios I've referred to use IPsec transport mode, not tunnel mode. In the Windows implementation, IPsec transport mode doesn't require static IPs or Windows Certificate Authority certificates. It can be used with DHCP-addressed clients and servers, and with many third-party PKI vendors. I guess the most common technical barrier I see is the conflict created by having a third-party IPsec VPN client installed which disables the native Windows IPsec capabilities. The second most common technical issue is that large internal networks often have some kind of internal NAT. However, Windows IPsec supports UDP encapsulation for NAT traversal. So clients behind an internal NAT can use IPsec transport mode to hosts on the rest of the internal network. The most common policy barrier is the requirement to inspect traffic. You can configure IPsec to provide authentication only. Or you can terminate IPsec at the inspection point, create a trusted proxy for example.

I said earlier IPsec is "fairly easy" to use because like any technology there is a learning curve to overcome. Detailed knowledge about the capabilities of the implementation is required to design IPsec policies that work for a particular environment.

To help address all of the planning and impact considerations, I co-authored with Microsoft a very detailed planning and troubleshooting guide called Server and Domain Isolation Using IPsec. I was really happy to publish this guide so we could make it easier to design solutions. My company now is focused almost exclusively on helping deploy this and other scenarios using IPsec for IPv4 and IPv6, and on training IT services companies to be able to do this.

Tulloch: Can you point network administrators to some good resources for deploying IPSec to secure internal networks?

Dixon: It's probably best to rely on each vendor's documentation about their IPsec implementation. While at Microsoft, I helped author most of the Windows IPsec guides, online help, resource kit chapters, white papers, etc. The architecture and design white papers are the place to start for envisioning how IPsec might be used to solve your network security issues. The most in-depth guide we wrote about the technology was the Windows Server 2003 IPsec Technical Reference. The best troubleshooting guide is Chapter 7 of the Server and Domain Isolation Guide. (See and

Tulloch: Finally, any thoughts concerning IPv6 and IPsec enhancements in the upcoming Windows Vista platform?

Dixon: I'm very happy with the integration of Windows Firewall, IPsec Policy, and full IPsec for IPv6 in Windows Vista. It is important to understand that you can simulate IPv6 security scenarios with IPsec for IPv4 now. Windows Vista will be the first release to make available IPsec options for IPv6 sockets so that applications can integrate IPsec protection for their traffic. It pains me to know that developers will probably wait several years until Windows Vista becomes as common as Windows 2000 clients are now.

I think the Network Access Protection (NAP) capabilities of Windows Vista and Longhorn Server are extremely interesting. NAP can do client health checks not only during the 802.1x and DHCP authentication, but also during IPsec IKE authentication. Thus a Server Isolation scenario today will be able to provide even stronger assurance and authorization using IPsec-based NAP policies.

There is one problem still that is really important to solve so that applications will have end-to-end IPv6 connectivity: the barrier of the host firewall. Host firewalls now are extremely common. So how would a peer-to-peer IPv6 application connect to another peer? I think the answer could be that the application uses IPsec socket options to authenticate and the firewall can then authorize that inbound connection. I've just finished a paper to describe this if anyone is interested at V6 Security, and the paper is titled "Unblocking IPv6 Applications: Safely Connecting Through Host and Edge Firewalls with IPsec."

Tulloch: Thanks for your time, William, and for being willing to share your knowledge with O'Reilly readers.

Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.

Return to the Windows DevCenter.

Copyright © 2009 O'Reilly Media, Inc.