Windows Vista networking technologies

Architecture of the Next Generation TCP/IP stack

The Next Generation TCP/IP stack connects to NICs via a Network Driver Interface Specification (NDIS) driver. The network stack, implemented in tcpip.sys implements the Transport, Network and Data link layers of the TCP/IP model. The Transport layer includes implementations for TCP, UDP and unformatted RAW protocols. At the Network layer, IPv4 and IPv6 protocols are implemented in a dual-stack architecture. And the Data link layer (also called Framing layer) implements 802.3, 802.1, PPP, Loopback and tunnelling protocols. Each layer can accommodate Windows Filtering Platform (WFP) shims, which allows packets at that layer to be introspected and also host the WFP Callout API. The networking API is exposed via three components:[1]

Winsock

A user mode API for abstracting network communication using sockets and ports. Datagram sockets are used for UDP, whereas Stream sockets are for TCP. While Winsock is a user mode library, it uses a kernel mode driver, called Ancillary Function Driver (AFD) to implement certain functionality.

Winsock Kernel (WSK)

A kernel-mode API providing the same socket-and-port abstraction as Winsock, while exposing other features such as Asynchronous I/O using I/O request packets.

Transport Driver Interface (TDI)

A kernel-mode API which can be used for legacy protocols like NetBIOS. It includes a component, known as TDX to map the TDI functionality to the network stack.

The Network and Sharing Center

The user interface for configuring, troubleshooting and working with network connections has changed significantly from prior versions of Windows as well. Users can make use of the new "Network and Sharing Center" to see the status of their network connections, and to access every aspect of configuration. A single icon in the notification area (system tray) represents connectivity through all network adapters, whether wired or wireless. The network can be browsed using Network Explorer, which replaces Windows XP's "My Network Places". Network Explorer items can be a shared device such as a scanner, or a file share. The Network Location Awareness (NLA) service uniquely identifies each network and exposes the network's attributes and connectivity type so that applications can determine the optimal network configuration. However, applications have to use the NLA APIs explicitly to be aware of the network connectivity changes, and adapt accordingly. Windows Vista uses the Link Layer Topology Discovery (LLTD) protocol to graphically present how different devices are connected over a network, as a Network Map. In addition, the Network Map uses LLTD to determine connectivity information and media type (wired or wireless), so that the map is topologically accurate. The ability to know network topology is important for diagnosing and solving networking problems, and for streaming content over a network connection. Any device can implement LLTD to appear on the Network Map with an icon representing the device, allowing users one-click access to the device's user interface. When LLTD is invoked, it provides metadata about the device that contains static or state information, such as the MAC address, IPv4/IPv6 address, signal strength etc.

Windows Vista classifies the networks it connects to as either Public, Private or Domain and uses Network Location Awareness to switch between network types. Different network types have different firewall policies. An open network such as a public wireless network is classified as Public and is the most restrictive of all network settings. In this mode other computers on the network are not trusted and external access to the computer, including sharing of files and printers, is disabled. A home network is classified as Private, and it enables file sharing between computers. If the computer is joined to a domain, the network is classified as a Domain network; in such a network the policies are set by the domain controller. When a network is first connected to, Windows Vista prompts to choose the correct network type. On subsequent connections to the network, the service is used to gain information on which network is connected to and automatically switch to the network configuration for the connected network. Windows Vista introduces a concept of network profiles. For each network, the system stores the IP address, DNS server, Proxy server and other network features specific to the network in that network's profile. So when that network is subsequently connected to, the settings need not be reconfigured, the ones saved in its profile are used. In the case of mobile machines, the network profiles are chosen automatically based on what networks are available. Each profile is part of either a Public, Private or Domain network.

The Windows Vista networking stack supports the dual Internet Protocol (IP) layer architecture in which the IPv4 and IPv6 implementations share common Transport and Framing layers. Windows Vista provides a GUI for configuration of both IPv4 and IPv6 properties. IPv6 is now supported by all networking components and services. The Windows Vista DNS client can use IPv6 transport. Internet Explorer in Windows Vista and other applications that use WinINet (Windows Mail, file sharing) support literal IPv6 addresses (RFC 2732). Windows Firewall and the IPsec Policies snap-in support IPv6 addresses as permissible character strings. In IPv6 mode, Windows Vista can use the Link Local Multicast Name Resolution (LLMNR) protocol, as described in RFC 4795, to resolve names of local hosts on a network which does not have a DNS server running. This service is useful for networks without a central managing server, and for ad hoc wireless networks. IPv6 can also be used over PPP-based dial-up and PPPoE connections. Windows Vista can also act as a client/server for file sharing or DCOM over IPv6. Support for DHCPv6, which can be used with IPv6, is also included. IPv6 can even be used when full native IPv6 connectivity is not available, using Teredo tunneling; this can even traverse most IPv4 symmetric Network Address Translations (NATs) as well. Full support for multicast is also included, via the MLDv2 and SSM protocols. The IPv6 interface ID is randomly generated for permanent autoconfigured IPv6 addresses to prevent determining the MAC address based on known company IDs of NIC manufacturers.

