Networking

Windows Vista and Windows Server 2008 include many new core networking components and enhanced technologies to improve networking performance, security, reliability, and manageability.

Protocols and Core Networking Components

• Next Generation TCP/IP Stack
  The Next Generation TCP/IP stack is a complete redesign of TCP/IP functionality in Windows. One stack supports both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) through a dual-layer IP architecture in which the IPv4 and IPv6 implementations share common transport and framing layers.

  
  
  
  

  • 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.
    

  • Compound TCP
    Developed by Microsoft Research, Compound TCP (CTCP) increases throughput for high-speed and long distance networks by monitoring the bandwidth-delay product, delay variations, and packet loss. 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. CTCP may be enabled or disabled via the netsh commandline utility:
    
    Enable CTCP:
    netsh interface tcp set global congestionprovider=ctcp
    
    Disable CTCP:
    netsh interface tcp set global congestionprovider=none
    

  • ECN Support
    RFC 3168: Explicit Congestion Notification (ECN) aids in detecting congestion before packet losses are incurred and increases the overall throughput between TCP peers. With ECN support on both TCP peers and 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. Because ECN uses previously unused or reserved bits in TCP and IP headers, and some network devices may discard ECN-marked packets, ECN is disabled by default in Windows Vista. ECN may be enabled via netsh to evaluate its effects on your network environment:
    
    Eenable ECN:
    netsh interface tcp set global ecncapability=enabled
    
    Disable ECN:
    netsh interface tcp set global ecncapability=disabled
    

  • Enhancements for 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). For environments that have sudden and temporary increases in the RTT, such as when a wireless client roams from one wireless AP to another, F-RTO prevents unnecessary retransmission of segments and more quickly returns to its normal sending rate.
      

  • 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 nodes suddenly become unavailable. The Next Generation TCP/IP stack provides similar error detection and recovery benefits for IPv4-based communications via support for Neighbor Unreachability Detection over IPv4.
    

  • Fail-back Support for Default Gateway Changes
    Dead gateway detection in TCP/IP for Windows XP and Windows Server 2003 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, potentially providing faster throughput by sending traffic through the primary default gateway on the subnet.
    

  • Changes in PMTU Black Hole Router Detection
    Black hole router detection is disabled by default in previous versions of Windows because enabling it increases the maximum number of retransmissions that are performed for a given segment. However, with increasing use of firewall 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.
    

  • 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 DNS settings

    • Local port is already being used

    • The DHCP Client service is not running

    • There is no remote listener

    • The media is disconnected

    • The local port is blocked

    • Low on memory
      

  • ESTATS Support
    The Next Generation TCP/IP Stack supports the "TCP Extended Statistics MIB" Internet draft (draft-ietf-tsvwg-tcp-mib-extension-08.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.
    

  • 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. The platform 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 Vista and Windows Server 2008 use the WFP API.
    

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

    • Dual IP stack
      

    • Enabled by default
      IPv6 is installed and enabled by default and may be configured through the properties of the Internet Protocol version 6 (TCP/IPv6) component and through commands in the netsh interface ipv6 context.
      

    • GUI-based configuration
      Windows Vista and Windows Server 2008 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. ***[Insert Pic of Config Dialogs]
      

    • Teredo enhancements
      The Teredo (RFC 4380) client is enabled but is inactive by default. In order to become active, a user must either install an application that needs to use Teredo, or choose to change firewall settings to allow an application to use Teredo. The Teredo client 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. Teredo is enabled for domain member computers and can now 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.
      

    • Integrated IPsec support
      In Windows Vista and Windows Server 2008, 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.
      

    • 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 - draft-ietf-dnsext-mdns-47) allows IPv6 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.
      

    • IPv6 over PPP
      The built-in remote access client now supports 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.
      

    • Random Interface IDs for IPv6 Addresses
      To prevent address scans of IPv6 addresses based on the known company IDs of network adapter manufacturers, Windows Vista and Windows Server 2008 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 Vista and Windows Server 2008 include a DHCPv6-capable DHCP client that will perform stateful address autoconfiguration with a DHCPv6 server.
      

• Policy-based Quality of Service
  In Windows XP and Windows Server 2003, quality of service (QoS) functionality is made available to applications through the Generic QoS (GQoS) APIs. Windows Vista and Windows Server 2008 include new facilities to manage network traffic for both enterprise and home networks.
  

• Policy-based QoS for Enterprise Networks
  QoS policies allow the prioritization and management of the sending rate for outgoing network traffic and can be confined to specific applications, specific source and destination IP addresses, and specific source and destination TCP or UDP ports.
  

• qWave for Home Networks
  Windows Vista supports Quality Windows Audio/Video Experience (qWave), a collection of QoS-related software modules that address the network challenges introduced by A/V applications and wireless networks. 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.
  

• 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. SMB 2.0 is 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.
    

