226 Understanding IPv6, Second Edition

Based on this default prefix policy table, computers running Windows Server 2008 or Windows Vista prefer the use of IPv6 addresses over IPv4 addresses, and therefore prefer IPv6 traffic over IPv4 traffic. The entry that matches all IPv6 addresses (with the prefix ::/0) has a higher precedence than the entry that matches all IPv4 addresses (with the prefix ::ffff:0:0/ 96 for IPv4-mapped addresses).

You can manage the prefix policy table in the following ways:

■Add entries with the netsh interface ipv6 add prefixpolicy command.

■Modify existing entries with the netsh interface ipv6 set prefixpolicy command.

■Remove entries with netsh interface ipv6 delete prefixpolicy command.

LLMNR Support

Windows Server 2008 and Windows Vista support LLMNR for both IPv4 and IPv6. LLMNR query messages sent over IPv6 use the following fields in the IPv6 header:

■The Destination Address field is set to FF02::1:3.

■The Source Address field is set to a link-local or other unicast address of the sending interface.

■The Hop Limit field is set to 1.

For LLMNR queries, a requestor sets the UDP Destination Port field to 5355 and the UDP Source Port field to a dynamically allocated port number. For LLMNR responses, the responder sets the UDP Destination Port field to the dynamically allocated port of the matching query and the UDP Source Port field to 5355.

When a host running Windows Server 2008 or Windows Vista starts, the DNS Client service verifies name uniqueness by sending LLMNR Name Query Request messages for its authoritative name, which is its computer name as a single-label name.

For example, a computer named client1 with the primary DNS suffix of wcoast.example.com is authoritative for LLMNR for the name client1, but not also authoritative for client1. wcoast.example.com. If there is a response to any of the initial requests for its own name with the C flag set to 0, there is a name conflict. The LLMNR host notes the conflict and does not respond to LLMNR requests for its name. However, the host that detected the conflict sends a new query for its name every 15 minutes to determine if the computer with the conflicting name is no longer on the link. If there are no responses to a subsequent query for its own name, the host begins responding to queries.

As a convenience to users who are accustomed to querying names of the form hostname.local, the LLMNR component in Windows Server 2008 and Windows Vista will convert the hostname.local name to hostname and use LLMNR to attempt to resolve the single-label name.

A computer running Windows Server 2008 or Windows Vista is not also authoritative for the hostname.local name.

When a single-label, unqualified name needs to be resolved, a computer running Windows Server 2008 or Windows Vista that is using both IPv6 and IPv4 (the default configuration) will do the following:

1.Perform normal DNS resolution by combining the single-label name with the primary DNS suffix of the computer and sending a DNS Name Query Request message to

its DNS server. Windows Server 2008 and Windows Vista perform additional DNS queries as needed based on name devolution or additional search suffixes that have been configured.

2.If DNS name resolution is not successful, send up to two sets of multicast LLMNR Name Query Request messages over both IPv6 and IPv4.

3.If LLMNR name resolution is not successful and NetBT is enabled, broadcast up to three NetBIOS Name Query Request messages.

If the name being resolved is not a single-label name (or a hostname.local name), LLMNR and NetBT are not used. Notice that LLMNR is used regardless of whether the host has been configured to use a DNS server. This allows a computer running Windows Server 2008 or Windows Vista to resolve the computer names of neighboring LLMNR hosts that do not have corresponding address records stored in DNS.

Neighboring LLMNR hosts that receive the LLMNR Name Query Request message check to see if they are authoritative for the name in the Question section of the message. If authoritative, the LLMNR host constructs and sends a unicast LLMNR Name Query Response message containing the original Question section and an Answer section containing one or more IP addresses that can be used to reach the responder. The responder must include only those addresses that are reachable to the requestor. For example, the addresses must be assigned to the interface that received the query.

Support for ipv6-literal.net Names

Windows Server 2008 and Windows Vista support the use of IPv6Address.ipv6-literal.net names. The IPv6Address.ipv6-literal.net name resolves to IPv6Address. To specify an IPv6 address within the ipv6-literal.net name, convert the colons (:) in the address to dashes (-). For example, for the IPv6 address 2001:db8:28:3:f98a:5b31:67b7:67ef, the corresponding ipv6-literal.net name is 2001-db8-28-3-f98a-5b31-67b7-67ef.ipv6-literal.net. When submitted by an application for name resolution, the 2001-db8-28-3-f98a-5b31-67b7-67ef.ipv6-literal.net name resolves to 2001:db8:28:3:f98a:5b31:67b7:67ef.

The IPv6 address in the name can be global, unique local, or link local (with or without a zone ID). To specify a zone ID (also known as a scope ID), replace the “%” used to separate the IPv6 address from the zone ID with an “s”. For example, to specify the destination fe80::218:8bff:fe17:a226%4, the name is fe80--218-8bff-fe17-a226s4.ipv6-literal.net.

228 Understanding IPv6, Second Edition

An ipv6-literal.net name can be used in services or applications that do not recognize the syntax of normal IPv6 addresses. It is always preferable to use a DNS name that corresponds to a destination, such as filesrv1.example.com. However, the ipv6-literal.net name can be used for connectivity when the DNS name for the destination is not registered and the IPv6 address is known.

You can use an ipv6-literal.net name in the computer name part of a Universal Naming Convention (UNC) path. For example, to specify the Docs share of the computer with the IPv6 address of 2001:db8:28:3:f98a:5b31:67b7:67ef, use the UNC path \\2001-db8-28-3- f98a-5b31-67b7-67ef.ipv6-literal.net\docs. The ipv6-literal.net name is an alias for the name of the file server. See Knowledge Base article 281308 at http://support.microsoft.com/ default.aspx?scid=kb;en-us;281308 for information about how to configure a Windows-based file server to accept alias names in a UNC.

Peer Name Resolution Protocol

In peer-to-peer environments, peers rely on name resolution systems to resolve each other’s network locations (addresses, protocols, and ports) from names or other types of identifiers. Peer-to-peer name resolution has been complicated by transient connectivity and shortcomings in DNS.

The Windows Peer-to-Peer Networking platform built into Windows Server 2008 and Windows Vista solves this problem with the Peer Name Resolution Protocol (PNRP), a secure, scalable, and dynamic name-registration and name-resolution protocol. PNRP has the following properties:

■Real time updates DNS relies heavily on caching to improve performance. Unfortunately, this means names cannot be reliably updated in real time. PNRP is much more efficient than DNS and can process updates almost instantaneously. Name resolutions will never return stale addresses, making PNRP an excellent solution for finding mobile users.

■Name more than just computers A PNRP resolution includes an address, port, and possibly an extended payload. With PNRP, you can name more than just computers. You can also name services.

■Protected name publication Names can be published as secured (protected) or unsecured (unprotected) with PNRP. PNRP uses public key cryptography to protect secure peer names against spoofing.