Support for wireless networks is built into the network stack itself as a new set of APIs called Native Wifi, and does not emulate wired connections, as was the case with previous versions of Windows. This allows implementation of wireless-specific features such as larger frame sizes and optimized error recovery procedures. Native Wifi is exposed by Auto Configuration Module (ACM) which replaces Windows XP's Wireless Zero Configuration. The ACM is extensible, so developers can incorporate additional wireless functionality (such as automatic wireless roaming) and override the automatic configuration and connection logic without affecting the built-in framework. It is easier to find wireless networks in range and tell which networks are open and which are closed. Hidden wireless networks, which do not advertise their name (SSID) are better supported. Security for wireless networks is improved with improved support for newer wireless standards like 802.11i. EAP-TLS is the default authentication mode. Connections are made at the most secure connection level supported by the wireless access point. WPA2 can be used even in ad-hoc mode. Windows Vista also provides a Fast Roaming service that will allow users to move from one access point to another without loss of connectivity. Preauthentication with the new wireless access point can be used to retain the connectivity. Wireless networks are managed from either the Connect to a network dialog box within the GUI or the netsh wlan command from the shell. Settings for wireless networks can also be configured using Group policy.

Windows Vista enhances security when joining a domain over a wireless network. It can use Single Sign On to use the same credentials to join a wireless network as well as the domain housed within the network. In this case, the same RADIUS server is used for both PEAP authentication for joining the network and MS-CHAP v2 authentication to log into the domain. A bootstrap wireless profile can also be created on the wireless client, which first authenticates the computer to the wireless network and joins the network. At this stage, the machine still does not have any access to the domain resources. The machine will run a script, stored either on the system or on USB thumb drive, which authenticates it to the domain. Authentication can be done either by using username and password combination or security certificates from a Public key infrastructure (PKI) vendor such as VeriSign.

Windows Vista features Windows Connect Now which supports setting up a wireless network using several methods supported in the Wi-Fi Protected Setup standard. It implements a native code API, Web Services for Devices (WSDAPI) to support Devices Profile for Web Services (DPWS) and also a managed code implementation in WCF. DPWS enables simpler device discoverability like UPnP and describes available services to those clients. Function Discovery is a new technology that serves as an abstraction layer between applications and devices, allowing applications to discover devices by referencing the device's function, rather than by its bus type or the nature of its connection. Plug and Play Extensions (PnP-X) allow network-connected devices to appear as local devices inside Windows connected physically. UPnP support has also been enhanced to include integration with PnP-X and Function Discovery.

Windows Vista's networking stack also uses several performance optimizations, which allow higher throughput by allowing faster recovery from packet losses, when using a high packet loss environment such as wireless networks. Windows Vista uses the NewReno (RFC 2582) algorithm which allows a sender to send more data while retrying in case it receives a partial acknowledgement, which is acknowledgement from the receiver for only a part of data that has been received. It also uses Selective Acknowledgements (SACK) to reduce the amount of data to be retransmitted in case a portion of the data sent was not received correctly, and Forward RTO-Recovery (F-RTO) to prevent unnecessary retransmission of TCP segments when round trip time increases. It also includes Neighbour Unreachability Detection capability in both IPv4 and IPv6, which tracks the accessibility of neighboring nodes. This allows faster error recovery, in case a neighboring node fails. NDIS 6.0 introduced in Windows Vista supports offloading IPv6 traffic and checksum calculations for IPv6, improved manageability, scalability and performance with reduced complexity for NDIS miniports, and simpler models for writing Lightweight Filter Drivers (LWF). LWF drivers are a combination of NDIS intermediate drivers and a miniport driver that eliminate the need to write a separate protocol and miniport and have a bypass mode to examine only selected control and data paths. The TCP/IP stack also provides fail-back support for default gateway changes by periodically attempting to send TCP traffic through a previously detected unavailable gateway. This can provide faster throughput by sending traffic through the primary default gateway on the subnet.

