Welcome  |  Sign In
 | 
Click to Rate and Give Feedback
TechNet
TechNet Library
Networking
 New Networking Features in Windows ...
New Networking Features in Windows Server 2008 and Windows Vista
Published: February 15, 2006 | Updated: February 15, 2008
On This Page

Abstract Abstract
Introduction Introduction
Protocols and Core Networking Components Protocols and Core Networking Components
Wireless and 802.1X-based Wired Connections Wireless and 802.1X-based Wired Connections
Network Infrastructure Network Infrastructure
Removal of Technologies Removal of Technologies
Summary Summary
Related Links Related Links

Abstract

Microsoft® Windows Server® 2008 and Windows Vista™ include many changes and enhancements to networking technologies. This article describes the changes to protocols and core networking components, wireless and 802.1X-authenticated wired technologies, and network infrastructure components and services in Windows Server 2008 and Windows Vista.

Introduction

Networking and communications are critical for organizations to meet the challenge of competing in the global marketplace. Employees need to connect to the network wherever they are and from any device. Partners, vendors, and others outside the network need to interact efficiently with key resources, and security is more important than ever.

This article is a technical overview of networking and communications enhancements in Windows Server 2008 and Windows Vista to address connectivity, ease of use, management, reliability, and security. With Windows Server 2008 and Windows Vista, IT administrators have greater and more flexible options for managing networking infrastructure, protecting their networks by requiring computers to prove their system health, deploying settings for authenticated wireless and wired connections through Group Policy or scripts, and deploying protected traffic scenarios.

Protocols and Core Networking Components

Windows Server 2008 and Windows Vista include many changes and enhancements to the following protocols and core networking components:

  • Next Generation TCP/IP Stack

  • Domain Name System

  • Quality of Service

  • Server Message Block 2.0

  • Http.sys enhancements

  • WinINet enhancements

  • Windows Sockets enhancements

  • Network Device Interface Specification (NDIS) 6.0 and 6.1

  • Network Awareness

  • Windows Peer-to-Peer Networking enhancements

  • Windows Firewall enhancements

  • Internet Protocol security (IPsec) improvements

Next Generation TCP/IP Stack

Windows Server 2008 and Windows Vista include a new implementation of the TCP/IP protocol stack known as the Next Generation TCP/IP stack. The Next Generation TCP/IP stack is a complete redesign of TCP/IP functionality for both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) that meets the connectivity and performance needs of today's varied networking environments and technologies.

For a complete list of resources, see the Next Generation TCP/IP Stack Web page.

Receive Window Auto Tuning

The TCP receive window size is the amount of data that a TCP receiver allows a TCP sender to send before having to wait for an acknowledgement. To correctly determine the value of the maximum receive window size for a connection based on the current conditions of the network, the Next Generation TCP/IP stack supports Receive Window Auto-Tuning. Receive Window Auto-Tuning continually determines the optimal receive window size on a per-connection basis by measuring the bandwidth-delay product (the bandwidth multiplied by the latency of the connection) and the application retrieve rate, and automatically adjusts the maximum receive window size on an ongoing basis.

With better throughput between TCP peers, the utilization of network bandwidth increases during data transfer. If all the applications are optimized to receive TCP data, then the overall utilization of the network can increase substantially, making the use of Quality of Service (QoS) more important for networks that are operating at or near capacity. For more information, see "Quality of Service" in this article.

For more information about Receive Window Auto-Tuning, see Performance Enhancements in the Next Generation TCP/IP Stack and TCP Receive Window Auto-Tuning.

Compound TCP

For TCP connections with a large receive window size and a large bandwidth-delay product, Compound TCP (CTCP) in the Next Generation TCP/IP stack aggressively increases the amount of data sent at a time by monitoring the bandwidth-delay product, delay variations, and packet losses. CTCP also ensures that its behavior does not negatively impact other TCP connections. In testing performed internally at Microsoft, large file backup times were reduced by almost half for a 1 Gigabit per second connection with a 50 millisecond round-trip time. Connections with a larger bandwidth-delay product can have even better performance.

Receive Window Auto Tuning optimizes receiver-side throughput and CTCP optimizes sender-side throughput. By working together, they can increase link utilization and produce substantial performance gains for large bandwidth-delay product connections.

CTCP is enabled by default for computers running Windows Server 2008 and disabled by default for computers running Windows Vista. You can enable CTCP with the netsh interface tcp set global congestionprovider=ctcp command and disable CTCP with the netsh interface tcp set global congestionprovider=none command.

ECN Support

When a TCP segment is lost, TCP assumes that the segment was lost due to congestion at a router and performs congestion control, which dramatically lowers the TCP sender’s transmission rate. With Explicit Congestion Notification (ECN) support (RFC 3168) on both TCP peers and the routers in the routing infrastructure, routers experiencing congestion mark the packets as they forward them. TCP peers receiving marked packets lower their transmission rate to ease congestion and prevent segment losses. Detecting congestion before packet losses are incurred increases the overall throughput between TCP peers. Windows Server 2008 and Windows Vista support ECN, but it is disabled by default. You can enable ECN support with the netsh interface tcp set global ecncapability=enabled command.

For more information, see Explicit Congestion Notification (ECN) for TCP/IP.

Enhancements for High-loss Environments

The Next Generation TCP/IP stack supports the following RFCs to optimize throughput in high-loss environments:

  • RFC 2582: The NewReno Modification to TCP's Fast Recovery Algorithm

    The NewReno algorithm provides faster throughput by changing the way that a sender can increase their sending rate when multiple segments in a window of data are lost and the sender receives a partial acknowledgement (an acknowledgement for only part of the data that has been successfully received).

  • RFC 2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP

    SACK, defined in RFC 2018, allows a receiver to indicate up to four noncontiguous blocks of received data. RFC 2883 defines an additional use of the fields in the SACK TCP option to acknowledge duplicate packets. This allows the receiver of the TCP segment containing the SACK option to determine when it has retransmitted a segment unnecessarily and adjust its behavior to prevent future retransmissions. The fewer retransmissions that are sent, the better the overall throughput.

  • RFC 3517: A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP

    The implementation of TCP/IP in Windows Server 2003 and Windows® XP uses SACK information only to determine which TCP segments have not arrived at the destination. RFC 3517 defines a method of using SACK information to perform loss recovery when duplicate acknowledgements have been received, replacing the fast recovery algorithm when SACK is enabled on a connection. The Next Generation TCP/IP stack keeps track of SACK information on a per-connection basis and monitors incoming acknowledgements and duplicate acknowledgements to more quickly recover when multiple segments are not received at the destination.

  • RFC 4138: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)

    Spurious retransmissions of TCP segments can occur when there is a sudden and temporary increase in the round trip time (RTT). The F-RTO algorithm prevents spurious retransmission of TCP segments. The result of the F-RTO algorithm is that for environments that have sudden and temporary increases in the RTT, such as when a wireless client roams from one wireless access point (AP) to another, F-RTO prevents unnecessary retransmission of segments and more quickly returns to its normal sending rate.

  • RFC 3042: Enhancing TCP's Loss Recovery Using Limited Transmit

    With Limited Transmit, when TCP has additional data to send on a connection and two consecutive duplicate ACKs have been received, TCP can send additional segments on the connection when the receiver's advertised window allows the transmission of the additional segments and when the additional segments contain data that is within two segments beyond the current congestion window. The ability of TCP to send additional segments helps ensure that fast retransmit can be used to detect segment losses, rather than waiting for an RTO timer expiration.

For more information about these enhancements, see Performance Enhancements in the Next Generation TCP/IP Stack.

For more information about TCP connections, data flow, and retransmission and timeout behavior, see the Windows Server 2008 TCP/IP Protocols and Services book from Microsoft Press.

Neighbor Unreachability Detection for IPv4