• Http.sys Enhancements
  Http.sys, the kernel mode driver that services Hypertext Transfer Protocol (HTTP) traffic, has received the following enhancements:
  

  • 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 enable a server application to register HTTP URLs, receive requests, and service responses. HTTP Server APIs include:
    

    • Simple-to-use HTTP listener functionality on Windows with both native and managed Windows .NET applications.
      

    • Applications can use the HTTP Server API to co-exist and share TCP ports with Internet Information Services (IIS) 6.0. This allows popular Web traffic TCP ports such as 80 and 443 to be used by both HTTP Server API-based and IIS 6.0 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.
      

  • Server-side Authentication
    Http.sys now performs server side authentication. Previously, server applications performed 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 run can under different accounts, since Http.sys now performs the Service Principle Name (SPN) authentication on their behalf.
      

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

  • Logging
    Http.sys now provides centralized World Wide Web Consortium (W3C) logging in which a single log file stores the entries for all the sites of a server application, such as IIS. Within the centralized log file, site ID fields identify the site to which the log entries belong.
    

  • 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. 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
      

  • 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. 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, HTTP metrics can be viewed in the Diagnostic Console snap-in or obtained through the Performance Counters API.

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

  • Support for IPv6 Literals and Scope IDs
    WinINet now supports the use of IPv6 literal addresses in URLs (RFC 2732) and. 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.
    

  • Support for HTTP Decompression
    Prior to Windows Vista and Windows Server 2008, HTTP requests with content encoding were sent to the application for processing at their level. WinINet now includes built-in support for the gzip and deflate content encoding schemes, reducing data compression/decompression issues between Web browsers and Web servers while providing performance gains through reduced Web page download times.
    

  • 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 application.
    

  • Support for ETW Tracing
    Construct traces that span the entire networking stack and obtain detailed information about WinINet processes and events to help determine the source of protocol or application problems.
    

  • 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.
    

• WinHTTP Enhancements
  Updates to the WinHTTP 5.1 API in Windows Vista and Windows Server 2008 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-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
    

• Windows Sockets Enhancements
  

  • 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.
      

  • 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

    ETW tracing for Winsock events can be enabled via the Event Viewer snap-in or using the Logman.exe and Tracerpt.exe tools.
    

• Layered Service Provider Enhancements
  

  • Logging of LSP installation and removal 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.
    

  • New installation API (WSCInstallProviderAndChains) that software vendors can use to install an LSP into the Winsock catalog.
    

  • New facilities to categorize LSPs and to remove most LSPs from the processing path for system critical services, increasing system stability and protecting system critical services from improperly designed LSPs.
    

  • 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.
    

• New Kernel Mode Sockets API
  The networking architecture of Windows Vista and Windows Server 2008 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.

• NDIS 6.0
  Network Driver Interface Specification (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.
  
  NDIS 6.0 includes the following features:
  
  • New Offload Support
    
    • Offload of IPv6 traffic processing.
      Offload of IPv4 traffic processing was supported in NDIS 5.1. NDIS 6.0 adds support for the offload of IPv6 traffic processing.
      
      
    • IPv6 Offloading of checksum calculations.
      
      
    • Large Send Offload version 2
      Large Segment Offload (LSO), supported in NDIS 5.1, 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 have the following advantages:
    
    
    • Reduced complexity
      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.
      
      
  • Receive-Side Scaling
    RSS provides the following benefits:
    
    
    • Parallel Execution.
      Receive packets from a single network adapter can be processed concurrently on multiple CPUs, while preserving in-order delivery.
      
      
    • Dynamic Load Balancing
      As system load on the host varies, RSS will rebalance the network processing load between the processors.
      
      
    • Cache Locality.
      Because packets from a single connection are always mapped to a specific processor, state for a particular connection never has to move from one processor's cache to another processor's cache, thereby eliminating cache thrashing and also promoting improved performance.
      
      
    • Send Side Scaling.
      Transmission Control Protocol (TCP) is often limited as to how much data it can send to the remote peer. The reasons can include the TCP congestion window, the size of the advertised receive window, or TCP slow-start. When an application tries to send a buffer larger than the size of the advertised receive window, TCP sends part of the data and then waits for an acknowledgment before sending the balance of the data. When the TCP acknowledgement arrives, additional data is sent in the context of the deferred procedure call (DPC) in which the acknowledgement is indicated. Thus, scaled receive processing can also result in scaled transmit processing.
      
      
    • Secure Hash.
      The default generated RSS signature is cryptographically secure, making it much more difficult for malicious remote hosts to force the system into an unbalanced state.
      
      
• Network Awareness
  The Network Awareness APIs in Windows Vista simplify the task of creating applications that can automatically adapt to changing network conditions. The Network Awareness APIs 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.
    
    
  • 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.
      
      
• 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 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 and simplified APIs to access Windows Peer-to-Peer Networking capabilities such as name resolution, group creation, and security make it easier to create P2P applications for Windows.
    
    
  • Peer Name Resolution Protocol (PNRP) version 2
    PNRP v2 in Windows Vista provides a simplified API for PNRP name publication and resolution and a protocol that is more scalable and uses less bandwidth than the original PNRP protocol. 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 the PNRP protocol used by computers running Windows XP. An update to the Windows Peer-to-Peer Networking components in Windows XP to support PNRP v2 is currently available from Microsoft.
    
    
  • People Near Me
    New in Windows Vista, People Near Me allows users to dynamically discover other users and their registered People-Near-Me-capable applications on the local subnet, and to easily invite users into a collaboration activity. The invitation and its acceptance launches an application on the invited user's computer and the two applications can begin participating in a collaboration activity such as chatting, photo sharing, or game playing. Windows Meeting Space, a new application included in Windows Vista, uses People Near Me to allow users to easily set up virtual conference rooms and view presentations, share documents, applications, or the desktop. Windows Peer-to-Peer Networking settings may be configured via the netsh p2p context or through Group Policy.
    
    
• Windows Firewall
  The new Windows Firewall in Windows Vista and Windows Server 2008 contains the following enhancements over the firewall included in Windows XP and Windows Server 2003:
  
  
  • 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 Windows Server 2003 with Service Pack 1) 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 provides wizards for graphical configuration of 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 to allow you to configure both firewall filtering and protected traffic 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.
    
    