Another significant change that aims to improve network throughput is the automatic resizing of TCP Receive window. The receive window (RWIN) specifies how much data a host is prepared to receive, and is limited by, among other things, the available buffer space. In other words, it is a measure of how much data the remote transmitter can send before requiring an acknowledgement for the outstanding data. When the receive window is too small, the remote transmitter will frequently find that it has hit the limit of how much outstanding data it can transmit, even though there is enough bandwidth available to transmit more data. This leads to incomplete link utilization. So using a larger RWIN size boosts throughput in such situations; an auto-adjusting RWIN tries to keep the throughput rate as high as is permissible by the bandwidth of the link. Receive window auto tuning functionality continually monitors the bandwidth and the latency of TCP connections individually and optimize the receive window for each connection. The window size is increased in high-bandwidth (~5 Mbit/s+) or high-latency (>10ms) situations.

Traditional TCP implementations uses the TCP Slow Start algorithm to detect how fast it can transmit without choking the receiver (or intermediate nodes). In a nutshell, it specifies that transmission should start at a slow rate, by transmitting a few packets. This number is controlled by the Congestion window – which specifies the number of outstanding packets that has been transmitted but for which an acknowledgement of receipt from the receiver has not yet been received. As acknowledgements are received, the congestion window is expanded, one TCP segment at a time till an acknowledgement fails to arrive. Then the sender assumes that with the congestion window size of that instant, the network gets congested. However, a high bandwidth network can sustain a quite large congestion window without choking up. The slow start algorithm can take quite some time to reach that threshold – leaving the network under-utilized for a significant time.

The new TCP/IP stack also supports Explicit Congestion Notification (ECN) to keep throughput hit due to network congestion as low as possible. Without ECN, a TCP message segment is dropped by some router when its buffer is full. Hosts get no notice of building congestion until packets start being dropped. The sender detects the segment did not reach the destination; but due to lack of feedback from the congested router, it has no information on the extent of reduction in transmission rate it needs to make. Standard TCP implementations detect this drop when they time out waiting for acknowledgement from the receiver. The sender then reduces the size of its congestion window, which is the limit on the amount of data in flight at any time. Multiple packet drops can even result in a reset of the congestion window, to TCP's Maximum Segment Size, and a TCP Slow Start. Exponential backoff and only additive increase produce stable network behaviour, letting routers recover from congestion. However, the dropping of packets has noticeable impacts on time-sensitive streams like streaming media, because it takes time for the drop to be noticed and retransmitted. With ECN support enabled, the router sets two bits in the data packets that indicate to the receiver it is experiencing congestion (but not yet fully choked). The receiver in turn lets the sender know that a router is facing congestion and then the sender lowers its transmission rate by some amount. If the router is still congested, it will set the bits again, and eventually the sender will slow down even more. The advantage of this approach is that the router does not get full enough to drop packets, and thus the sender does not have to lower the transmission rate significantly to cause serious delays in time-sensitive streams; nor does it risk severe under-utilization of bandwidth. Without ECN, the only way routers can tell hosts anything is by dropping packets. ECN is like Random Early Drop, except that the packets are marked instead of dropped. The only caveat is that both sender and receiver, as well as all intermediate routers, have to be ECN-friendly. Any router along the way can prevent the use of ECN if it considers ECN-marked packets invalid and drops them (or more typically the whole connection setup fails because of a piece of network equipment that drops connection setup packets with ECN flags set). Routers that don't know about ECN can still drop packets normally, but there is some ECN-hostile network equipment on the Internet. For this reason, ECN is disabled by default. It can be enabled via the netsh interface tcp set global ecncapability=enabled command.[3]

In previous versions of Windows, all processing needed to receive or transfer data over one network interface was done by a single processor, even in a multi processor system. With supported network interface adapters, Windows Vista can distribute the job of traffic processing in network communication among multiple processors. This feature is called Receive Side Scaling. Windows Vista also supports network cards with TCP Offload Engine, that have certain hardware-accelerated TCP/IP-related functionality. Windows Vista uses its TCP Chimney Offload system to offload to such cards framing, routing, error-correction and acknowledgement and retransmission jobs required in TCP. However, for application compatibility, only TCP data transfer functionality is offloaded to the NIC, not TCP connection setup. This will remove some load from the CPU. Traffic processing in both IPv4 and IPv6 can be offloaded. Windows Vista also supports NetDMA, which uses the DMA engine to allow processors to be freed from the hassles of moving data between network card data buffers and application buffers. It requires specific hardware DMA architectures, such as Intel I/O Acceleration to be enabled.