Neighbor Unreachability Detection is a feature of IPv6 in which a node tracks whether a neighboring node is reachable, providing better error detection and recovery when a neighboring node suddenly becomes unavailable. The Next Generation TCP/IP stack also supports Neighbor Unreachability Detection for IPv4 traffic by tracking the reachable state of IPv4 neighbors in the Address Resolution Protocol (ARP) cache. IPv4 Neighbor Unreachability Detection determines reachability through an exchange of unicast ARP Request and ARP Reply messages or by relying on upper layer protocols such as TCP. With IPv4 Neighbor Unreachability Detection, IPv4-based communications benefit by determining when neighboring nodes such as routers are no longer reachable.

For more information about Neighbor Unreachability Detection for IPv4, see Performance Enhancements in the Next Generation TCP/IP Stack.

Fail-back Support for Default Gateway Changes

Dead gateway detection in TCP/IP for Windows Server 2003 and Windows XP provides a fail-over function, but not a fail-back function in which a dead gateway is tried again to determine whether it has become available. The Next Generation TCP/IP stack provides fail-back for default gateway changes by periodically attempting to send TCP traffic through the previously detected unavailable gateway. If the TCP traffic sent through the previous gateway is successful, the Next Generation TCP/IP stack switches the default gateway back to the previous default gateway. Support for fail-back to primary default gateways can provide faster throughput by sending traffic through the primary default gateway on the subnet.

Changes in PMTU Black Hole Router Detection

Path maximum transmission unit (PMTU) discovery, defined in RFC 1191, relies on the receipt of Internet Control Message Protocol (ICMP) Destination Unreachable-Fragmentation Needed and Don’t Fragment (DF) Set messages from routers containing the MTU of the next link. However, in some cases, intermediate routers silently discard packets that cannot be fragmented. These types of routers are known as black hole PMTU routers. Additionally, intermediate routers might drop ICMP messages because of configured packet filtering rules. The result is that TCP connections can time out and terminate because intermediate routers silently discard large TCP segments, their retransmissions, and the ICMP error messages for PMTU discovery.

PMTU black hole router detection senses when large TCP segments are being retransmitted and automatically adjusts the PMTU for the connection, rather than relying on the receipt of the ICMP Destination Unreachable-Fragmentation Needed and DF Set messages. With TCP/IP in Windows Server 2003 and Windows XP, PMTU black hole router detection is disabled by default because enabling it often yielded false positive results, lowering the MTU unnecessarily and decreasing performance.

With increasing use of packet filtering rules on routers to drop ICMP traffic, the Next Generation TCP/IP stack enables PMTU black hole router detection by default to prevent TCP connections from terminating and uses an improved method of detecting PMTU black home routers. PMTU black hole router detection is triggered on a TCP connection when it begins retransmitting full-sized segments with the DF flag set. TCP resets the PMTU for the connection to 536 bytes and retransmits its segments with the DF flag cleared. This maintains the TCP connection, although at a possibly lower PMTU size than actually exists for the connection.

This behavior also applies to IPv6 traffic. For IPv6, the PMTU is set to 1220 bytes if a PMTU black hole router is detected.

Network Diagnostics Framework Support

The Network Diagnostics Framework is an extensible architecture that helps users recover from and troubleshoot problems with network connections. For TCP/IP-based communication, the Network Diagnostics Framework prompts the user through a series of options to eliminate possible causes until the root cause of the problem is identified or all possibilities are eliminated. Specific TCP/IP-related issues that the Network Diagnostics Framework can diagnose are the following:

  • Incorrect IP address

  • Default gateway (router) is not available

  • Incorrect default gateway

  • Network Basic Input/Output System (NetBIOS) over TCP/IP (NetBT) name resolution failure

  • Incorrect Domain Name System (DNS) settings

  • Local port is already being used

  • The Dynamic Host Configuration Protocol (DHCP) Client service is not running

  • There is no remote listener

  • The media is disconnected

  • The local port is blocked

  • Low on memory

For more information, see Network Diagnostics Framework in Windows Vista and Network Diagnostics Technologies in Windows Vista.

ESTATS Support

The Next Generation TCP/IP Stack supports the "TCP Extended Statistics MIB" Internet draft (draft-ietf-tsvwg-tcp-mib-extension-15.txt), which defines extended performance statistics for TCP. By analyzing ESTATS on a connection, it is possible to determine whether the performance bottleneck for a connection is the sending application, the receiving application, or the network. ESTATS is disabled by default and can be enabled per connection. With ESTATS, third-party independent software vendors (ISVs) can create powerful diagnostics and network throughput analysis applications. Tcpanalyzer.exe, available in the Windows Vista SDK, is a diagnostic tool based on ESTATS.

New Packet Filtering Model with Windows Filtering Platform

The Windows Filtering Platform (WFP) is a new architecture in the Next Generation TCP/IP Stack that provides APIs so that third-party ISVs can participate in the filtering decisions that take place at several layers in the TCP/IP protocol stack and throughout the operating system. WFP also integrates and provides support for next-generation firewall features such as authenticated communication and dynamic firewall configuration based on applications’ use of the Windows Sockets API (application-based policy). ISVs can create firewalls, anti-virus software, diagnostic software, and other types of applications and services. Windows Firewall and IPsec in Windows Server 2008 and Windows Vista use the WFP API.

For more information, see Windows Filtering Platform.

IPv6 Enhancements

The Next Generation TCP/IP Stack supports the following enhancements to IPv6:

  • Dual IP layer stack

    The Next Generation TCP/IP stack supports a dual IP layer architecture in which the IPv4 and IPv6 implementations share common transport (that includes TCP and UDP) and framing layers. The Next Generation TCP/IP stack has both IPv4 and IPv6 enabled by default. There is no need to install a separate component to obtain IPv6 support.

  • Enabled by default

    In Windows Server 2008 and Windows Vista, IPv6 is installed and enabled by default. You configure IPv6 settings through the properties of the Internet Protocol version 6 (TCP/IPv6) component in the Network Connections folder and through commands in the netsh interface ipv6 context.

    IPv6 in Windows Server 2008 and Windows Vista cannot be uninstalled, but it can disabled. For more information, see Configuring IPv6 with Windows Vista.

  • GUI-based configuration

    Windows Server 2008 and Windows Vista now allows you to manually configure IPv6 settings through a set of dialog boxes in the Network Connections folder, similar to how you can manually configure IPv4 settings.

    For more information, see Configuring IPv6 with Windows Vista.

  • Teredo enhancements

    The Teredo client in Windows Vista is enabled but might be active or inactive, depending on the computer’s configuration.

    The Teredo client in Windows Server 2008 and Windows Vista uses the 2001::/32 prefix as assigned by IANA and uses unused bits in the Flags field of the Teredo address to help prevent address scans of Teredo addresses. For more information, see Teredo Overview.

    Teredo can now be manually enabled for domain member computers and can work if there is one Teredo client behind one or more symmetric network address translators (NATs). A symmetric NAT maps the same internal (private) address and port number to different external (public) addresses and ports, depending on the external destination address (for outbound traffic). This new behavior allows Teredo to work between a larger set of Internet-connected hosts.

    For more information about IPv6 and Teredo, see Using IPv6 and Teredo.

  • Integrated IPsec support

    In Windows Server 2008 and Windows Vista, IPsec support for IPv6 traffic is the same as that for IPv4, including support for Internet Key Exchange (IKE) and data encryption. The Windows Firewall with Advanced Security and IP Security Policies snap-ins now support the configuration of IPsec policies for IPv6 traffic in the same way as IPv4 traffic. For example, when you configure an IP filter as part of an IP filter list in the IP Security Policies snap-in, you can now specify IPv6 addresses and address prefixes when specifying a specific source or destination IP address.

    For more information, see The New Windows Firewall in Windows Vista and Windows Server 2008.

  • MLDv2

    Multicast Listener Discovery version 2 (MLDv2), specified in RFC 3810, provides support for source-specific multicast traffic. MLDv2 is equivalent to Internet Group Management Protocol version 3 (IGMPv3) for IPv4.

  • LLMNR

    Link-Local Multicast Name Resolution (LLMNR) allows IPv6 and IPv4 hosts on a single subnet without a DNS server to resolve each other’s names. This capability is useful for single-subnet home networks and ad hoc wireless networks. For more information, see Link-Local Multicast Name Resolution.

  • Support for ipv6-literal.net Names

    Windows Vista and Windows Server 2008 support the use of IPv6Address.ivp6-literal.net names. An ipv6-literal.net name can be used in services or applications that do not recognize the syntax of normal IPv6 addresses.

    To specify an IPv6 address within the ipv6-literal.net name, convert the colons (:) in the address to dashes (-). For example, for the IPv6 address 2001:db8:28:3:f98a:5b31:67b7:67ef, the corresponding ipv6-literal.net name is 2001-db8-28-3-f98a-5b31-67b7-67ef.ipv6-literal.net. To specify a zone ID (also known as a scope ID), replace the “%” used to separate the IPv6 address from the zone ID with an “s”. For example to specify the destination fe80::218:8bff:fe17:a226%4, the name is fe80--218-8bff-fe17-a226s4.ipv6-literal.net.

    You can use an ipv6-literal.net name in the computer name part of a Universal Naming Convention (UNC) path. For example, to specify the Docs share of the computer with the IPv6 address of 2001:db8:28:3:f98a:5b31:67b7:67ef, use the UNC path \\2001-db8-28-3-f98a-5b31-67b7-67ef.ipv6-literal.net\docs.

  • IPv6 over PPP

    The built-in remote access client and the Routing and Remote Access service now support the IPv6 Control Protocol (IPV6CP), as defined in RFC 2472, to configure IPv6 nodes on a Point-to-Point Protocol (PPP) link. Native IPv6 traffic can now be sent over PPP-based connections. For example, IPV6CP support allows you to connect with an IPv6-based Internet service provider (ISP) through dial-up or PPP over Ethernet (PPPoE)-based connections that might be used for broadband Internet access.

    For more information about IPv6 over PPP, see IPv6 over Point-to-Point Protocol Links.

  • Random Interface IDs for IPv6 Addresses

    To prevent address scans of IPv6 addresses based on the known company IDs of network adapter manufacturers, Windows Server 2008 and Windows Vista by default generate random interface IDs for non-temporary autoconfigured IPv6 addresses, including public and link-local addresses. Windows XP and Windows Server 2003 use Extended Unique Identifier (EUI)-64-based interface IDs for autoconfigured IPv6 addresses.

  • DHCPv6 support

    Windows Server 2008 and Windows Vista include a DHCPv6-capable DHCP client that will perform stateful address autoconfiguration with a DHCPv6 server. Windows Server 2008 includes a DHCPv6-capable DHCP server.

    For more information about DHCPv6, see The DHCPv6 Protocol.