• IPsec Improvements
  Windows Vista and Windows Server 2008 include the following improvements to Internet Protocol security (IPsec):
  
  
  • Integrated Firewall and IPsec Configuration
    In Windows Vista and Windows Server 2008, 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. 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 Vista or Windows Server 2008 with an authenticating firewall.
    
    
  • Simplified IPsec Policy Configuration
    New optional negotiation behavior reduces the number of rules needed for protected traffic exemptions, and improves the performance of unprotected connections to hosts by negotiating both clear and protected communications in parallel, rather than incurring response delays by using the fallback to clear behavior of Windows XP and Windows Server 2003.
    
    
  • Client-to-DC IPsec Protection
    Windows Vista and Windows Server 2008 supports securing traffic between domain members and domain controllers in the following deployment modes:
    
    
    • 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.
      
      
    • 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. When a computer running Windows Vista or Windows Server 2008 attempts to join the domain, the user is prompted for the user name and password of a domain user account. IPsec 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.
      
      
  • Improved Load Balancing and Clustering Server Support
    In Windows Vista and Windows Server 2008, the timeout for a cluster node failure is substantially reduced. IPsec is more tightly integrated into the Next Generation TCP/IP stack and monitors TCP connections for established security associations (SAs) rather than relying on IPsec idle timeouts to detect a cluster node failure. 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 XP and Windows Server 2003 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 Vista and Windows Server 2008 supports the following improvements in IPsec authentication:
    
    
    • Ability to require that IPsec peers authenticate with a health certificate
      A health certificate server issues a health certificate when a Network Access Protection client proves that its health state complies with current system health requirements.
      
      
    • Ability to specify user-based or health-based authentication during a second authentication
      With support for Authenticated IP (AuthIP), IPsec in Windows Vista and Windows Server 2008 allows a second authentication for IPsec-protected communication. With a second authentication, IPsec in Windows Vista and Windows Server 2008 can perform an additional level of authentication. The credentials used during the second authentication can be based on the following:
      
      
      • Kerberos credentials of the logged in user 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 with or without the first authentication.
        
        
      • Multiple authentication methods are attempted
        In Windows XP and Windows Server 2003, 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 Vista or Windows Server 2008, 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.
        
        
  • New Cryptographic Support
    In response to governmental security requirements and trends in the security industry to support stronger cryptography, Windows Vista and Windows Server 2008 support additional key derivation and encryption algorithms. Windows Vista and Windows Server 2008 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 XP and Windows Server 2003 with Service Pack 2 and 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 Vista and Windows Server 2008 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 a security association with a computer running Windows Server 2003, Windows XP, or Windows 2000.
    

  • Integration with Network Access Protection
    With the new Network Access Protection platform, you can require that IPsec nodes perform a second authentication with a health certificate, verifying that the IPsec node meets current system health requirements. A health certificate server issues a health certificate after an IPsec peer's health status has been evaluated by a Network Policy Server (NPS).
    

  • Additional Configuration Options for Protected Communication
    When you configure a connection security rule with the new Windows Firewall with Advanced Security snap-in, you can specify the following additional settings:
    

    • By application name
      This greatly simplifies protected traffic configuration because the ports used by the application do not need to be manually configured.
      

    • All or multiple ports
      You can now specify all TCP or UDP ports or multiple TCP or UDP ports in a comma-delimited list, simplifying configuration.
      

    • For all addresses in a numeric range
      You can now specify a range of IP addresses using a numeric range, such as 10.1.17.23 to 10.1.17.219.
      

    • For all addresses on the local subnet
      A set of predefined addresses that are dynamically mapped to the set of addresses defined by your IPv4 address and subnet mask or by your IPv6 local subnet prefix.
      

    • For all wireless adapters
      You can protect traffic based on the interface type, which now includes wireless in addition to LAN and remote access.
      

    • By Active Directory user or computer account
      You can specify the list of computer or user accounts or groups that are authorized to initiate protected communication. For example, this allows you to specify that traffic to specific servers with sensitive data must be protected and can only originate from user accounts that are members of specific Active Directory security groups.
      

    • By ICMP or ICMPv6 Type or Code value
      You can specify ICMP or ICMPv6 messages by specifying the ICMP or ICMPv6 message Type and Code field values.
      

    • For services you can specify that the exception applies to any process, only for services, for a specific service by its service name, or you can type the short name for the service.
      

  • Integrated IPv4 and IPv6 Support
    IPsec support for IPv6 traffic in Windows XP and Windows Server 2003 is limited. For example, there is no support for Internet Key Exchange (IKE) or data encryption. IPsec security policies, security associations, and keys must be configured through text files and activated using the Ipsec6.exe command line tool.
    
    In Windows Vista and Windows Server 2008, IPsec support for IPv6 traffic is the same as that for IPv4, including support for IKE and data encryption. Policy settings for both IPv4 and IPv6 traffic are configured in the same way using either the Windows Firewall with Advanced Security or IP Security Policies snap-ins.
    

  • Extended Events and Performance Monitor Counters
    Windows Vista and Windows Server 2008 include new IPsec audit-specific events and the text of existing events has been updated with more useful information. These improvements will help you troubleshoot failed IPsec negotiations without having to enable the advanced Oakley logging capability. IPsec performance counters help identify performance and networking issues with IPsec-protected traffic.
    

  • Network Diagnostics Framework Support
    The Network Diagnostics Framework is an extensible architecture that helps users recover from and troubleshoot problems with network connections. For a failed IPsec negotiation, the Network Diagnostics Framework will prompt a user with an option to identify and correct the problem. IPsec support for the Network Diagnostics Framework then attempts to discover the source of the failed connection and either automatically correct the problem, or, depending on security considerations, prompt the user to make the appropriate configuration change.
    

