The Cable Guy - November 2006

Link-Local Multicast Name Resolution

By The Cable Guy

Link-local Multicast Name Resolution (LLMNR) is a new protocol that provides an additional method to resolve the names of neighboring computers. LLMNR is especially useful for networks that do not have a Domain Name System (DNS) server. LLMNR uses a simple exchange of request and reply messages to resolve computer names to Internet Protocol version 6 (IPv6) or IP version 4 (IPv4) addresses. This article describes the implementation of LLMNR in Microsoft® Windows Vista and Windows Server® 2008.

Note

This article assumes knowledge of IPv4, IPv6, DNS protocol operation, and DNS client and server behavior.

Introduction

LLMNR is a protocol defined in RFC 4795 that allows both IPv6 and IPv4 hosts to perform name resolution for the names of neighboring computers without requiring a DNS server or DNS client configuration.

IPv4 hosts can use NetBIOS over TCP/IP (NetBT) to resolve computer names to IPv4 addresses for neighboring hosts by broadcasting a NetBIOS Name Query Request message to the local subnet broadcast address. The node that owns the queried name sends back a unicast NetBIOS Name Query Response message to the requestor and the name is resolved. However, NetBT only works over IPv4, not IPv6. Additionally, IT administrators can disable NetBT in an environment in which DNS is exclusively used for name resolution. With NetBT disabled on a network without DNS servers, you must add entries to the Hosts file to resolve names.

LLMNR allows name resolution on networks where a DNS server is not present or practical. A good example is the temporary subnet formed by a group of computers that form an ad hoc IEEE 802.11 wireless network. With LLMNR, hosts in the ad hoc wireless network can resolve each other computer names without having to configure one of the computers as a DNS server and the other computers with the IP address of the computer acting as the DNS server.

LLMNR messages use a similar format as DNS messages that are defined in RFC 1035 and use a different port than DNS messages. LLMNR Name Query Request messages in Windows Vista are sent to UDP port 5355. LLMNR Name Query Response messages are sent from UDP port 5355. The LLMNR resolver cache is separate from the DNS resolver cache.

Note

RFC 4795 also describes how LLMNR messages can be sent and received over TCP. However, TCP-based LLMNR messages are not supported in Windows Vista.

For LLMNR messages sent over IPv6, a querying host (a requestor) sends an LLMNR Name Query Request message to the link-local scope IPv6 multicast address of FF02::1:3. For LLMNR messages sent over IPv4, a querying host sends a LLMNR Name Query Request message to the IPv4 multicast address of 224.0.0.252. In both cases, the multicast address is scoped to prevent a multicast-enabled router from forwarding the query message beyond the subnet on which it was initially sent.

Note

RFC 4795 uses the term sender for the requesting host.

All IPv6-based LLMNR hosts listen on the IPv6 multicast address FF02::1:3 and instruct their Ethernet network adapters to listen for Ethernet frames with the destination multicast address of 33-33-00-01-00-03. All IPv4-based LLMNR hosts listen on the IPv4 multicast address 224.0.0.252 instruct their Ethernet network adapters to listen for Ethernet frames with the destination multicast address of 01-00-5E-00-00-FC.

The typical LLMNR message exchange for a name query consists of a multicast query and, if a host on the subnet is authoritative for the requested name, a unicast response to the requestor. Windows Vista-based LLMNR hosts neither send nor respond to unicast queries.

In contrast to DNS servers, LLMNR hosts are authoritative for specific names that have been assigned to them, rather than for a portion of the DNS namespace beginning at the assigned name. Using DNS terminology, LLMNR hosts are only authoritative for the zone apexes corresponding to their assigned names (the term zone is used loosely here because LLMNR hosts are not DNS servers that store zones). For example, an LLMNR node that has been assigned the name office.example.com is not also authoritative for all names that begin with office.example.com.

LLMNR Message Structure

As previously described, LLMNR uses a similar format as DNS messages. Figure 1 shows the format of LLMNR messages.

Figure 1: The LLMNR message format

Similar to DNS messages, LLMNR uses a 12-byte header and a series of sections containing zero or more question records, answer records, authority records, and additional records.

Figure 2 shows the structure of the LLMNR header.

Figure 2: The LLMNR header

Similar to DNS messages, LLMNR uses a 2-byte Transaction ID field to match queries with their responses, a 2-byte field for flags and indicators (described later in this article), and a series of 2-byte fields that indicate how many question records, answer records, authority records, and additional records are contained in the message past the LLMNR header.

A maximum-sized LLMNR message can be 65,527 bytes long (corresponding to the maximum size of a UDP message for IPv6) or 65,507 bytes long (corresponding to the maximum size of a UDP message for IPv4). LLMNR messages that exceed the maximum transmission unit (MTU) of the link are fragmented by the sending host.

Figure 3 shows the structure of the 2-byte field for flags and indicators in the LLMNR header.

Figure 3: The flags and indicators in the LLMNR header

Within these two bytes, the following fields and flags are defined for LLMNR:

• QR flag Similar to DNS, the Query/Response (QR) flag indicates whether the message is a query (QR=0) or a response (QR=1).

• Opcode field Similar to DNS, the 4-bit Operation Code (Opcode) field indicates the type of query. For LLMNR, the Opcode is set to 0 for both queries and responses.

• C flag The Conflict (C) flag indicates name conflicts. If a name is considered to be unique on the subnet, the responder sets the C flag to 0. If a requestor has previously received multiple responses for the name being queried, it sets the C flag to 1. Responders do not send a response to a query with the C flag set to 1, but potential responders that have previously determined the name to be unique need to verify that the names for which they are authoritative are unique.

• TC flag Similar to DNS, the Truncation (TC) flag is set to 1 only in a response to indicate that the message was truncated because it was larger than the maximum payload size allowed on the link. If a requestor receives a response with the TC flag set to 1, it can send a new TCP-based request message to the unicast address of the responder. Because LLMNR messages have such a large maximum size, LLMNR in Windows Vista never sets the TC flag in queries or responses.

• T flag The Tentative (T) flag is set to 1 in a response if the responder is authoritative for the name but has not verified the name's uniqueness.

• RCODE field Similar to DNS, the 4-bit Return Code (RCODE) field indicates the success of the response. For LLMNR, the RCODE field is set to 0 by requestors and responders. Unlike DNS servers, LLMNR responders that are not authoritative for a queried name do not respond to the query with an RCODE set to 3, indicating that the name was not found. LLMNR responders that are not authoritative for the queried name send no response. The requestor interprets the lack of a response to a query in the same way as a DNS client that receives a name query response from a DNS server with an RCODE set to 3.

Windows Vista supports 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.

LLMNR query messages sent over IPv4 use the following fields in the IPv4 header:

• The Destination Address field is set to 224.0.0.252.

• The Source Address field is set to a unicast IPv4 address of the sending interface.

• The Time-to-Live (TTL) field is set to 1.

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

Host Startup and Name Resolution Processes

When a host running Windows Vista starts, it 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, Windows Vista will convert the hostname.local name to hostname and use LLMNR to attempt to resolve the single-label name. A Windows Vista-based computer is not also authoritative for the computername.local name.

When a single-label, unqualified name needs to be resolved, a computer running 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 Vista performs 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 (for example, the DNS server returns an RCODE=3), 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 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.

For More Information

For more information about TCP/IP enhancements in Windows Vista, consult the following resources:

• Next Generation TCP/IP Stack Web site

• Microsoft IPv6 Web site

For a list of all The Cable Guy articles, click here.