For more information about IPv6 changes in Windows Server 2008 and Windows Vista, see Changes to IPv6 in Windows Vista and Windows Server 2008.

For more information about IPv6 in Windows Server 2008 and Windows Vista, see the Understanding IPv6, Second Edition book from Microsoft Press.

TCP Chimney Offload

Managing TCP connections can involve a significant amount of processing, which includes:

  • Parsing the fields of the TCP header (validating the TCP checksum and processing sequence and acknowledgement numbers, TCP flags, and source and destination ports).

  • Creating and sending acknowledgements for data received.

  • Segmentation for data sent.

  • Copying of data between memory locations for the receive window, the send window, and applications.

  • Managing timers for TCP retransmission behavior.

By offloading this processing to dedicated hardware, a server computer's CPU can be used for other tasks. TCP Chimney Offload in Windows Server 2008 and Windows Vista provides automated, stateful offload of all TCP traffic processing to specialized network adapters that implement a TCP Offload Engine (TOE).

Rather than offloading individual tasks, the TOE-capable network adapter maintains state for the significant attributes of a connection, such as IP address, the TCP ports, and segment sequence numbers. This allows the network adapter to perform all of the processing of the TCP traffic without impacting the server's CPU. The benefit of offloading all TCP processing is most pronounced when TCP Chimney Offload is used for long-lived connections with large packet payloads, such as TCP connections for file backup and multimedia streaming.

By moving these TCP processing tasks to a TOE-enabled network adapter, the server's CPU is freed for other application tasks, such as supporting more user sessions or processing incoming requests faster.

For more information, see Scalable Networking: Network Protocol Offload - Introducing TCP Chimney.

Domain Name System

Windows Server 2008 includes the following changes and enhancements to the Domain Name System (DNS) Server service:

  • Background zone loading DNS servers that host large DNS zones that are stored in Active Directory Domain Services are able to respond to client queries more quickly when they restart because zone data is now loaded in the background.

  • IPv6 support The DNS Server service now fully supports forward and reverse lookups for IPv6 and DNS traffic over IPv6.

  • Support for read-only domain controllers (RODCs) The DNS Server role in Windows Server 2008 provides primary read-only zones on RODCs.

  • Global single names The DNS Server service in Windows Server 2008 provides a new zone type, the GlobalNames zone, which you can use to store single-label names that can be unique across an entire forest. The GlobalNames zone provides single-label name resolution for large enterprise networks that do not deploy WINS and where using DNS name suffixes to provide single-label name resolution is not practical. For more information, see DNS Server GlobalNames Zone Deployment.

For more information about DNS support in Windows Server 2008, see DNS Server in the Windows Server 2008 Technical Library and DNS Enhancements in Windows Server 2008. For more information about DNS support in Windows, see the Microsoft DNS Web page.

Quality of Service

In Windows Server 2003 and Windows XP, quality of service (QoS) functionality is made available to applications through the QoS APIs. Applications that used the QoS APIs could access prioritized delivery functions. In Windows Server 2008 and Windows Vista, there are new facilities to manage network traffic for both enterprise and home networks.

Policy-based QoS for Enterprise Networks

QoS policies in Windows Server 2008 and Windows Vista allow IT staff to either prioritize or manage the sending rate for outgoing network traffic and can be confined to applications (by executable name or by application folder path), source and destination IPv4 or IPv6 addresses, source and destination TCP or UDP ports, and a range of ports. QoS policy settings are part of User Configuration or Computer Configuration Group Policy and are configured with the Group Policy Object Editor and linked to Active Directory containers (domains, sites, and organizational units) with the Group Policy Management Console. QoS policies can be applied to users or computers that are members of a domain, a site, an organizational unit, or filtered within an Active Directory container for a security group.

To manage the use of bandwidth, you can configure a QoS policy with a throttle rate for outbound traffic. Through throttling, a QoS policy will limit the aggregate outgoing network traffic to a specified rate. To specify prioritized delivery, traffic is marked with a configured Differentiated Services Code Point (DSCP) value. The routers in the network infrastructure can place DSCP-marked packets in different queues for differentiated delivery. For Wi-Fi Multimedia (WMM)-enabled wireless networks, DSCP values are mapped to WMM Access Categories. Both DSCP marking and throttling can be used together to manage traffic effectively. Because the throttling and priority marking is taking place at the Network layer, applications do not need to be modified.

Advanced policy-based QoS settings allow you to indirectly control incoming TCP data by specifying the maximum size of the TCP receive window (default size of 16 MB) and to specify whether applications can set DSCP values (allowed by default). Advanced QoS settings are only available for Computer Configuration Group Policy.

For more information about QoS support in Windows Vista and other versions of Windows, see the Quality of Service Web page.

qWave and QoS2 APIs for Home Networks

Because home networks are increasingly being shared by both data and audio/video (A/V) applications, a QoS solution is needed so that time-dependent A/V traffic can be given preferential treatment over data traffic. Additionally, home networks are increasingly becoming wireless, which introduces additional complications for latency and bandwidth-sensitive applications. Windows Vista supports Quality Windows Audio/Video Experience (qWave), a collection of QoS-related software components that address the network challenges introduced by A/V applications and wireless networks. qWave is integrated into the networking stack as part of the QoS subsystem and works with multiple network and data link layer packet priority technologies to support multiple A/V streams (real-time flows requiring QoS) and data streams (best-effort flows, such as e-mail or file transfers) simultaneously over a home network, while providing a high-quality user experience.

The collection of qWave technologies detect and monitor LAN bandwidth, discover the QoS capability of the home network, and provide distributed admission control for fair and consistent usage of network bandwidth. These technologies enable advanced A/V streaming techniques so that applications can dynamically adapt to variable network conditions.