Wireless and 802.1X-based Wired Connections
Windows Vista and Windows Server 2008 include many enhancements to support IEEE 802.11 wireless networks and networks that use authenticating switches.

• IEEE 802.11 Wireless Changes and Enhancements
  
  • Native Wi-Fi Architecture
    In Windows XP and Windows Server 2003, the software infrastructure that supports wireless connections was built to emulate an Ethernet connection and can only be extended by supporting additional EAP types for IEEE 802.1X authentication. In Windows Vista and Windows Server 2008, the software infrastructure for 802.11 wireless connections, called the Native Wi-Fi Architecture, has been redesigned for the following:
    
    
    • IEEE 802.11 is now represented inside of Windows as a media type separate from IEEE 802.3. This allows independent hardware vendors (IHVs) more flexibility in supporting advanced features of IEEE 802.11 networks, such as a larger frame size than Ethernet.
      
      
    • New components in the Native Wi-Fi Architecture perform authentication, authorization, and management of 802.11 connections, reducing the burden on IHVs to incorporate these functions into their wireless network adapter drivers. IHVs develop a smaller NDIS 6.0 miniport driver that exposes a native 802.11 interface on its top edge.
      
      
    • The Native Wi-Fi Architecture supports APIs to allow ISVs and IHVs the ability to extend the built-in wireless client for additional wireless services and custom capabilities. Extensible components written by ISVs and IHVs can also provide customized configuration dialog boxes and wizards.
      
      
• User Interface Improvements for Wireless Connections
  
  
  • Wireless configuration integrated into new Network and Sharing Center
    Connectivity to wireless networks has been integrated into the new Network and Sharing Center in Windows Vista, rather than from the properties of a wireless network adapter. From the Network and Sharing Center, you can connect to wireless networks, set up a wireless network that uses a wireless access point or an ad hoc wireless network, and manage your wireless networks.
    
    
  • Wireless networks can be configured for all users or per-user
    In the Manage Wireless Networks folder (available from the Network and Sharing Center), you can now specify the wireless network profile type. This allows you to specify that new wireless networks (known as profiles) apply to all users of the computer or can be configured to apply to specific users. Per-user wireless profiles are only connected when the user to which the profile applies logs in to the computer. Per-user profiles are disconnected when the user logs off or switches to another user.
    
    
  • Extensible wireless UI
    Custom wireless configuration dialog boxes or wizards can be written and added to the built-in Windows wireless client, allowing the configuration of custom ISV or IHV wireless features and capabilities.
    
    
  • Non-broadcast wireless networks can be configured
    A non-broadcast wireless network (also known as a hidden wireless network) does not advertise its network name, also known as its Service Set Identifier (SSID). A wireless access point of a non-broadcast wireless network can be configured to send Beacon frames with an SSID set to NULL. This practice is known as using non-broadcast SSIDs. In Windows XP and Windows Server 2003, you could not configure a preferred wireless network as non-broadcast, which sometimes produced confusing behavior when automatically connecting to preferred wireless networks, some of which are non-broadcast and some of which are not. In Windows Vista and Windows Server 2008, you can configure a preferred wireless network as a non-broadcast network.
    
    
  • Non-broadcast wireless networks displayed as "Unnamed Network"
    In the list of available wireless networks in the Connect to a network wizard, non-broadcast networks appear with the name "Unnamed Network". When you connect to the non-broadcast wireless network, you will be prompted to type the non-broadcast wireless network name.
    
    
  • Prompts user when connecting to unsecured wireless network
    Due to the risks associated with communicating on unsecured wireless networks, Windows Vista and Windows Server 2008 will now prompt the user when connecting to an unsecured wireless network and allow them to confirm the connection attempt.
    
    
  • Network connection wizard lists the security methods supported by the wireless network adapter
    The Connect to a network wizard in Windows Vista and Windows Server 2008 retrieves the security capabilities of the wireless network adapter and allows the user to select the strongest security method. For example, if a wireless network adapter supports both Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access (WPA), the Connect to a network wizard will allow the user to select WPA or WEP as the security method.
    
    