Windows Vista's networking stack includes integrated policy-based quality of service (QoS) functionality to prioritize network traffic. Quality of service can be used to manage network usage by specific applications or users, by throttling the bandwidth available to them, or it can be used to limit bandwidth usage by other applications when high priority applications, such as real time conferencing applications, are being run, to ensure they get the bandwidth they need. Traffic throttling can also be used to prevent large data transfer operations from using up all the available bandwidth. QoS policies can be confined by application executable name, folder path, source and destination IPv4 or IPv6 addresses, source and destination TCP or UDP ports or a range of ports. In Windows Vista, QoS policies can be applied to any application at the Network Layer, thus eliminating the need to rewrite applications using QoS APIs to be QoS-aware. QoS policies can either be set on a per-machine basis or set by Active Directory Group policy objects which ensures that all Windows Vista clients connected to the Active Directory container (a domain, a site or an organizational unit)[5] will enforce the policy settings.

Windows Vista supports the Wireless Multimedia (WMM) profile classes for QoS in wireless networks as certified by the Wi-Fi Alliance: BG (for background data), BE (for best effort non real time data), VI (for real time videos) and VO (for real time voice data).[6] When both the wireless access point as well as the wireless NIC supports the WMM profiles, Windows Vista can provide preferential treatment to the data sent.

qWave

The Feedback Loop of qWave

Windows Vista includes a specialized QoS API called qWave (Quality Windows Audio/Video Experience),[7] which is a pre-configured quality of service module for time dependent multimedia data, such as audio or video streams. qWave uses different packet priority schemes for real-time flows (such as multimedia packets) and best-effort flows (such as file downloads or e-mails) to ensure that real-time data gets as little delays as possible, while providing a high quality channel for other data packets.

qWave is intended to ensure real-time transport of multimedia networks within a wireless network. qWave supports multiple simultaneous multimedia as well as data streams. qWave does not depend solely on bandwidth reservation schemes, as provided by RSVP for providing QoS guarantees, as the bandwidth in a wireless network fluctuates constantly. As a result, it also uses continuous bandwidth monitoring to implement service guarantees.[7]

Applications have to explicitly use the qWave APIs to use the service. When the multimedia application requests qWave to initiate a new media stream, qWave tries to reserve bandwidth using RSVP. At the same time, it uses QoS probes to make sure the network has enough bandwidth to support the stream. If the conditions are met, the stream is allowed, and prioritized so that other applications do not eat into its share of bandwidth. However, environmental factors can affect the reception of the wireless signals, which can reduce the bandwidth, even if no other stream is allowed to access the reserved bandwidth. Due to this, qWave continuously monitors the available bandwidth, and if it decreases, the application is informed, creating a feedback loop, so that it can adapt the stream to fit into the lower bandwidth range. If more bandwidth is available, qWave automatically reserves it and informs the application of the improvement.[7]

For probing the quality of the network, probe packets are sent to the source and statistics (such as round trip time, loss, latency jitter etc.) of their path analyzed and the results are cached. The probe is repeated after specific time intervals to update the cache. Whenever the stream is requested, the cache is looked up. qWave also serializes creation of multiple simultaneous streams, even across devices, so that probes sent for one stream are not interfered by others. qWave uses client side buffers to keep transmission rate within range of the slowest part in the network, so that the access point buffers are not overwhelmed, thus reducing packet loss.[7]

qWave works best if both the source and sink (client) of the multimedia stream are qWave aware. Also, the wireless access point (AP) needs to be QoS-enabled, supporting bandwidth reservation. It can also work without QoS-aware APs; however, since qWave cannot reserve bandwidth in this case, it has to depend on the application to adapt the stream based on the available bandwidth, which not only will be affected by network conditions, but other data in the network as well. qWave is also available for other devices as a part of the Windows Rally technologies.[7]