For more information about qWave, see Quality Windows Audio-Video Experience - qWave.

Server Message Block 2.0

Server Message Block (SMB), also known as the Common Internet File System (CIFS), is the file sharing protocol used by default on Windows-based computers. Windows includes an SMB client (the Client for Microsoft Windows component installed through the properties of a network connection) and an SMB server (the File and Printer Sharing for Microsoft Windows component installed through the properties of a network connection). SMB in versions of Windows prior to Windows Server 2008 and Windows Vista, known as SMB 1.0, was originally designed 15 years ago for early Windows-based network operating systems such as Microsoft LAN Manager and Windows for Workgroups and carries with it the limitations of its initial design.

SMB in Windows Server 2008 and Windows Vista also supports SMB 2.0; a new version of SMB that has been redesigned for today’s networking environments and the needs of the next generation of file servers. SMB 2.0 has the following enhancements:

  • Supports sending multiple SMB commands within the same packet. This reduces the number of packets sent between an SMB client and server, a common complaint against SMB 1.0.

  • Supports much larger buffer sizes compared to SMB 1.0.

  • Increases the restrictive constants within the protocol design to allow for scalability. Examples include an increase in the number of concurrent open file handles on the server and the number of file shares that a server can have.

  • Supports durable handles that can withstand short interruptions in network availability.

  • Supports symbolic links.

Computers running Windows Server 2008 or Windows Vista support both SMB 1.0 and SMB 2.0. The version of SMB that is used for file sharing operations is determined during the SMB session negotiation. The following table shows which version of SMB that is used for various combinations of client and server computers.

Client

Server

Version of SMB used

Windows Server 2008 or Windows Vista

Windows Server 2008 or Windows Vista

SMB 2.0

Windows Server 2008 or Windows Vista

Windows XP, Windows Server 2003, or Windows 2000

SMB 1.0

Windows XP, Windows Server 2003, or Windows 2000

Windows Server 2008 or Windows Vista

SMB 1.0

Windows XP, Windows Server 2003, or Windows 2000

Windows XP, Windows Server 2003, or Windows 2000

SMB 1.0

Http.sys Enhancements

Http.sys, the kernel mode driver that services Hypertext Transfer Protocol (HTTP) traffic, has been enhanced in Windows Server 2008 and Windows Vista with the following:

  • HTTP Server API 2.0

  • Server-side authentication

  • Logging

  • ETW tracing for HTTP events

  • Netsh commands

  • Performance counters

HTTP Server API 2.0

HTTP Server API is a kernel-mode HTTP protocol driver with user-mode APIs available through Httpapi.dll. The HTTP Server APIs enables a server application to register HTTP URLs, receive requests, and service responses. HTTP Server APIs include:

  • Simple-to-use HTTP listener functionality on Windows for native Windows applications.

  • Applications can use the HTTP Server API to co-exist and share TCP ports with HTTP Server API applications, such as Internet Information Services (IIS) 6.0. This allows popular Web traffic TCP ports such as 80 and 443 to be used by multiple server applications simultaneously as long as they are serving different parts of the URL namespace.

  • A native HTTP stack for computers running on a Windows operating system that is HTTP/1.1 compliant.

  • New APIs for configuring the HTTP server: Authentication, Bandwidth Throttling, Logging, Connection Limits, Server State, 503 Responses, Request Queues, Response Caching, and SSL Certificate Binding. For more information, see Using the HTTP Server Version 2.0 API.

Server-side Authentication

Http.sys now provides server-side authentication through the HTTP Server 2.0 APIs for the following schemes: Negotiate (Kerberos | NTLM), NTLM, Basic, and Digest. Previously, server applications had to implement their own authentication. Advantages to Http.sys providing the server-side authentication include the following:

  • Server applications can run under lower privileged accounts.

  • Server applications that support Kerberos authentication can now run under a different account than the default account associated with the Service Principle Name (SPN) of the local machine. A service using Http.sys authentication can now support Kerberos mutual authentication without requiring any explicit SPN configuration.

  • Seamless NTLM authentication handshakes do not cause a restart of the handshake process.

Logging

Http.sys now provides logging through the HTTP Server 2.0 APIs, supporting the following formats: W3C, centralized W3C, NCSA, IIS, and centralized binary log format. Within the centralized log file, site ID fields identify the site to which the log entries belong.

IDNA Support

Http.sys now supports Internationalized Domain Names (IDN) for hostnames. Clients can request sites with IDN hostnames. Http.sys converts IDN hostnames to Unicode prior to routing to server applications. For all encoding formats used by clients in hostnames, Http.sys performs checks and normalization of hostnames according to the IDN in Applications (IDNA) standard (RFC 3490).

ETW Tracing for HTTP Events

Event Tracing for Windows (ETW) is a capability of Windows to obtain information about components and events, typically written to log files. ETW log files make it much easier to troubleshoot problems. Tracing can also diagnose end-to-end issues, in which an Activity ID indicates the flow across operations. Http.sys supports tracing for the following categories:

  • HTTP requests and responses

  • SSL and authentication transactions

  • Logging events

  • Connections and connection timers

  • Cache

  • Service or application setup; setting or deleting properties

  • Activity ID based, including across other ETW-enabled components

For each tracing category, Http.sys supports four levels of information: Error, Warning, Informational, and Verbose. Http.sys tracing can be used as an advanced troubleshooting tool to obtain information about Http.sys processes and behavior.

To start an ETW trace session for Http.sys, do the following:

  1. Create a folder to store the trace files. From this folder, create a file named Httptrace.txt with the following contents:

    "Microsoft-Windows-HttpService" 0xFFFF

  2. Use the following command to start tracing:

    logman start "http trace" -pf httptrace.txt -o httptrace.etl -ets

  3. Perform the steps or tests that need to be traced.

To stop the ETW trace session for Http.sys, use the following command:

logman stop "http trace" -ets

An Httptrace.etl trace file should now appear in the folder. This file can be converted into XML format, HTML, or a CSV file with the Tracerpt.exe tool. For example, to convert the contents of the Httptrace.etl file into a CSV file, use the following command:

tracerpt httptrace.etl -y -o httptrace.csv

The CSV files can then be viewed in a text editor or spreadsheet application.

Netsh commands for Http.sys

You can now manage configuration settings and control diagnostics for Http.sys through a set of commands in the netsh http context. Netsh is a command-line tool that is used by many other Windows networking services, such as IPsec and Routing and Remote Access. The commands in the netsh http context replace the sample tool Httpconfig.exe. With this new support, you can do the following at a Windows command prompt:

  • Configure SSL certificate bindings, URL reservations, IP listen lists, or global timeouts

  • Delete or flush the HTTP cache or logging buffers

  • Display the Http.sys service or cache state

Performance Counters for Http.sys

Http.sys now has the following performance metric counters to help you with monitoring, diagnosing, and capacity planning for Web servers:

  • HTTP Service Counters

    • Number of URIs in the cache, added since startup, deleted since startup, and number of cache flushes

    • Cache hits/second and Cache misses/second

  • HTTP Service URL Groups

    • Data send rate, data receive rate, bytes transferred (sent and received)

    • Maximum number of connections, connection attempts rate, rate for GET and HEAD requests, and total number of requests

  • HTTP Service Request Queues

    • Number of requests in queue, age of oldest requests in queue

    • Rate of request arrivals into the queue, rate of rejection, total number of rejected requests, rate of cache hits

With these new performance counters, metrics can be viewed in through the Diagnostic Console snap-in or obtained through the Performance Counters API.

WinINet Enhancements

Enhancements to the WinINet API in Windows Server 2008 and Windows Vista include the following:

  • Support for IPv6 literals and scope IDs

  • Support for HTTP decompression

  • Support for Internationalized Domain Names

  • Support for ETW tracing

  • IPv6 support in Web Proxy Auto-Discovery scripts

Support for IPv6 Literals and Scope IDs