• Wireless Group Policy Enhancements
  Wireless Group Policy settings include the following enhancements:
  
  
  • WPA2 authentication options
    Wireless Group Policy settings in allow the configuration of WPA2 authentication options; WPA2 (for WPA2 Enterprise) and WPA2-PSK (for WPA2 Personal).
    
    
  • Lists of allowed and denied wireless network names
    Wireless Group Policy settings allow you to configure lists of allowed and denied wireless network names. With an allow list, you can specify the set of wireless networks by name (SSID) to which the Windows Vista or Windows Server 2008 wireless client is allowed to connect. This is useful for network administrators that want an organization's laptop computer to connect to a specific set of wireless networks, which might include the organization's wireless network and wireless Internet service providers. With a deny list, you can specify the set of wireless networks by name to which the wireless client is not allowed to connect. This is useful to prevent managed laptop computers from connecting to other wireless networks that are within range of the organization's wireless network (such as when an organization occupies a floor of a building and there are other wireless networks of other organization on adjoining floors) or to prevent managed laptop computers from connecting to known unsecured wireless networks.
    
    
  • Additional preferred wireless network settings
    The wireless Group Policy settings in Windows Server 2008 allow configuration of the following for preferred wireless networks:
    
    
    • Fast roaming settings
      Fast roaming is an advanced capability of WPA2 wireless networks that allow wireless clients to more quickly roam from one wireless AP to another by using preauthentication and pairwise master key (PMK) caching. With Windows Server 2008, you can configure this behavior through wireless Group Policy settings. With Windows XP and the Wireless Client Update for Windows XP with Service Pack 2, you can control this behavior with registry settings as described in Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE) Update for Windows XP with Service Pack 2
      
      
    • Non-broadcast wireless networks
      Preferred wireless networks can now be configured as non-broadcast networks via wireless Group Policy settings.
      
      
    • Automatic or manual connection
      Preferred wireless networks can now be configured for automatic or manual connection via wireless Group Policy settings.
      
      
• Changes in Wireless Auto Configuration
  Wireless Auto Configuration is a service that dynamically selects the wireless network to which the computer will automatically connect, based either on your preferences or on default settings. This includes automatically selecting and connecting to a more preferred wireless network when it becomes available. Windows Vista and Windows Server 2008 include the following changes to Wireless Auto Configuration:
  
  
  • Change in behavior when there are no preferred wireless networks available
    In Windows XP and Windows Server 2003, if a preferred wireless network could not be connected and the wireless client is configured to prevent automatic connection to wireless networks that are not in the preferred list (the default), Wireless Auto Configuration creates a random wireless network name and places the wireless network adapter in infrastructure mode. However, the random wireless network does not have a security configuration, making it possible for a malicious user to connect to the wireless client using the random wireless network name.
    
    In Windows Vista and Windows Server 2008, Wireless Auto Configuration configures the wireless network adapter with a random name and security configuration consisting of a 128-bit random encryption key and the strongest encryption method supported by the wireless network adapter. This new behavior helps prevent a malicious user from connecting to the wireless client using the random wireless network name.
    
    
  • New support for non-broadcast wireless networks
    In Windows XP and Windows Server 2003, Wireless Auto Configuration attempts to match configured preferred wireless networks with wireless networks that are broadcasting their network name. If none of the available networks match a preferred wireless network, Wireless Auto Configuration then sends probe requests to determine if the preferred networks in the ordered list are non-broadcast networks. The result of this behavior is that broadcast networks will be connected to before non-broadcast networks, even if a non-broadcast network is higher in the preferred list than a broadcast network. Another result is that a Windows XP or Windows Server 2003 wireless client advertises its list of preferred wireless networks when sending probe requests.
    
    In Windows Vista and Windows Server 2008, you can configure wireless networks as broadcast (the wireless network name is included in the Beacon frames sent by the wireless AP) or non-broadcast (the Beacon frame contains a network name set to NULL). Wireless Auto Configuration now attempts to connect the wireless networks in the preferred network list order, regardless of whether they are broadcast or non-broadcast. Because the wireless networks are now explicitly marked as broadcast or non-broadcast, Windows Vista or Windows Server 2008 wireless clients only send probe requests for non-broadcast wireless networks.
    
    
• WPA2 Support
  Windows Vista and Windows Server 2008 include built-in support to configure WPA2 authentication options with both the standard profile (locally configured preferred wireless networks) and the domain profile with Group Policy settings. WPA2 is a product certification available through the Wi-Fi Alliance that certifies wireless equipment as being compatible with the IEEE 802.11i standard. WPA2 in Windows Vista and Windows Server 2008 supports both Enterprise (IEEE 802.1X authentication) and Personal (preshared key authentication) modes of operation. Windows Vista and Windows Server 2008 also include support for WPA2 for an ad hoc mode wireless network (a wireless network between wireless clients that does not use a wireless access point).
  
  
• Integration with Network Access Protection when using 802.1X Authentication
  WPA2-Enterprise, WPA-Enterprise, and dynamic WEP connections that use 802.1X authentication can leverage the Network Access Protection platform to prevent wireless clients that do not comply with system health requirements from gaining unlimited access to an intranet.
  
  
• EAPHost Infrastructure
  Windows Vista and Windows Server 2008 supports the new EAPHost infrastructure for easier development of Extensible Authentication Protocol (EAP) authentication methods for IEEE 802.1X-authenticated wireless connections.
  
  
• New Default EAP Authentication Method
  In Windows XP and Windows Server 2003, the default EAP authentication method for 802.1X-authenticated wireless connections is EAP-Transport Layer Security (TLS). Although the most secure form of authentication employing mutual authentication with digital certificates, EAP-TLS requires a public key infrastructure (PKI) to distribute, revoke, and renew user and computer certificates.
  
  In many cases, organizations want to leverage the account name and password-based authentication infrastructure that already exists in Active Directory. Therefore, in Windows Vista and Windows Server 2008, the default EAP authentication method for 802.1X-authenticated wireless connections has been changed to Protected EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2). PEAP-MS-CHAP v2 is a password-based 802.1X authentication method for wireless connections that only requires computer certificates to be installed on the Remote Authentication Dial-In User Service (RADIUS) servers.
  
  
