The TCP/IP networking stack in the previous Windows
XP and Windows Server 2003 platforms had a dual stack architecture that
used separate transport and framing layers for IPv4 and IPv6 based on
separate drivers: Tcpip.sys and Tcpip6.sys. Only the transport and
framing layers for IPv4 were installed by default, and adding support
for IPv6 involved installing an additional IPv6 protocol component
through the Network Connections folder.
By
contrast, in Windows Vista and Windows Server Code Name “Longhorn” the
TCP/IP stack has been completely redesigned and now uses a dual IP
layer architecture in which both IPv4 and IPv6 share a common transport
and framing layer. In addition, IPv6 is installed and enabled by
default in these new platforms to provide out-of-the-box support for
new features such as the Windows Meeting Space application, which uses
only IPv6. Finally, the new a dual IP layer architecture means that all
of the performance enhancements of the Next Generation TCP/IP stack
that apply to IPv4 also apply to IPv6. These performance enhancements
include Compound TCP, Receive Window Auto-Tuning, and other
enhancements that can dramatically improve performance in high-latency,
high-delay, and high-loss networking environments.
Note
For more information about the performance enhancements in the Next Generation TCP/IP stack. |
Summary of IPv6 Enhancements in Windows Vista
The following list summarizes the changes to IPv6 support in Windows Vista compared with previous Microsoft Windows platforms:
Dual IP layer architecture A new TCP/IP stack architecture that uses the same transport and framing layers for both IPv4 and IPv6.
Enabled by default
Both IPv4 and IPv6 are installed and enabled by default, with the stack
giving preference to IPv6 when appropriate without impairing the
performance of IPv4 communications on the network. For example, if a
DNS name query returns both an IPv4 and IPv6 address for a host, the
client will try to use IPv6 first for communicating with the host. This
preference also results in better network performance for IPv6-enabled
applications.
User interface configuration support In addition to being able to configure IPv6 settings from the command line using the netsh interface ipv6
command context, you can also configure them in Windows Vista using the
user interface.
Full IPsec support
IPv6 support in previous versions of Microsoft Windows offered only
limited support for IPsec protection of network traffic. In Windows
Vista, however, IPsec support for IPv6 is the same as for IPv4, and you
can configure IPsec connection security rules for IPv6 the same as for
IPv4, using the Windows Firewall With Advanced Security console.
LLMNR support
Windows Vista’s implementation of IPv6 supports Link-Local Multicast
Name Resolution (LLMNR), a mechanism that enables IPv6 nodes on a
single subnet to resolve each other’s names in the absence of a DNS
server. LLMNR works by having nodes send multicast DNS name queries
instead of unicast queries. Windows Vista computers listen by default
for multicast LLMNR traffic, which eliminates the need to perform local
subnet name resolution using NetBIOS over TCP/IP when no DNS server is
available. LLMNR is currently on track for RFC status.
MLDv2 support
Windows Vista’s implementation of IPv6 supports Multicast Listener
Discovery (MLD) version 2 (MLDv2), a mechanism described in RFC 3810
that enables IPv6 hosts to register interest in source-specific
multicast traffic with local multicast routers by specifying an include
list (to indicate specific source addresses of interest) or an exclude
list (to exclude unwanted source addresses).
DHCPv6 support
Windows Vista’s DHCP Client service supports Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) as defined in RFCs 3736 and 4361. This means
that Windows Vista computers can perform both stateful and stateless
DHCPv6 configuration on a native IPv6 network.
IPV6CP support
Windows Vista’s built-in remote access client component supports IPv6
Control Protocol (IPV6CP) (RFC 2472) to configure IPv6 nodes on a
Point-to-Point Protocol (PPP) link. This means that native IPv6 traffic
can be sent over PPP-based network connections such as dial-up
connections or broadband PPP over Ethernet (PPPoE) connections to an
Internet Service Provider (ISP). IPV6CP also supports Layer 2 Tunneling
Protocol (L2TP)–based Virtual Private Network (VPN) connections.
Random Interface IDs By
default, Windows Vista generates random interface IDs for non-temporary
autoconfigured IPv6 addresses, including both public addresses (global
addresses registered in DNS) and link-local addresses.
Literal IPv6 addresses in URLs
Windows Vista supports RFC 2732–compliant literal IPv6 addresses in
URLs by using the new WinINet API support in Microsoft Internet
Explorer 7.0. This can be a useful feature for troubleshooting Internet
connectivity with IPv6-enabled Web servers.
New Teredo Behavior
The Teredo client in Windows Vista remains dormant (inactive) until it
spins up (is activated by) an IPv6-enabled application that tries to
use Teredo. In Windows Vista, three things can bring up Teredo: an
application trying to communicate using a Teredo address (the outbound
instantiated scenario); a listening application that has the Edge
Traversal rule enabled in Windows Firewall (any IPv6-enabled
applications that need to use Teredo can easily do so by setting the
Edge Traversal flag using the Windows Firewall APIs); and the
NotifyStableUnicastIpAddressTable IP Helper API.
Teredo is default-enabled but inactive in both workgroup and domain scenarios. Teredo becomes active in two main scenarios:
An
application tries to communicate with a Teredo address (for example, by
using a URL with a Teredo address in a Web browser). This is
outbound-initiated traffic, and Teredo will go dormant again after 60
minutes of inactivity. The host firewall will allow only incoming
Teredo traffic corresponding to the specific outbound request, ensuring
that system security isn’t compromised. This is really no different
than how any outbound-initiated traffic works with the host firewall
with IPv4. (In other words, all outbound traffic is allowed by default,
and a state table allows responses that match the outgoing requests.)
An
application or service is authorized to use Teredo with the advanced
Windows Firewall Edge Traversal flag. If an application has the Edge
Traversal option, it is allowed to receive any incoming traffic over
Teredo from any source (such as unsolicited traffic). Windows Meeting
Space and Remote Assistance automatically set this flag for themselves,
but users can do it manually for other Vista services if they would
like, such as with a Web service.