WinINet now supports RFC 3986 and the use of IPv6 literal addresses in URLs. For example, to connect to the Web server at the IPv6 address 2001:db8:100:2a5f::1, a user with a WinINet-based Web browser (such as Internet Explorer) can type http://[2001:db8:100:2a5f::1] as the address. Although typical users might not use IPv6 literal addresses, the ability to specify the IPv6 address in the URL is valuable to application developers, software testers, and network troubleshooters. WinINet also supports the encoding of the IPv6 scope ID (also known as a zone ID) as part of the address to allow users to specify the scope for the IPv6 destination. For more information, see IP Version 6 Support.

Support for HTTP Decompression

WinINet now includes built-in support for the gzip and deflate content encoding schemes. Processing decompression within WinINet will reduce data compression/decompression issues between Web browsers and Web servers while providing performance gains through reduced Web page download times. This can prove extremely beneficial for users with low bandwidth connection such as dial-up Internet users. For more information, see Content Encoding.

Support for Internationalized Domain Names

WinINet now conforms to the Internationalized Domain Names (IDN) standard (RFC 3490) for hostnames when you use the Unicode versions of the WinINet API. This new support ensures that applications work correctly with domain names containing non-ASCII characters without requiring IDN support within the Web application, installation of a third-party plug-in, or intermediate nodes in a network communication path. For more information, see IDN Support in WinINet.

Support for ETW Tracing

WinINet now supports ETW tracing that allows IT helpdesk and support specialists to obtain detailed information about WinINet processes and events to help determine the source of protocol or application problems. By including identifiers for all of the WinINet events, you can construct a chain of ETW traces that span the entire networking stack, using the identifiers to associate traces from adjacent networking layers. For more information about ETW Tracing, see Event Tracing.

IPv6 support in Web Proxy Auto-Discovery scripts

Web Proxy Auto-Discovery (WPAD) script helper functions exposed by WinINet have been updated to include support for IPv6 addresses and subnet prefixes. WPAD scripts that use the dnsResolve, myIpAddress, isInNet, and isResolvable Proxy Helper APIs can now obtain IPv6 information from WinINet. For more information about WPAD, see WinHTTP AutoProxy Support.

WinHTTP Enhancements

Updates to the WinHTTP 5.1 API in Windows Server 2008 and Windows Vista include the following:

  • Support for data uploads larger than 4 gigabytes

  • Support for chunked transfer encoding

  • Support for issuer list retrieval for Secure Sockets Layer (SSL)-based client authentication

  • Support for optional client certificate requests

  • Support for 4-tuple connection information indication

  • New error codes for SSL client authentication

  • IPv6 support in WPAD scripts

Support for Data Uploads Larger than 4 Gigabytes

WinHTTP now allows applications to add a “Content-Length” header to specify a data length up to 264 bytes.

Support for Chunked Transfer Encoding

WinHTTP now allows applications to perform “chunked” transfer encoding for their data and send them using the WinHttpWriteData API. WinHTTP will detect the presence of a “Transfer-Encoding” header and make internal adjustments to ensure that the transfer is compliant to the HTTP 1.1 specification.

Support for Issuer List Retrieval for Secure Sockets Layer-based Client Authentication

WinHTTP now allows the application to retrieve the issuer list that is associated with a client authentication challenge. An issuer list specifies a list of certification authorities (CAs) that are authorized by the server to issue client certificates. With this new support, a WinHTTP application can determine the correct client certificate to use for client authentication.

Support for Optional Client Certificate Requests

Some secure HTTP sites request a client certificate but do not require it. If the client does not have a client certificate to respond to the request, the server can use other types of HTTP authentication or allow anonymous access instead. To support interoperation with such server configurations, WinHTTP now allows an application to supply a NULL client certificate to indicate to the server that it does not have a client certificate for Secure Sockets Layer (SSL) authentication.

Support for 4-tuple Connection Information Indication

Upon completion of a WinHttpReceiveResponse API, WinHTTP now allows an application to query the source IP/port and destination IP/port associated with the HTTP request that results in the response.

New Error Codes for SSL Client Authentication

WinHTTP now includes error codes for the following common errors in SSL client authentication:

  • The client certificate does not have an associated private key, which is typically caused by importing a client certificate without the private key.

  • The application thread that calls WinHttpSendRequest or WinHttpReceiveResponse does not have the privilege to access the private key associated with the supplied client certificate. Verify that the access control list (ACL) for the private key allows the application to access it.

IPv6 Support in WPAD Scripts

WPAD script helper functions exposed by WinHTTP have been updated to include support for IPv6 addresses and subnet prefixes. WPAD scripts that use the dnsResolve, myIpAddress, isInNet, and isResolvable Proxy Helper APIs can now obtain IPv6 information from WinHTTP. For more information about WPAD, see WinHTTP AutoProxy Support.

For information about enhancements to WinHTTP in Windows Server 2008 and Windows Vista, see What's New in Windows Server 2008 and Windows Vista and SSL in WinHTTP.

Windows Sockets Enhancements

Windows Sockets (Winsock) support has been updated with the following:

  • New Winsock APIs

  • ETW Tracing for Winsock events

  • Layered Service Provider enhancements

  • Winsock Network Diagnostics Framework module

  • New kernel mode Sockets API

New Winsock APIs

Windows Server 2008 and Windows Vista include the following new Winsock APIs:

  • WSAConnectByName Creates a connection to the specified destination, given the destination host’s name. WSAConnectByName takes all the destination addresses returned by name resolution, all the local addresses, and attempts connections by using address pairs with the highest chance of success. An optimal pairing algorithm provided by the transport determines the order of the address pairs. WSAConnectByName ensures a connection will be established (if possible), in the minimal amount of time.

  • WSAConnectByList Creates a connection to the specified destination, given a list of destination IP addresses. WSAConnectByList takes a list of M addresses and the local computer’s N addresses, and tries connecting using up to M x N address combinations before failing to connect.

  • WSASendMsg Sends data and optional control information from connected and unconnected sockets. The WSASendMsg function can be used in place of the WSASend and WSASendTo functions.

  • WSAPoll Determines status of one or more sockets.

For more information on these new APIs, search MSDN for the API name.

ETW Tracing for Winsock Events

The following are some of the Winsock events that can be traced with ETW tracing:

  • Socket creation

  • Bind

  • Connect

  • Accept

  • Send

  • Recv

  • Abort indications

You can enable ETW tracing for Winsock events using the following:

  • Event Viewer snap-in

  • Logman.exe and Tracerpt.exe tools

To enable ETW Tracing for Winsock events using the Event Viewer snap-in, do the following:

  1. Run the Event Viewer tool in the Administrative Tools folder.

  2. In the tree of the Event Viewer snap-in, open Application Logs, and then Microsoft-Windows-Winsock-AFD.

  3. Click the Winsock/AFD item.

  4. In the Action pane, click Log Properties.

  5. In the Log Properties dialog box, click Enable Logging, and then click OK.

To view the events, in the Action pane, click Refresh. To disable logging, clear the Enable Logging check box on the Log Properties dialog box for the Winsock/AFD item.

You might have to increase the log size depending on how many events you want to view.

To enable ETW Tracing for Winsock events using the Logman.exe tool, use the following commands:

logman create trace afdlog –o LogFileLocation
logman update afdlog –p “Microsoft-Windows-Winsock-AFD”
logman start afdlog

A binary log file will be written to LogFileLocation. To convert the binary file written by the Logman.exe tool into readable text, use the Tracerpt.exe tool. For example, use the following command:

tracerpt.exe c:\afdlog.etl –o afdlog.txt

To stop logging, use the following command:

logman stop afdlog
Layered Service Provider Enhancements

Winsock Layered Service Provider (LSP) support in Windows Server 2008 and Windows Vista has been enhanced with the following:

  • The installation and removal of LSPs are logged in the system event log to help determine which applications are installing LSPs and to troubleshoot failed LSP installations. To view the events logged in a console window, use the netsh winsock audit trail command.

  • There is a new installation API (WSCInstallProviderAndChains) that software vendors can use to install an LSP into the Winsock catalog. Manually installing an LSP can be done using a series of Winsock functions, but if done improperly can leave the Winsock LSP catalog in an inconsistent state. Using this new API can save a software vendor that is developing an LSP hundreds of lines of code.

  • There are new facilities to categorize LSPs and to remove most LSPs from the processing path for system critical services. These new facilities provide more stability to Windows, protecting system critical services from improperly designed LSPs.

  • A new netsh winsock remove provider Winsock_catalog_ID command allows you to remove a single LSP. Use this command instead of the netsh winsock reset command, which resets the Winsock catalog to a clean state.

  • There is a Winsock-specific diagnostics module for the Network Diagnostics Framework that will allow users to selectively repair the Winsock catalog by removing only those LSPs that are causing problems.

    For more information about the Network Diagnostics Framework, see Network Diagnostics Framework in Windows Vista and Network Diagnostics Technologies in Windows Vista.

