The Windows TCP/IP stack was significantly beefed up in Windows Server 2003 and Windows XP, and in service packs for these platforms, to include selective acknowledgements, TCP receive window scaling, dead gateway detection, and other tweaks that made it perform better and more reliably than Windows 2000’s stack performed. But under the hood, Windows Server 2003’s stack was still pretty much the same old stack developed in the early 90s for the Windows NT platform. In other words, it was a stack originally designed to support only IPv4. And when Microsoft in the mid 90s saw the growing need for their platform to support IPv6 as well as IPv4, support for IPv6 was simply tacked on by adding a second transport layer driver Tcpip6.sys to the existing Tcpip.sys driver for IPv4. This resulted in a “dual stack” where transport for IPv4 and IPv6 were handled by separate drivers, and to enable IPv6, support administrators had to install the IPv6 protocol component on their Windows XP and Windows Server 2003 machines.
The dual stack approach also had other disadvantages. For example, it separated packet filtering functionality for each IP protocol, making it harder to configure firewalls on machines running both protocols. It also made life more difficult for developers of network applications that needed to support both IPv4 and IPv6. And it meant duplication of code and a less efficient pipeline for stack processing.
There were other problems and limitations with how TCP/IP networking worked in Windows Server 2003 and Windows XP. For example, dead gateway detection was introduced as a way to provide fail-over when the primary gateway (router) for the network went down. Large enterprises often have a backup router that can take over when the main router fails, and dead gateway detection enables their networks to make use of such backup routers. The way it works is that you would specify two gateways on your computers instead of one by adding a second gateway using the IP Settings tab on the Advanced TCP/IP Properties sheet of your network connection. Your computer would normally use the first gateway listed, but when the computer detects that gateway is not responding, it automatically switches over to the next gateway in the list. That’s fine, but what if the second gateway is your backup router, which is usually cheaper and slower than your main router, and then a short time later your main router comes back online? Unfortunately dead gateway detection in Windows Server 2003 has no built-in fallback mechanism, so even though the faster primary router becomes available again your computer continues to use the slower backup router as its default gateway. You either have to manually change the default gateway on your machines or reboot them to get them to use your primary router again. Also, while dead gateway detection worked (sort of, as you can see from the above) in Windows Server 2003, it could only handle failures in the local default gateway—failures in remote gateways can’t be detected or re-routed by this feature.
Another issue is that Windows computers currently do a poor job of isolating traffic between network interfaces. This is typically evident in VPN scenarios where a machine is connected both to the Internet and to a private corporate network. The fact that a single routing table is used to separate traffic destined to each of these networks means that if the user has local admin privileges on the machine they could conceivably modify the routing table in such a way as to compromise the security of the private network with respect to the Internet.
Finally, another problem with TCP/IP in existing Windows platforms is their poor performance over high bandwidth links that have a high latency (delay of about 50 msec or higher). This is caused by the way the stack adjusts the TCP send window using slow start and congestion avoidance, two standard TCP/IP algorithms that are showing their age since they were designed before gigabyte networking speeds became the norm. And the combination of high bandwidth and large latency is not an unusual one in today’s branch office environment. For example, in a DFS scenario you might have a server at the hub location replicate large quantities of data over a high-speed WAN link through multiple routers along the way, resulting in enough latency that the product of latency and bandwidth overwhelms the standard algorithms for send window adjustment. The result is that the WAN link is underutilized and replication takes longer than it should, sometimes much more longer, using an optimal send window configuration.
TCP/IP in Windows Vista
To address these issues, significant changes are being made to the TCP/IP networking stack in Windows Vista and the upcoming Longhorn Server. These changes are characterized by Microsoft as a “Next Generation TCP/IP Stack” that is designed to take Windows networking technologies into the next decade and beyond. Let’s take a look at how Vista’s new TCP/IP features address the issues we’ve identified above.
First, for enterprises planning on upgrading their networks soon to IPv6, Vista makes it easy—IPv6 support is installed and enabled by default (though enterprises not wanting to use IPv6 will be able to disable it). Not only that, the entire TCP/IP stack in Vista has been completely rewritten so that it’s now a “dual layer” architecture and not a dual-stack one. In other words, the stack has a single transport layer driver and not two separate ones (Tcpip.sys and Tcpip6.sys) like in earlier versions, one for IPv4 and one for IPv6. This change makes for a more efficient stack that processes packets better, and also makes it simpler for developers to write made-for-Vista applications that support both IPv4 and IPv6. A side benefit of re-architecting the stack is that Microsoft has built-in hooks in the stack so that developers can write applications that can tap into how a packet is being processed almost anywhere within the stack. Vista also completely integrates packet-filtering (firewall) capability for IPv4 and IPv6, which makes it easier to implement IPSec policies and firewall rules that handle both kinds of traffic simultaneously. There are also other architectural changes to the stack in Vista including Winsock Kernel (WSK), which is planned to replace the older Transport Driver Interface (TDI) layer, though for backward compatibility reasons TDI is still supported in Vista. But these deeper architectural changes are mainly of interest to developers of networking applications and not to network admins.
Next, Vista solves the problem of ensuring isolation of VPN traffic by linking logon sessions, routing tables, and network interfaces together into a logical construct called a routing compartment. This compartmentalization means, for example, that a laptop’s connections to the Internet and to the corporate network over a VPN are completely isolated from one another, which is good for the security of corporate networks. Vista also includes another enhancement in how computers handle unicast traffic directed to local network interfaces on the machine. Currently, when a packet on the local network segment has a destination address that matches the IP address of one of your machine’s network interfaces, all the network interfaces on your machine pick it up and try to process it. Obviously this only affects multihomed machines with two or more network cards. This approach gives good network connectivity for the machine, but it does mean unnecessary processing occurs, plus it makes your computer susceptible to a certain kind of network attack that targets multihomed machines. In Vista however, only the network interface whose address matches the destination address actually pulls the packet from the wire and processes it. The basic result of all these changes however is more secure network connectivity in Vista than in previous Windows platforms.
Vista also resolves the problem of lack of fallback for dead gateway detection in previous versions. Vista uses a similar kind of method that IPv6 uses for detecting unreachable neighbors on IPv4 networks, which essentially involves monitoring TCP sessions and exchanging ARP packets. The upshot of this is that Vista is more efficient than previous platforms in detecting when a remote router goes down. When it detects this situation, the stack switches to the next default gateway in the list, but the stack then continues to monitor the previous gateway and if it returns to life, then Vista switches back to the primary gateway. This makes it easier for enterprises to ensure optimal connectivity with remote branch offices by ensuring that backup routers will only be used when they’re needed and not a minute more.
Vista handles the issue of poor performance over high-bandwidth, high-latency connections by using a more aggressive TCP send window adjustment algorithm than the older slow start and congestion avoidance algorithms used on previous platforms. This new approach is called Compound TCP (CTCP) and it can significantly increase throughput in such scenarios like the DFS replication environment described previously (of course, DFS in Windows Server 2003 R2 has significant improvements of its own such as Remote Differential Compression that help mitigate such issues and I’ve described these enhancements in my previous article on the subject).
Finally, Vista supports a number of recent RFCs that provide greater reliability and performance on wireless networks, which are rapidly becoming the technology of choice for companies wanting to save on wiring costs. These enhancements help deal with the kinds of issues that typically prevent wireless networks from performing as well as wired ones, such as electromagnetic interference, non-stationary clients, attenuation of signal with distance, and so on. These impediments tend to make TCP/IP traffic drop packets in wireless environments, causing timeouts and retransmissions that can reduce throughput. Vista’s changes address these kinds of issues and the result is that Vista machines should boast significantly better performance in wireless environments than previous Windows versions could provide.