Chapter 9
IPv6 and Name Resolution
At the end of this chapter, you should be able to do the following:
■Describe the Domain Name System (DNS) support for IPv6 name-to-address and address-to-name resolution.
■Describe the Link-Local Multicast Name Resolution Protocol (LLMNR).
■Describe source and destination address selection.
■Describethename resolution support for IPv6provided byWindowsServer2008and Windows Vista.
Name Resolution for IPv6
For Internet Protocol version 6 (IPv6), it is more important than ever that names, rather than addresses, be used to reference network resources. With IPv4, it is hard enough to remember an IPv4 address as a series of four decimal numbers. An IPv6 address can have up to 32 hexadecimal digits. It is unreasonable to expect end users to remember or reliably type an IPv6 address when attempting to access a resource. Additionally, with a mixture of both IPv4 and IPv6 addresses, specifying a name allows the operating system to choose the best set
of addresses with which to communicate. Therefore, name resolution support for IPv6 addresses is a critically important part of an IPv6 deployment.
Two protocols for providing name resolution support for IPv6 are DNS and LLMNR.
DNS Enhancements for IPv6
RFC 1886 defines a new DNS resource record type, AAAA (also known as “quad A”), for resolving a fully qualified domain name to an IPv6 address. AAAA records are comparable to the host address (A) resource records used for IPv4 name resolution and use the DNS record type of 28. The resource record type is named AAAA because 128-bit IPv6 addresses are four times longer than 32-bit IPv4 addresses.
The AAAA resource record in a typical DNS database file has the following structure:
Name IN AAAA Address
Name is the fully qualified domain name, and Address is the IPv6 address associated with the name. The following is an example of an AAAA resource record:
host1.microsoft.com IN AAAA 2001:DB8::1:DD48:AB34:D07C:3914
209
210 Understanding IPv6, Second Edition
To receive IPv6 address resolution data in the DNS query answer sections of the DNS query response, a host must specify either an AAAA query (by setting the Question Type field in a DNS query question entry to 0x1C, or 28 in decimal) or a query of type Any (by setting the Question Type field in a DNS query question entry to 0xFF, or 255 in decimal).
The IP6.ARPA domain has been created for IPv6 reverse queries. Also called pointer queries, reverse queries determine a host name based on the address. To create the namespace for reverse queries, each hexadecimal digit in the fully expressed 32-digit IPv6 address becomes a separate level in the reverse domain hierarchy in inverse order.
For example, the reverse lookup domain name for the address 2001:DB8::1:DD48:AB34:D07C:3914 (fully expressed as 2001:0DB8:0000:0001:DD48:AB34:D07C:3914) is 4.1.9.3.C.7.0.D.4.3.B.A.8.4.D.D.1.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
An example pointer (PTR) record is the following (folded for readability):
4.1.9.3.C.7.0.D.4.3.B.A.8.4.D.D.1.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. IN PTR host1.microsoft.com
The DNS support for IPv6 is a simple way to both map host names to IPv6 addresses and provide reverse name resolution. It is a direct translation of IPv4 name and reverse name resolution techniques to IPv6.
LLMNR
LLMNR is a new protocol defined in RFC 4795 that provides an additional method to resolve the names of neighboring computers for networks that do not have a DNS server. LLMNR allows both IPv6 and IPv4 hosts to perform name resolution for the computer names of neighboring computers with a simple exchange of request and reply messages 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 subnet broadcast IPv4 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 resolves IPv4 addresses, not IPv6 addresses. Additionally, network 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’s computer names without having to configure one of the computers as a DNS server and the other computers with the IPv4 or IPv6 address of the computer acting as the DNS server.
Chapter 9 IPv6 and Name Resolution |
211 |
LLMNR messages use a similar format as DNS messages that are defined in RFC 1035, and they use a different port than DNS messages. LLMNR hosts send LLMNR Name Query Request messages to UDP port 5355, and they send LLMNR Name Query Response messages 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 Server 2008 or 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. All IPv6based LLMNR hosts listen on the IPv6 multicast address FF02::1:3, and they instruct their Ethernet network adapters to listen for Ethernet frames with the destination multicast address of 33-33-00-01-00-03.
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 Server 2008 and 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 authoritative only 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 end with office.example.com.
LLMNR Message Structure
LLMNR uses a similar format as DNS messages, which Figure 9-1 shows.
LLMNR Header
(12 Bytes)
Question Records
(Variable Size)
Answer Records
(Variable Size)
Authority Records
(Variable Size)
Additional Records
(Variable Size)
Figure 9-1 The LLMNR message format
212 Understanding IPv6, Second Edition
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 9-2 shows the structure of the LLMNR header.
Transaction ID |
Flags and Fields |
Question Count |
Answer Count |
Authority Count
Additional Records Count 
Figure 9-2 The LLMNR header
Similar to DNS messages, LLMNR uses a 2-byte Transaction Identifier (ID) field to match queries with their responses, a 2-byte field for flags and indicators (described later in this chapter), 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 9-3 shows the structure of the 2-byte field for flags and indicators in the LLMNR header.
|
|
Opcode |
|
|
|
Reserved |
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
QR |
|
|
|
|
C |
TC |
T |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Response Code
Figure 9-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