New Kernel Mode Sockets API

The networking architecture of Windows Server 2008 and Windows Vista include a new interface called Winsock Kernel (WSK) . WSK is a new transport-independent kernel mode Network Programming Interface (NPI) for TDI clients. Using WSK, kernel-mode software modules can perform network communication using socket-like programming semantics similar to those supported in the user-mode Windows Sockets 2 API. While TDI is supported in Windows Vista for backward compatibility, TDI clients should be updated to use WSK to achieve the best performance.

For background information, see Intro to WinSock Kernel (WSK) and Network Programming with Winsock Kernel (WSK). For WSK API information, see Winsock Kernel.

NDIS 6.0

Windows Server 2008 and Windows Vista with no service packs installed include Network Driver Interface Specification (NDIS) 6.0. NDIS specifies a standard interface between kernel-mode network drivers and the operating system. NDIS also specifies a standard interface between layered network drivers, abstracting lower-level drivers that manage hardware from upper-level drivers, such as network transports. For more information about NDIS, see NDIS - Network Driver Interface Specification.

NDIS 6.0 includes the following features:

  • New offload support

  • Support for lightweight filter drivers

  • Receive-side scaling

New Offload Support

NDIS 6.0 includes the following new support for offloading network traffic processing functions to network adapters:

  • Offload of IPv6 traffic NDIS 5.1 in Windows Server 2003 and Windows XP already supports the offload of IPv4 traffic processing. NDIS 6.0 now supports the offload of IPv6 traffic processing.

  • Checksum offload supports IPv6 Offloading of checksum calculations for IPv6 traffic is now supported.

  • Large Send Offload version 2 NDIS 5.1 already supports Large Segment Offload (LSO), which offloads the segmentation of TCP data for data blocks up to 64 Kilobytes (KB) in size. Large Send Offload version 2 (LSOv2) in NDIS 6.0 can offload the segmentation of TCP data for data blocks larger than 64 Kilobytes (KB) in size.

Support for Lightweight Filter Drivers

In NDIS 6.0, intermediate filter drivers have been replaced with Lightweight Filter (LWF) drivers that are a combination of an NDIS intermediate driver and a miniport driver. LWF drivers but have the following advantages:

  • There is no longer a need to write a separate protocol and miniport. All of these functions are contained within a single driver.

  • Improved performance.

  • A bypass mode allows the LWF driver to examine only selected control and data paths.

An example of an intermediate filter driver that has been converted to a LWF driver is Pacer.sys, formerly known Psched.sys. It has the same functionality, but takes advantage of performance improvements available with NDIS 6.0. For more information, including samples, see the Windows Driver Kit.

Receive-Side Scaling

In the architecture for multiprocessor computers running Windows Server 2003 or Windows XP, a network adapter is associated with a single processor. The single processor must handle all the traffic received by the network adapter, regardless of whether there are other processors available. The result of this architecture for high-volume servers such as Internet-facing Web servers or enterprise file servers is that the amount of incoming traffic and number of connections that can be serviced by the processor associated with the network adapter is limited. If the processor associated with the network adapter cannot handle the incoming traffic fast enough, the network adapter discards the traffic, resulting in retransmissions and reduced performance.

In Windows Server 2008 and Windows Vista, a network adapter is not associated with a single processor. Instead, the processing for incoming traffic is distributed among the processors on the computer. This new feature, known as Receive-side Scaling, allows for much more traffic to be received by a network adapter on a high-volume server. A multiprocessor computer can now handle more incoming traffic without having to add servers, resulting in lower costs. To take advantage of this new feature, you must install Receive-side Scaling compatible network adapters that can take advantage of the new architecture in Windows Server 2008 and Windows Vista. Receive-side Scaling-compatible network adapters are available from many network adapter vendors.

For more information, see Scalable Networking with RSS.

NDIS 6.1

Windows Server 2008 and Windows Vista with SP1 support NDIS 6.1, which includes the following features:

  • Header-data split services

  • Direct OID Request Interface

  • IPsec Task Offload Version 2

  • NETDMA Updates

For more information, see Introduction to NDIS 6.1.

Header-data Split Services

Header-data split services improve network performance by splitting the header and data in received Ethernet frames into separate buffers. By separating the headers and the data, these services enable the headers to be collected together into smaller regions of memory. More headers fit into a single memory page and more headers fit into the system caches. Therefore, the overhead for memory accesses in the driver stack is reduced. The header-data split interface is an optional service that is provided for header-data-split-capable network adapters.

Direct OID Request Interface

NDIS 6.1 provides a direct OID request interface for NDIS 6.1 and later drivers. The direct OID request path supports OID requests that are queried or set frequently. The direct OID request interface is optional for NDIS drivers. To support the direct OID path, drivers provide entry points and NDIS provides NdisXxx functions for protocol, filter, and miniport drivers.

For NDIS 6.1, the only interface that uses the direct OID request interface is IPsec offload version 2 (IPsecOV2).

IPsec Task Offload Version 2

IPsec task offload provides offloading services for IPsec network data processing to IPsec offload-capable network adapters. NDIS 6.1 supports IPsecOV2. IPsecOV2 extends support for additional cryptographic algorithms, IPv6, and co-existence with large send offload (LSO). IPsecOV2 uses the NDIS 6.1 direct OID request interface.

NETDMA Updates

NETDMA provides services for offloading the memory copy operation performed by the networking subsystem, when receiving network packets, to a dedicated DMA engine. Windows Server 2008 and Windows Vista with SP1 support NETDMA versions 1.1 and 2.0. NETDMA version 2.0 introduces support for a more efficient DMA setup and Plug and Play. In addition, on Windows Server 2008 and Windows Vista SP1, NETDMA versions 1.1 and 2.0 will be used in more scenarios and configurations.

Network Awareness

Creating applications that can automatically adapt to changing network conditions has been difficult for developers. The Network Awareness APIs in Windows Vista allow applications to do the following:

  • Register with Windows Vista to be informed when there are changes to the network to which the computer is connected.

    For example, a user places a laptop into standby mode at work and then opens it at a wireless hotspot. After being alerted of network changes by Windows Vista, applications can automatically configure themselves or behave differently to provide a more seamless user experience.

  • Query Windows Vista for characteristics of the currently connected network to determine the application settings and behavior. Characteristics include the following:

    • Connectivity A network may be disconnected, it may provide access to only the local network, or it may provide access to the local network and the Internet.

    • Connections The computer may be connected to a network by one or more connections (such as network adapters). Network Awareness APIs enable applications to determine the connections that Windows Vista is currently using to connect to a network.

    • Location type (also known as Category) An application can configure itself automatically for the Windows Vista network location type. For more information, see Network Location Types in Windows Vista.

Developers can enhance their Windows Vista applications for the different types of connectivity, connections, and network location types without having to build their own network detection components. The Network Awareness APIs allow developers to focus on features that make network connectivity transparent to the user, rather than the details of lower-level network determination.

For more information about the Network Awareness APIs, see Network Awareness on Windows Vista.

Windows Peer-to-Peer Networking Enhancements