• Diagnostics Support for Wireless Connections
  Troubleshooting failed wireless connections, although improved in Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1, can still be difficult. In Windows Vista and Windows Server 2008, troubleshooting wireless connections is made much easier through the following features:
  
  
  • Wireless connections support the new Network Diagnostics Framework
    The Network Diagnostics Framework is an extensible architecture that helps users recover from and troubleshoot problems with network connections. For a failed wireless connection, the Network Diagnostics Framework will prompt a user with an option to identify and correct the problem. Wireless support for the Network Diagnostics Framework then attempts to discover the source of the failed connection and either automatically correct the problem, or, depending on security considerations, prompt the user to make the appropriate configuration change.
    
    
  • New information stored in the Windows event log
    For a failed wireless connection attempt, the wireless components of Windows Vista and Windows Server 2008 record detailed information about the connection attempt in the Windows event log. These event records can be used by support professionals within an organization to perform further troubleshooting when the wireless diagnostics either could not resolve the problem or when it could resolve the problem but the problem cannot be fixed by changing wireless client settings. The information in the Windows event log can shorten the time needed to resolve wireless connection support problems. Additionally, these event log entries can be automatically collected by network administrator using Microsoft Operations Manager or other types of central management tools and analyzed for trends and wireless infrastructure design changes.
    
    
  • Information can be sent to Microsoft for analysis and improvements
    Users that experience wireless connection problems will also be prompted to send the connection information to Microsoft for analysis through the Windows Error Reporting (WER) infrastructure. Additionally, successful diagnostics can be sent to Microsoft through the Software Quality Metrics (SQM) infrastructure, also known as the Customer Experience Improvement Program in Windows XP. In both cases, only wireless network diagnostic information is sent (no personal information about the computer or the user). Microsoft will use this information to identify the top root causes for wireless connection failures, identify new wireless connection problems and their causes, and take appropriate actions to either improve the wireless client software in Windows or work with wireless vendors to help improve wireless hardware products.
    
    
• Command Line Interface for Configuring Wireless Settings
  Windows Server 2003 or Windows XP does not have a command line interface that allows you to configure the wireless settings that are available from the wireless dialog boxes in the Network Connections folder or through the Wireless Network (IEEE 802.11) Policies Group Policy settings. Command line configuration of wireless settings can help deployment of wireless networks in the following situations:
  
  
  • Automated script support for wireless settings without using Group Policy
    Wireless Network (IEEE 802.11) Policies Group Policy settings only apply in an Active Directory domain. For an environment without Active Directory or a Group Policy infrastructure, a script that automates the configuration of wireless connections can be run either manually or automatically, such as part of the login script.
    
    
  • Bootstrap of a wireless client onto the protected organization's wireless network
    A wireless client computer that is not a member of the domain cannot connect to the organization's protected wireless network. Additionally, a computer cannot join the domain until it has successfully connected to the organization's secure wireless network. A command line script provides a method to connect to the organization's secure wireless network to join the domain.

In Windows Vista and Windows Server 2008, you can use Netsh commands in the netsh wlan context to do the following:

• Configure all wireless client settings in a named profile including general settings (the types of wireless networks to access), 802.11 settings (SSID, type of authentication, type of data encryption), and 802.1X authentication settings (EAP types and their configuration).
  

• Specify the list of allowed and denied wireless network names.
  

• Specify the order of preferred wireless networks.
  

• Display a wireless client's configuration.
  

• Remove the wireless configuration from a wireless client.
  

• Migrate wireless configuration settings between wireless clients.
  

• Network Awareness and Network Profiles
  To provide an operating system infrastructure to allow application developers to more easily develop applications that can automatically change their behavior based on the currently attached network and network conditions, the Network Awareness APIs in Windows Vista and Windows Server 2008 make network information available to applications and enables them to easily and effectively adapt to these changing environments. The Network Awareness APIs allow applications to obtain up-to-date network information and location change notification.
  
  
• Next Generation TCP/IP Stack Enhancements for Wireless Environments
  As described in the "Enhancements for High-loss Environments" section of this article, the Next Generation TCP/IP stack includes support for new TCP algorithms that optimize throughput by recovering from single and multiple packet losses and detecting spurious retransmissions, which improves performance in wireless network environments.
  
  
• Single Sign On
  The deployment of secure wireless technologies has promoted the use of Layer 2 network authentication, such as IEEE 802.1X, to ensure that only an authenticated user or device is allowed on the network and that their data is secure at the radio transmission level. The Single Sign On feature of Windows Vista and Windows Server 2008 executes 802.1X authentication at the appropriate time for a given network security configuration, while simply and seamlessly integrating with the user's Windows log-on experience. Network administrators can use Group Policy settings or the new netsh wlan commands to configure Single Sign On profiles on wireless client computers. After a Single Sign On profile is configured, 802.1X authentication will precede the computer logon to the domain and users are only prompted for credential information if needed. This feature ensures that the wireless connection is place prior to the computer domain logon, which enables scenarios that require network connectivity prior to user logon such Group Policy updates, execution of login scripts, and wireless client domain joins.
  

IEEE 802.1X-based Wired Connectivity Enhancements
In Windows XP and Windows Server 2003, there is limited support for deployment of 802.1X authentication settings for wired connections to an authenticating switch. Windows Vista and Windows Server 2008 include the following for easier deployment of 802.1X-authenticated wired connections:

• Group Policy Support for Wired 802.1X Settings
  For environments that use Active Directory and Group Policy, Windows Vista and Windows Server 2008 include Group Policy support for 802.1X authentication settings for wired connections under Computer Configuration/Windows Settings/Security Settings/Wired Network (IEEE 802.3) Policies.
  
  
• Command-Line Interface for Configuring Wired 802.1X Settings
  For environments that do not use Active Directory or Group Policy or for domain join scenarios, Windows Vista and Windows Server 2008 also support a command line interface for configuring 802.1X authentication settings for wired connections. Using commands in the netsh lan context, you can do the following:
  
  
  • Configure all wired client settings in a named profile including 802.1X authentication settings (EAP types and their configuration)
    
    
  • Display a wired client's configuration
    
    
  • Remove the wired configuration from a wired client
    
    
  • Export and import a wired profile to migrate wired configuration settings between wired clients
    
    
• Integration with Network Access Protection when using 802.1X Authentication
  IEEE 802.1X-authenticated wired connections can leverage the Network Access Protection platform to prevent wired clients that do not comply with system health requirements from gaining unlimited access to a private network. For more information about the Network Access Protection platform, see "Network Access Protection (NAP)" in this article.
  
  
• EAPHost Infrastructure
  For easier development of EAP authentication methods for IEEE 802.1X-authenticated wired connections, Windows Vista and Windows Server 2008 supports the new EAPHost infrastructure. For more information, see "EAPHost Architecture" in this article.
  
  
• Change in 802.1X Service State
  In Windows XP and Windows Server 2003, the 802.1X service was enabled by default but was placed in a passive listening mode. In Windows Vista, the 802.1X service for wired connections, known as the Wired AutoConfig service, is disabled by default, but when enabled operates in an active listening mode. To obtain an Authentication tab for the properties of a LAN connection to configure 802.1X settings, you must first start the Wired AutoConfig service.
  

Network Infrastructure
Windows Vista and Windows Server 2008 include changes to the following components and services of network infrastructure:

• Network Access Protection
  Network Access Protection (NAP) in Windows Vista and Windows Server 2008 provides policy enforcement components that help ensure that computers connecting to a network or communicating on a network comply with administrator-defined requirements for system health. For example, the requirements for system health might include that all computers have the latest operating system updates and antivirus signature files installed.
  
  Administrators can use a combination of policy validation and network access limitation components to control network access or communication. Administrators can also choose to temporarily limit the access of computers that do not meet requirements to a restricted network. Depending on the configuration chosen, the restricted network might contain resources required to update noncompliant computers so that they then meet the health requirements for unlimited network access and normal communication. NAP includes an API set for developers and vendors to create complete solutions for health policy validation, network access limitation, automatic remediation, and ongoing health policy compliance.
  
  
• NAP Enforcement Technologies
  
  • IPsec
    With IPsec Enforcement, you can confine the communication on your network to compliant computers. Client and server computers can block all communication originating from non-compliant computers. IPsec Enforcement confines communication to compliant computers after they have successfully connected and obtained a valid IP address configuration. IPsec Enforcement is the strongest form of limited network access in Network Access Protection.
    
    
  • IEEE 802.1X
    With 802.1X Enforcement, a Network Policy Server (NPS) instructs an 802.1X-based access point (an Ethernet switch or a wireless access point) to place a restricted access profile on the 802.1X client until it performs a set of health remediation functions. A restricted access profile can consist of a set of IP packet filters or a virtual LAN identifier to confine the traffic of an 802.1X client. 802.1X Enforcement provides strong limited network access for all computers accessing the network through an 802.1X connection. For more information about NPS, see "Network Policy Server" in this article.
    
    
  • VPN
    With VPN Enforcement, VPN servers can enforce health policy requirements any time a computer attempts to make a VPN connection to the network. VPN Enforcement provides strong limited network access for all computers accessing the network through a VPN connection. VPN Enforcement with NAP is different than Network Access Quarantine Control, a feature in Windows Server 2003. Both VPN Enforcement in NAP and Network Access Quarantine Control perform a similar function, but NAP is easier to deploy.
    
    
  • DHCP
    With DHCP Enforcement, DHCP servers can enforce health policy requirements any time a computer attempts to lease or renew an IP address configuration on the network. DHCP Enforcement relies on IP routing table entries and is the weakest form of NAP enforcement.
    

  Using NAP APIs, third-party software vendors can create their own NAP enforcement technologies.
  

• Network Policy Server
  Network Policy Server (NPS) is the Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) server and proxy in Windows Server 2008. NPS replaces the Internet Authentication Service (IAS) in Windows Server 2003. NPS performs all of the functions of IAS in Windows Server 2003 for VPN and 802.1X-based wireless and wired connections and performs health evaluation and the granting of either unlimited or limited access for Network Access Protection clients. For more information, see "Network Access Protection" in this article. NPS also supports sending RADIUS traffic over IPv6, as specified in RFC 3162.
  
  