In order to provide better security when transferring data over a network, Windows Vista provides enhancements to the cryptographic algorithms used to obfuscate data. Support for 256-bit, 384-bit and 512-bit Elliptic curve Diffie–Hellman (ECDH) algorithms, as well as for 128-bit, 192-bit and 256-bit Advanced Encryption Standard (AES) is included in the network stack itself. Direct support for SSL connections in new Winsock API allows socket applications to directly control security of their traffic over a network (such as providing security policy and requirements for traffic, querying security settings) rather than having to add extra code to support a secure connection. Computers running Windows Vista can be a part of logically isolated networks within an Active Directory domain. Only the computers which are in the same logical network partition will be able to access the resources in the domain. Even though other systems may be physically on the same network, unless they are in the same logical partition, they won't be able to access partitioned resources. A system may be part of multiple network partitions.

Windows Vista also includes an Extensible Authentication Protocol Host (EAPHost) framework that provides extensibility for authentication methods for commonly used protected network access technologies such as 802.1X and PPP.[8] It allows networking vendors to develop and easily install new authentication methods known as EAP methods.

A planned feature in the new TCP/IP suite known as "Routing Compartments", utilized a per-user routing table, thus compartmentalizing the network according to the user's needs, so that data from one segment would not go into another. This feature however was removed before the release of Windows Vista, and is slated to be included possibly in a future release of Windows.[9]

The ability to assist the user in diagnosing a network problem is expected to be a major new networking feature. There is extensive support for runtime diagnostics for both wired and wireless networks, including support for TCP Management information base (MIB)-II and better system event logging and tracing. The Vista TCP/IP stack also supports ESTATS which defines extended performance statistics for TCP and can help in determining the cause of network performance bottlenecks. Windows Vista can inform the user of most causes of network transmission failure, such as incorrect IP address, incorrect DNS and default gateway settings, gateway failure, port in use or blocked, receiver not ready, DHCP service not running, NetBIOS over TCP/IP name resolution failure etc. Transmission errors are also exhaustively logged, which can be analyzed to better find the cause of error. Windows Vista has a greater awareness of the network topology the host computer is in, using technologies such as Universal Plug and Play. With this new network awareness technology, Windows Vista can provide help to the user in fixing network issues or simply provide a graphical view of the perceived network configuration.

The Windows Vista network stack includes Windows Filtering Platform,[10] which allows external applications to access and hook into the packet processing pipeline of the networking subsystem. WFP allows incoming and outgoing packets to be filtered, analyzed or modified at several layers of the TCP/IP protocol stack. Because WFP has an inbuilt filtering engine, applications need not write any custom engine, they just need to provide the custom logic for the engine to use. WFP includes a Base Filtering Engine which implements the filter requests. The packets are then processed using the Generic Filtering Engine, which also includes a Callout Module, where applications providing the custom processing logic can be hooked up. WFP can be put to uses such as inspecting packets for malware, selective packet restriction, such as in firewalls, or providing custom encryption systems, among others. Upon its initial release WFP was plagued with bugs including memory leaks and race conditions.[11]

The Windows Firewall in Windows Vista is implemented through WFP.[12]

Windows Vista includes significant peer-to-peer support with the introduction of new APIs and protocols. A new version of the Peer Name Resolution Protocol (PNRP v2), as well as a set of Peer Distributed Routing Table, Peer Graphing, Peer Grouping, Peer Naming, and Peer Identity Management APIs are introduced. Contacts can be created and administered with the new peer-to-peer subsystem—serverless presence allows users to manage real-time presence information and track the presence of other registered users across a subnet or the Internet. A new People Near Me service allows for the discovery and management of contacts on the same subnet and uses Windows Contacts to manage and store contact information; the new capabilities allows peers to send application invitations to other peers (ad-hoc collaboration is also supported) without a centralized server. Windows Meeting Space is an example of such an application.

PNRP also allows creating an overlay network called a Graph. Each peer in the overlay network corresponds to a node in the graph. All the nodes in a graph share book-keeping information responsible for the functioning of the network as a whole. For example, in a distributed resource management network, which node has what resource needs to be shared. Such information is shared as Records, which are flooded to all the peers in a graph. Each peer stores the Record to a local database. A Record consists of a header and a body. The body contains data specific to the application that is using the API; the header contains metadata to describe the data in the body as name-value pairs serialized using XML, in addition to author and version information. It can also contain an index of the body data, for fast searching. A node can connect to other nodes directly as well, for communication that need not be shared with the entire Graph. The API also allows creation of a secure overlay network called a Group, consisting of all or a subset of nodes in a Graph. A Group can be shared by multiple applications, unlike a Graph. All peers in a Group must be identifiable by a unique named, registered using PNRP, and have a digital signature certificate termed as Group Member Certificate (GMC). All Records exchanged are digitally signed. Peers must be invited into a Group. The invitation contains the GMC that enables it to join the group.[13]