Windows Peer-to-Peer Networking, originally introduced with the Advanced Networking Pack for Windows XP, is an operating system platform component and API in Windows Vista that allows the development of peer-to-peer (P2P) applications. Windows Vista includes the following enhancements to Windows Peer-to-Peer Networking:

  • New, easy to use API APIs to access Windows Peer-to-Peer Networking capabilities such as name resolution, group creation, and security have been highly simplified in Windows Vista, making it easier to create P2P applications for Windows.

  • New version of PNRP Windows Vista includes version 2 of the Peer Name Resolution Protocol (PNRP) that is more scalable and uses less network bandwidth. For PNRP v2 in Windows Vista, Windows Peer-to-Peer Networking applications can access PNRP name publication and resolution functions through a simplified PNRP API. For highly simplified PNRP name resolution in Windows Vista, PNRP names are now integrated into the Getaddrinfo Windows Sockets function. To use PNRP to resolve a name to an IPv6 address, applications can use the Getaddrinfo function to resolve the Fully Qualified Domain Name (FQDN) name.prnp.net, in which name is peer name being resolved. The pnrp.net domain is a reserved domain in Windows Vista for PNRP name resolution. The PNRP v2 protocol is incompatible with PNRP version 1 that was provided with the Advanced Networking Pack for Windows XP. Microsoft has released a PNRP v2 upgrade for Windows XP, which is available through Windows Update or from the Microsoft Download Center. For more information about PNRP, see Peer Name Resolution Protocol.

  • People Near Me A new capability of Windows Peer-to-Peer Networking for Windows Vista that allows users to dynamically discover other users on the local subnet. For more information, see People Near Me.

  • Contact management and serverless presence Peer-to-Peer Networking integrates with the Windows Address Book to provide functions for long term contact management. Users can add trusted contacts to the Windows Address Book by exchanging “Me” contact files with each other. The “Me” contact file is automatically created when a user starts the collaboration infrastructure for the first time. It contains information that identifies a user, and can be used by others to protect against spoofing and to track a user’s presence through the Internet.

  • Application invite This new capability allows applications to invite other users into collaborative activities. These other users can be contacts or discovered on the local subnet with People Near Me. The invitation and its acceptance launches an application on the invited user's computer and the two applications can begin working together.

  • Windows Meeting Space Windows Vista includes Windows Meeting Space, a new P2P-based application that allows users to easily set up meetings, share files, pass notes, and project applications to the group. Windows Meeting Space uses Windows Peer-to-Peer Networking functionality.

  • Netsh configuration support You can now configure Windows Peer-to-Peer Networking settings from commands in the netsh p2p context.

  • Group Policy configuration support You can now configure Windows Peer-to-Peer Networking settings with Group Policy from the Computer Configuration\Administrative Templates\Network\Microsoft Peer-to-Peer Networking Services node.

Windows Firewall

The new Windows Firewall in Windows Server 2008 and Windows Vista has the following enhancements over the current Windows Firewall in Windows XP with Service Pack 2 and later and Windows Server 2003 with Service Pack 1 and later:

  • Supports filtering of both incoming and outgoing traffic

    A network administrator can configure the new Windows Firewall with a set of rules (known as exceptions for Windows Firewall in Windows XP with Service Pack 2 and later and Windows Server 2003 with Service Pack 1 and later) to block all traffic sent to specific ports, such as the well-known ports used by virus software, or to specific addresses containing either sensitive or undesirable content.

  • New Windows Firewall with Advanced Security Microsoft Management Console (MMC) snap-in for graphical user interface (GUI) configuration

    The new Windows Firewall with Advanced Security snap-in, available from the Administrative Tools folder, provides wizards for configuring firewall rules for inbound and outbound traffic and connection security rules. For command-line configuration of advanced settings of the new Windows Firewall, you can use commands in the netsh advfirewall context.

  • Firewall filtering and Internet Protocol security (IPsec) protection settings are integrated

    When using the Windows Firewall with Advanced Security snap-in, you can configure both firewall filtering and traffic protection rules.

  • Advanced configuration for rules (exceptions)

    Configuration options for firewall filtering rules include three different profiles (domain, public, and private), source and destination IP addresses, IP protocol number, source and destination Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports, all or multiple TCP or UDP ports, specific types of interfaces, ICMP and ICMP for IPv6 (ICMPv6) traffic by Type and Code, services, the protection state (protected with IPsec), edge traversal, and specified users and computers based on Active Directory accounts.

Unlike the Windows Firewall in Windows Server 2003 with Service Pack 1 and Windows Server 2003 with Service Pack 2, the new Windows Firewall in Windows Server 2008 is enabled by default.

For more information about these improvements, see The New Windows Firewall in Windows Vista and Windows Server 2008. For additional information, see Introduction to Windows Firewall with Advanced Security.

IPsec Improvements

Windows Server 2008 and Windows Vista include the following improvements to Internet Protocol security (IPsec):

  • Integrated firewall and IPsec configuration

  • Simplified IPsec policy configuration

  • Client-to-DC IPsec protection

  • Improved load balancing and clustering server support

  • Improved IPsec authentication

  • New cryptographic support

  • Integration with Network Access Protection

  • Additional configuration options for protected communication

  • Integrated IPv4 and IPv6 support

  • Extended events and performance monitor counters

  • Network Diagnostics Framework support

Integrated Firewall and IPsec Configuration

In Windows Server 2003 and Windows XP, Windows Firewall and IPsec were components and services that had to be configured separately. Although the purpose of Windows Firewall was to block or allow incoming traffic, IPsec could also be configured to block or allow incoming traffic. Because block and allow traffic behavior for incoming traffic could be configured through two different and separate services, it was possible to have duplicated or contradictory settings. Additionally, Windows Firewall and IPsec supported different configuration options for specifying allowed incoming traffic. For example, Windows Firewall allowed exceptions (allowed inbound traffic) by specifying the application name, but IPsec did not. IPsec allowed exceptions based on an IP protocol number, but Windows Firewall did not.

In Windows Server 2008 and Windows Vista, Windows Firewall and IPsec configuration have been combined into a single tool with the new Windows Firewall with Advanced Security snap-in, which now controls both traditional firewall responsibilities (blocking and allowing both inbound and outbound traffic) and protecting traffic with IPsec. Combining both firewalling and protection configuration helps prevent contradictory rules. Additionally, commands within the netsh advfirewall context can be used for command line configuration of both firewall and IPsec behavior. The integration of Windows Firewall with IPsec provides computers running Windows Server 2008 or Windows Vista with an authenticating firewall.

Simplified IPsec Policy Configuration

In Windows Server 2003 and Windows XP, IPsec policy configuration in many scenarios such as Server and Domain Isolation consists of a set of rules to protect most of the traffic on the network and another set of rules for protected traffic exemptions. Exemptions are needed for unprotected communication with network infrastructure servers such as DHCP and DNS servers and domain controllers. When a computer is starting, it must be able to obtain an IP address, use DNS to find a domain controller, and then log in to its domain before it can begin to use Kerberos authentication to authenticate itself as an IPsec peer. Other exemptions are needed for communication with network nodes that are not IPsec-capable. In some cases, there are dozens or hundreds of exceptions, which makes it more difficult to deploy IPsec protection on an enterprise network and to maintain it over time.

IPsec in Windows Server 2008 and Windows Vista provides an optional behavior when negotiating IPsec protection. If enabled, when initiating communication with another network node, an IPsec node running Windows Server 2008 or Windows Vista will attempt to communicate in the clear and negotiate protected communication in parallel. If the initiating IPsec peer does not receive a response to the initial negotiation attempt, the communication continues in the clear. If the initiating IPsec peer receives a response to the initial negotiation attempt, the communication in the clear continues until the negotiation can complete, at which point subsequent communications are protected.

With this optional behavior and the recommended configuration to require protection for incoming initiated communications and request protection for outgoing initiated communications, the initiating node discovers whether the node it is communicating with is capable of IPsec and behaves accordingly. This new behavior greatly simplifies IPsec policy configuration. For example, the initiating node does not need a set of predefined IPsec filters for exemptions for the set of hosts that either should not or cannot protect network traffic with IPsec. The initiating node tries both protected and unprotected traffic in parallel and if protected communication is not possible, the initiating node uses unprotected communication.

This new negotiation behavior also improves the performance of unprotected connections to hosts. An IPsec node running Windows Server 2003 or Windows XP that is configured to request protected communications but allow unprotected communications—a behavior known as fallback to clear—sends the negotiation messages and then waits for a response. The initiating node waits up to 3 seconds before falling back to clear and attempting unprotected communications. With Windows Server 2008 and Windows Vista, there is no longer a 3-second delay when falling back to clear because communications in the clear is already in progress while the initiating node is waiting for a response.