• New EAPHost Architecture
  Windows Vista and Windows Server 2008 include EAPHost, a new architecture for Extensible Authentication Protocol (EAP) authentication methods and EAP-based supplicants. EAPHost provides the following features that are not supported by the EAP implementation in Windows XP and Windows Server 2003:
  
  
  • Support for additional EAP methods
    
    
  • Network Discovery
    EAPHost will support network discovery as defined in the "Identity Hints for EAP" Internet draft (draft-adrangi-eap-network-discovery-13.txt)
    
    
  • RFC 3748 compliance
    EAPHost will conform to the EAP State Machine and address a number of security vulnerabilities that have been specified in RFC 3748. Additionally, EAPHost will support additional capabilities such as Expanded EAP Types (including vendor-specific EAP Methods).
    
    
  • EAP method coexistence
    EAPHost allows multiple implementations of the same EAP method to coexist simultaneously. For example, the Microsoft version of PEAP and the Cisco Systems, Inc. version of PEAP can be installed and selected.
    
    
  • Modular supplicant architecture
    In addition to supporting modular EAP methods, EAPHost also supports a modular supplicant architecture in which new supplicants can be easily added without having to replace the entire EAP implementation.
    

For EAP method vendors, EAPHost provides support for EAP methods already developed for Windows XP and Windows Server 2003 and an easier method of developing new EAP methods for and Windows Vista and Windows Server 2008. Certified EAP methods can be distributed with Windows Update. EAPHost also allows better classification of EAP types so that the built-in 802.1X and PPP-based Windows supplicants can use them.

For supplicant method vendors, EAPHost provides support for modular and pluggable supplicants for new link layers. Because EAPHost is integrated with NAP, new supplicants do not have to be NAP-aware. In order to participate in NAP, new supplicants just need to register a connection identifier and a callback function that informs the supplicant to reauthenticate.

For network administrators, EAPHost provides availability of new EAP methods and a more robust and flexible infrastructure for 802.1X-authentication connections.

• Remote Access and VPN Connection Enhancements
  
  
  • VPN Enforcement for remote access VPN connections
    The built-in VPN client and Routing and Remote Access add components to support VPN Enforcement in the NAP platform. For more information, see "Network Access Protection" in this article.
    
    
  • IPv6 support
    The built-in remote access client and Routing and Remote Access now support IPv6 over the Point-to-Point Protocol (PPP) (PPPv6), defined in RFC 2472. Native IPv6 traffic can now be sent over PPP-based connections. For example, PPPv6 support allows you to connect with an IPv6-based Internet service provider (ISP) through dial-up or PPP over Ethernet (PPPoE)-based connections (used for broadband Internet access). The built-in remote access client and Routing and Remote Access also support IPv6-based Layer Two Tunneling Protocol with IPsec (L2TP/IPsec) VPN connections. Additional IPv6 support includes a DHCPv6 Relay Agent, IPv6-based static packet filters, and sending and receiving RADIUS traffic over IPv6.
    
    
  • A revised connection creation wizard
    This new wizard provides a simplified way to configure dial-up, broadband Internet, VPN, and incoming connections.
    
    
  • Updated Winlogin support
    Allows a third-party access provider to plug in their connections to automatically create a remote access connection during the user login.
    
    
  • Multiple-locale support for the Connection Manager Administration Kit
    Allows Connection Manager profiles to be created on a server of any locale for installation on a client of any other locale running Windows Vista or Windows XP, which simplifies Connection Manager Administration Kit (CMAK)-based client management.
    
    
  • Connection Manager clients support DNS dynamic update
    Connection Manager clients now support the registering of DNS names and IP addresses using DNS dynamic update.
    
    
  • New Cryptographic Support
    L2TP/IPsec-based VPN connections now support the Advanced Encryption Standard (AES) with 128 and 256-bit keys. Support for weaker cryptographic algorithms-40 and 56-bit RC4 for PPTP and DES with MD5 for L2TP/IPsec-has been removed.
    
    
  • Support for Network Diagnostics Framework
    Client-based connections support basic diagnostics capabilities with the Network Diagnostics Framework.
    
    
• DHCP Enhancements
  
  
  • Dynamic Host Configuration Protocol for IPv6 (DHCPv6) support
    Dynamic Host Configuration Protocol for IPv6 (DHCPv6) defined in RFC 3315, provides stateful address configuration for IPv6 hosts on a native IPv6 network.
    
    
  • Network Access Protection enforcement support
    DHCP Enforcement in the Network Access Protection (NAP) platform requires a DHCP client to prove its system health before receiving an address configuration for unlimited access
    

Removal of Technologies
Support for the following technologies has been removed from Windows Vista and Windows Server 2008:

• Bandwidth Allocation Protocol (BAP)
  
  
• X.25
  
  
• Serial Line Interface Protocol (SLIP)
  SLIP-based connections will automatically be updated to PPP-based connections.
  
  
• Asynchronous Transfer Mode (ATM)
  
  
• IP over IEEE 1394
  
  
• NWLink IPX/SPX/NetBIOS Compatible Transport Protocol
  
  
• Services for Macintosh (SFM)
  
  
• Open Shortest Path First (OSPF) routing protocol component in Routing and Remote Access
  
  
• Basic Firewall in Routing and Remote Access (replaced with Windows Firewall)
  
  
• Static IP filter APIs for Routing and Remote Access (replaced with Windows Filtering Platform APIs)
  

Resources:

New Networking Features in Windows Server 2008 and Windows Vista
http://www.microsoft.com/technet/network/evaluate/new_network.mspx

Windows Vista Networking
http://www.microsoft.com/technet/windowsvista/network/default.mspx

Windows Server 2008 Web site
http://www.microsoft.com/windowsserver2008/default.mspx

Microsoft Windows 2000 TCP/IP Implementation Details
http://www.microsoft.com/technet/network/deploy/depovg/tcpip2k.mspx

Windows Server 2008 Web site
http://www.microsoft.com/windowsserver2008/default.mspx

Connectivity