A new Windows Internet Computer Names (WICN) peer networking feature allows an IPv6-connected machine to obtain a custom or unique domain name. If the computer is connected to the Internet, users can specify a secured or unsecured host name for their computer from a console command, without requiring to register a domain name and configuring a dynamic DNS. WICN can be used in any application that accepts an IP address or DNS name; PNRP performs all the domain name resolution at the peer-to-peer level.

Another planned feature in Windows Vista would have provided a new domain-like networking setup known as a Castle, but this did not make it into the release. Castle would have made it possible to have an identification service, which provides user authentication, for all members on the network, without a centralized server. It would have allowed user credentials to propagate across the peer-to-peer network, making them more suitable for a home network.

The new Background Intelligent Transfer Service (BITS) 3.0 has a new feature called Neighbor Casting which supports peer-to-peer file transfers within a domain. This facilitates peer caching, allows users to download and serve content (such as WSUS updates) from peers on the same subnet, receive notification when a file is downloaded, access the temporary file while the download is in progress, and control HTTP redirects. This saves bandwidth on the network and reduces performance load on the server. BITS 3.0 also uses Internet Gateway Device Protocol counters to more accurately calculate available bandwidth.

The HTTP kernel mode driver in Windows Vista, Http.sys has been enhanced to support server-side authentication, logging, IDN hostnames, Event Tracing and better manageability through netsh http and new performance counters. WinINet, the protocol handler for HTTP and FTP handles IPv6 literal addresses, includes support for Gzip and deflate decompression to improve content encoding performance, Internationalized domain names support and Event Tracing. WinHTTP, the client API for server-based applications and services supports IPv6, AutoProxy, HTTP/1.1 chunked transfer encoding, larger data uploads, SSL and client certificates, server and proxy authentication, automatic handling of redirects and keep-alive connections and HTTP/1.0 protocol, including support for keep-alive (persistent) connections and session cookies. Winsock has been updated with new APIs and support for Event Tracing. Winsock Layered Service Provider support has been enhanced with logged installations and removals, a new API for reliably installing LSPs, a command to reliably remove LSPs, facilities to categorize LSPs and to remove most LSPs from the processing path for system critical services and support for Network Diagnostics Framework.

A new version of the Server Message Block (SMB) protocol was introduced with Windows Vista.[20] It has a number of changes to improve performance and add additional capabilities. Windows Vista and later operating systems use SMB 2.0 when communicating with other machines running Windows Vista or later. SMB 1.0 continues in use for connections to any previous version of Windows, or to Samba. Samba 3.6 also includes support for SMB 2.0.[21]

Remote Differential Compression (RDC) is a client-server synchronization protocol allows data to be synchronized with a remote source using compression techniques to minimize the amount of data sent across the network. It synchronizes files by calculating and transferring only the differences between them on-the-fly. Therefore, RDC is suitable for efficient synchronization of files that have been updated independently, or when network bandwidth is small or in scenarios where the files are large but the differences between them are small.

The Bluetooth Devices Control Panel applet introduced with Windows XP was a window that displayed paired devices on a Devices tab. When a device was opened, the device category, last connection time, MAC address, and type of connection for the device were displayed. Devices were always grouped by categories (such as phones and modems). In Windows Vista, Bluetooth Devices replaces this Devices tab and is part of the Windows Shell. Users can now filter, group, and sort devices by their properties; scale device icons; and search for connected or paired devices. New properties are introduced for Bluetooth devices — Authenticated, Connection In Use, Discovery Method, Encrypted, Paired, Version — and users can group, sort, and search for devices based on these properties. Additionally, all properties are displayed in the new Details Pane.

• Windows Vista and later support the use of PEAP with PPTP. The authentication mechanisms supported are PEAPv0/EAP-MSCHAPv2 (passwords) and PEAP-TLS (smartcards and certificates).
• Secure Socket Tunneling Protocol (SSTP), introduced in Windows Vista Service Pack 1 is a form of VPN tunnel that provides a mechanism to transport PPP or L2TP traffic through an SSL 3.0 channel. SSL provides transport-level security with key-negotiation, encryption and traffic integrity checking.

• Enterprise Networking with Windows Vista
• Connecting to Wireless Networks with Windows Vista
• Policy-based QoS Architecture in Windows Server 2008 and Windows Vista
• Windows Core Networking