Note

The IPsec Simple Policy Update for Windows Server 2003 and Windows XP includes new negotiation behavior to simplify IPsec policy. Windows Server 2003 Service Pack 2 and Windows XP Service Pack 3 include the Simple Policy Update. For more information, see Simplifying IPsec Policy with the Simple Policy Update.

Client-to-DC IPsec Protection

For Windows Server 2003 and Windows XP, Microsoft does not support IPsec to protect traffic between domain controllers and member computers (however, Microsoft does support protecting traffic between domain controllers). This is because the IPsec policy configuration can become very complex due to the different types of traffic sent between domain members and domain controllers. Additionally, there is a domain join issue. If the domain controller requires IPsec-protected traffic from computers that must provide domain-based credentials for authentication, a computer that is not a member of the domain cannot contact a domain controller to join the domain. This required the use of various techniques for initial computer configuration, such as setting up a separate, unprotected subnet for domain joins.

Windows Server 2008 and Windows Vista supports securing traffic between domain members and domain controllers in the following deployment modes:

  • You can configure IPsec policy in the domain to request protected traffic but not require it.

    Domain controllers will protect most traffic with domain members but allow clear text for domain joins and other types of traffic.

  • You can configure IPsec policy to require protected traffic for domain controllers.

    Domain controllers are configured with IPsec settings that allow the use of Windows NT/LAN Manager version 2 (NTLM v2) user credentials for authentication. When a computer running Windows Server 2008 or Windows Vista attempts to join the domain, the user is prompted for the user name and password of a domain user account. IPsec protection with the domain controller is negotiated with Windows NT/LAN Manager version 2 (NTLM v2) user credentials for a protected domain join. This new behavior is only available for domain member computers running either Windows Vista or Windows Server 2008 and for domain controllers running Windows Server 2008.

Because of the new negotiation behavior, you no longer have to configure exemptions for domain controllers, simplifying IPsec policy and deployment of IPsec protection in a domain.

Improved Load Balancing and Clustering Server Support

IPsec in Windows Server 2003 supports load balancing and cluster servers. However, failover times to re-establish IPsec connectivity to a cluster virtual IP address are the following:

  • Typically 3-6 seconds for administrative moves of clustered resources.

  • Up to two minutes when a cluster node suddenly becomes unavailable or another sudden loss of connectivity occurs. The timeout of two minutes includes one minute for the IPsec idle time to expire and one minute to renegotiate security associations (SAs). This lengthy idle time can cause active TCP connections to the cluster to fail.

In Windows Server 2008 and Windows Vista, the timeout for a cluster node failure is substantially reduced. IPsec in Windows Server 2008 and Windows Vista is more tightly integrated into the Next Generation TCP/IP stack. Rather than relying on IPsec idle timeouts to detect a cluster node failure, IPsec in Windows Server 2008 and Windows Vista monitors TCP connections for established SAs. If the TCP connection for an established SA begins retransmitting segments, IPsec will renegotiate the SAs. The result is that the failover to a new cluster node happens quickly, typically in time to keep the application from failing.

Improved IPsec Authentication

IPsec in Windows Server 2003 and Windows XP supports the Internet Key Exchange (IKE) and three authentication methods during main mode negotiations: Kerberos (for Active Directory domain members), digital certificates, and preshared key. For all of these authentication methods, the authentication process is validating the identity and trustworthiness of a computer, rather than the user of the computer. IKE only attempts a single authentication using a single authentication method.

Windows Server 2008 and Windows Vista supports the following improvements in IPsec authentication:

  • Ability to require that IPsec peers authenticate with a health certificate

    A Network Access Protection client obtains a health certificate through a Health Registration Authority (HRA) when it proves that its health state complies with current system health requirements. For more information about the Network Access Protection platform, see "Network Access Protection" in this article.

  • Ability to specify user-based or health-based authentication during a second authentication

    With support for Authenticated IP (AuthIP), IPsec in Windows Server 2008 and Windows Vista allows a second authentication for IPsec-protected communication. With a second authentication, IPsec in Windows Server 2008 and Windows Vista can perform an additional level of authentication, which can be based on the following:

    • Kerberos credentials of the logged in user account

    • NTLM v2 credentials of the computer account

    • NTLM v2 credentials of the logged in user account

    • A user certificate

    • A computer health certificate

    For example, you can use the first authentication and Kerberos credentials to authenticate the computer and then the second authentication and a health certificate to validate the computer's health state. Second authentication can be configured with or without the first authentication.

  • Multiple authentication methods are attempted

    In Windows Server 2003 and Windows XP, you can select multiple authentication methods in a preference order for main mode IPsec authentication. However, only one authentication method is used for authentication. If the authentication process for the negotiated authentication method fails, main mode fails and IPsec protection cannot be performed. When you select multiple authentication methods for computers running Windows Server 2008 or Windows Vista, IPsec will attempt multiple authentication attempts in an effort to perform mutual authentication. For example, if you specify that you want to authenticate using computer certificates with a specific certification authority (CA) and then Kerberos, the IPsec peer will attempt Kerberos authentication if the certificate authentication fails.

For more information about IPsec authentication improvements, see AuthIP in Windows Vista. For more information about AuthIP, see The Authenticated Internet Protocol.

New Cryptographic Support

In response to governmental security requirements and trends in the security industry to support stronger cryptography, Windows Server 2008 and Windows Vista support additional key derivation and encryption algorithms.

Windows Server 2008 and Windows Vista support the following additional algorithms to negotiate the master key material derived during main mode negotiation:

  • Diffie-Hellman (DH) Group 19, which is an elliptic curve algorithm using a 256-bit random curve group (NIST identifier P-256)

  • DH Group 20, which is an elliptic curve algorithm using a 384-bit random curve group (NIST identifier P-384)

These methods are stronger than DH algorithms supported in Windows Server 2003 and Windows XP with Service Pack 2 and later. For more information about these algorithms, see RFC 4753. These new DH algorithms cannot be used for main mode negotiation with a computer running Windows Server 2003, Windows XP, or Windows 2000.

In addition to the Data Encryption Standard (DES) and Triple-DES (3DES), Windows Server 2008 and Windows Vista support the following additional algorithms for encrypting data:

  • Advanced Encryption Standard (AES) with cipher block chaining (CBC) and a 128-bit key size (AES 128)

  • AES with CBC and a 192-bit key size (AES 192)

  • AES with CBC and a 256-bit key size (AES 256)

These new encryption algorithms cannot be used for IPsec SAs with a computer running Windows Server 2003, Windows XP, or Windows 2000.

Windows Server 2008 and Windows Vista SP1 also include support for Suite B, a standard from the National Security Agency (NSA) that defines a common set of cryptographic algorithms for the needs of the US government.

For Suite B support, Windows Server 2008 and Windows Vista SP1 include the following additional integrity algorithms for main mode negotiation:

  • Secure Hash Algorithm (SHA)-256

  • SHA-38

Windows Server 2008 and Windows Vista SP1 include the following integrity algorithms for providing data integrity when using either Authentication Header (AH) or Encapsulating Security Payload (ESP):

  • SHA-256

  • AES-Galois Message Authentication Code (GMAC)-128

  • AES-GMAC-192

  • AES-GMAC-25

Windows Server 2008 and Windows Vista SP1 include the following integrity algorithms for providing data integrity and encryption when using ESP only:

  • AES-Galois/Counter Mode (GCM)-128

  • AES-GCM-192

  • AES-GCM-256

Windows Server 2008 and Windows Vista SP1 also include the following authentication methods:

  • Computer certificate with Elliptic Curve Digital Signature Algorithm (ECDSA)-P256 signing

  • Computer certificate with ECDSA-P384 signing

These new integrity algorithms and authentication methods can be configured using commands in the netsh advfirewall context. They cannot be configured with the Windows Firewall with Advanced Security or IPsec Policies snap-ins.

The additional Suite B integrity algorithms and authentication methods cannot be used for