draft-ietf-dnsext-mdns-38.txt   draft-ietf-dnsext-mdns-39.txt 
DNSEXT Working Group Levon Esibov DNSEXT Working Group Bernard Aboba
INTERNET-DRAFT Bernard Aboba INTERNET-DRAFT Dave Thaler
Category: Standards Track Dave Thaler Category: Standards Track Levon Esibov
<draft-ietf-dnsext-mdns-38.txt> Microsoft <draft-ietf-dnsext-mdns-39.txt> Microsoft
19 February 2005 19 March 2005
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2005. This Internet-Draft will expire on September 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2005. All rights reserved. Copyright (C) The Internet Society 2005. All rights reserved.
Abstract Abstract
Today, with the rise of home networking, there are an increasing Today, with the rise of home networking, there are an increasing
number of ad-hoc networks operating without a Domain Name System number of ad-hoc networks operating without a Domain Name System
(DNS) server. The goal of Link-Local Multicast Name Resolution (DNS) server. The goal of Link-Local Multicast Name Resolution
skipping to change at page 2, line 12 skipping to change at page 2, line 12
LLMNR only operates on the local link, it cannot be considered a LLMNR only operates on the local link, it cannot be considered a
substitute for DNS. substitute for DNS.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements .................................... 3 1.1 Requirements .................................... 3
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
2. Name resolution using LLMNR ........................... 4 2. Name resolution using LLMNR ........................... 4
2.1 LLMNR packet format ............................. 6 2.1 LLMNR packet format ............................. 6
2.2 Sender behavior ................................. 8 2.2 Sender behavior ................................. 9
2.3 Responder behavior .............................. 9 2.3 Responder behavior .............................. 9
2.4 Unicast queries ................................. 11 2.4 Unicast queries ................................. 12
2.5 Off-link detection .............................. 12 2.5 Off-link detection .............................. 12
2.6 Responder responsibilities ...................... 13 2.6 Responder responsibilities ...................... 13
2.7 Retransmission and jitter ....................... 13 2.7 Retransmission and jitter ....................... 14
2.8 DNS TTL ......................................... 14 2.8 DNS TTL ......................................... 15
2.9 Use of the authority and additional sections .... 14 2.9 Use of the authority and additional sections .... 15
3. Usage model ........................................... 15 3. Usage model ........................................... 15
3.1 LLMNR configuration ............................. 16 3.1 LLMNR configuration ............................. 16
4. Conflict resolution ................................... 17 4. Conflict Resolution ................................... 18
4.1 Uniqueness Verification ......................... 18 4.1 Uniqueness Verification ......................... 18
4.2 Conflict Detection and Defense .................. 18 4.2 Ongoing Conflict Detection ...................... 19
4.3 Considerations for multiple interfaces .......... 20 4.3 Considerations for multiple interfaces .......... 20
4.4 API issues ...................................... 21 4.4 API issues ...................................... 21
5. Security considerations ............................... 21 5. Security considerations ............................... 22
5.1 Scope restriction ............................... 22 5.1 Scope restriction ............................... 22
5.2 Usage restriction ............................... 23 5.2 Usage restriction ............................... 23
5.3 Cache and port separation ....................... 23 5.3 Cache and port separation ....................... 24
5.4 Authentication .................................. 24 5.4 Authentication .................................. 24
6. IANA considerations ................................... 24 6. IANA considerations ................................... 24
7. Constants ............................................. 24 7. Constants ............................................. 25
8. References ............................................ 24 8. References ............................................ 25
8.1 Normative References ............................ 24 8.1 Normative References ............................ 25
8.2 Informative References .......................... 25 8.2 Informative References .......................... 26
Acknowledgments .............................................. 26 Acknowledgments .............................................. 27
Authors' Addresses ........................................... 27 Authors' Addresses ........................................... 27
Intellectual Property Statement .............................. 27 Intellectual Property Statement .............................. 28
Disclaimer of Validity ....................................... 28 Disclaimer of Validity ....................................... 28
Copyright Statement .......................................... 28 Copyright Statement .......................................... 28
1. Introduction 1. Introduction
This document discusses Link Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
which utilizes the DNS packet format and supports all current and which utilizes the DNS packet format and supports all current and
future DNS formats, types and classes. LLMNR operates on a separate future DNS formats, types and classes. LLMNR operates on a separate
port from the Domain Name System (DNS), with a distinct resolver port from the Domain Name System (DNS), with a distinct resolver
cache. cache.
skipping to change at page 4, line 33 skipping to change at page 4, line 33
that address sent over the link. that address sent over the link.
Responder Responder
A host that listens to LLMNR queries, and responds to those for A host that listens to LLMNR queries, and responds to those for
which it is authoritative. which it is authoritative.
Sender Sender
A host that sends an LLMNR query. A host that sends an LLMNR query.
UNIQUE UNIQUE
There are some scenarios when multiple responders may respond to There are some scenarios when multiple responders may respond to a
the same query. There are other scenarios when only one responder query. There are other scenarios when only one responder may
may respond to a query. Resource records for which only a single respond to a query. A responder considers a name to be UNIQUE if
responder is anticipated are referred to as UNIQUE. Resource multiple responses are not expected in response to a query for a
record uniqueness is configured on the responder, and therefore name, regardless of the type and class.
uniqueness verification is the responder's responsibility.
2. Name resolution using LLMNR 2. Name resolution using LLMNR
LLMNR is a peer-to-peer name resolution protocol that is not intended LLMNR is a peer-to-peer name resolution protocol that is not intended
as a replacement for DNS. LLMNR queries are sent to and received on as a replacement for DNS. LLMNR queries are sent to and received on
port 5355. IPv4 administratively scoped multicast usage is specified port 5355. IPv4 administratively scoped multicast usage is specified
in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link- in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-
scope multicast address a given responder listens to, and to which a scope multicast address a given responder listens to, and to which a
sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast
address a given responder listens to, and to which a sender sends all address a given responder listens to, and to which a sender sends all
skipping to change at page 5, line 13 skipping to change at page 5, line 12
Typically a host is configured as both an LLMNR sender and a Typically a host is configured as both an LLMNR sender and a
responder. A host MAY be configured as a sender, but not a responder. A host MAY be configured as a sender, but not a
responder. However, a host configured as a responder MUST act as a responder. However, a host configured as a responder MUST act as a
sender to verify the uniqueness of names as described in Section 4. sender to verify the uniqueness of names as described in Section 4.
This document does not specify how names are chosen or configured. This document does not specify how names are chosen or configured.
This may occur via any mechanism, including DHCPv4 [RFC2131] or This may occur via any mechanism, including DHCPv4 [RFC2131] or
DHCPv6 [RFC3315]. DHCPv6 [RFC3315].
LLMNR usage MAY be configured manually or automatically on a per LLMNR usage MAY be configured manually or automatically on a per
interface basis. By default, LLMNR responders SHOULD be enabled on interface basis. By default, LLMNR responders SHOULD be enabled on
all interfaces, at all times. Enabling LLMNR for use in situations all interfaces over all protocols that the host supports, at all
where a DNS server has been configured will result in a change in times. Enabling LLMNR for use in situations where a DNS server has
default behavior without a simultaneous update to configuration been configured will result in a change in default behavior without a
information. Where this is considered undesirable, LLMNR SHOULD NOT simultaneous update to configuration information. Where this is
be enabled by default, so that hosts will neither listen on the link- considered undesirable, LLMNR SHOULD NOT be enabled by default, so
scope multicast address, nor will they send queries to that address. that hosts will neither listen on the link-scope multicast address,
nor will they send queries to that address.
An LLMNR sender may send a request for any name. However, by An LLMNR sender may send a request for any name. However, by
default, LLMNR requests SHOULD be sent only when one of the following default, LLMNR requests SHOULD be sent only when one of the following
conditions are met: conditions are met:
[1] No manual or automatic DNS configuration has been [1] No manual or automatic DNS configuration has been
performed. If DNS server address(es) have been performed. If DNS server address(es) have been
configured, then LLMNR SHOULD NOT be used as the configured, then LLMNR SHOULD NOT be used as the
primary name resolution mechanism, although it MAY primary name resolution mechanism, although it MAY
be used as a secondary name resolution mechanism. be used as a secondary name resolution mechanism.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
2.1.1. LLMNR header format 2.1.1. LLMNR header format
LLMNR queries and responses utilize the DNS header format defined in LLMNR queries and responses utilize the DNS header format defined in
[RFC1035] with exceptions noted below: [RFC1035] with exceptions noted below:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | | ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode | Z|TC| U| C| Z| Z| Z| RCODE | |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT | | QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT | | ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT | | NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | | ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where: where:
ID A 16 bit identifier assigned by the program that generates any kind ID A 16 bit identifier assigned by the program that generates any kind
of query. This identifier is copied from the query to the response of query. This identifier is copied from the query to the response
and can be used by the sender to match responses to outstanding and can be used by the sender to match responses to outstanding
queries. The ID field in a query SHOULD be set to a pseudo-random queries. The ID field in a query SHOULD be set to a pseudo-random
value. For advice on generation of pseudo-random values, please value. For advice on generation of pseudo-random values, please
consult [RFC1750]. consult [RFC1750].
QR A one bit field that specifies whether this message is an LLMNR QR Query/Response. A one bit field, which if set indicates that the
query (0), or an LLMNR response (1). message is an LLMNR response; if clear then the message is an LLMNR
query.
OPCODE OPCODE
A four bit field that specifies the kind of query in this message. A four bit field that specifies the kind of query in this message.
This value is set by the originator of a query and copied into the This value is set by the originator of a query and copied into the
response. This specification defines the behavior of standard response. This specification defines the behavior of standard
queries and responses (opcode value of zero). Future queries and responses (opcode value of zero). Future
specifications may define the use of other opcodes with LLMNR. specifications may define the use of other opcodes with LLMNR.
LLMNR senders and responders MUST support standard queries (opcode LLMNR senders and responders MUST support standard queries (opcode
value of zero). LLMNR queries with unsupported OPCODE values MUST value of zero). LLMNR queries with unsupported OPCODE values MUST
be silently discarded by responders. be silently discarded by responders.
C Conflict. When set within a request, the 'C'onflict bit indicates
that a sender has received multiple LLMNR responses to this query
with the 'T' bit clear. In an LLMNR response, the 'C' bit is clear
if the responder considers the name in the query to be UNIQUE;
otherwise the 'C' bit is set. LLMNR senders do not retransmit
queries with the 'C' bit set. When receiving an LLMNR query with
the 'C' bit set, an LLMNR responder MUST NOT respond, but will
attempt to verify the conflict, as described in Section 4.2.
TC TrunCation - specifies that this message was truncated due to TC TrunCation - specifies that this message was truncated due to
length greater than that permitted on the transmission channel. length greater than that permitted on the transmission channel.
The TC bit MUST NOT be set in an LLMNR query and if set is ignored The TC bit MUST NOT be set in an LLMNR query and if set is ignored
by an LLMNR responder. If the TC bit is set in an LLMNR response, by an LLMNR responder. If the TC bit is set in an LLMNR response,
then the sender SHOULD discard the response and resend the LLMNR then the sender SHOULD discard the response and resend the LLMNR
query over TCP using the unicast address of the responder as the query over TCP using the unicast address of the responder as the
destination address. See [RFC2181] and Section 2.4 of this destination address. See [RFC2181] and Section 2.4 of this
specification for further discussion of the TC bit. specification for further discussion of the TC bit.
U UNIQUE - specifies that this message is a UNIQUEness query. The U T Tentative. The 'T'entative bit is set in a response if the
bit MUST NOT be set in an LLMNR response, and if set is ignored by responder is authoritative for the name, but has not yet verified
an LLMNR sender. If the U bit is set in an LLMNR query, this the uniqueness of the name. A sender receiving a response with the
indicates that the sender believes that it is authoritative for the 'T' bit set MUST silently discard the response unless it is
name. See Section 4.1 and 4.2 for discussion of name conflict received in response to a uniqueness query. A responder MUST
detection. ignore the 'T' bit in a query, if set. When a response with the
'T' bit set is received in response to a uniqueness query, a
C Conflict - specifies that a sender has previously received multiple conflict has been detected and a responder MUST resolve the
LLMNR responses to this query. The C bit MUST NOT be set in an conflict. Use of the 'T' bit is described in more detail in
LLMNR response, and if set is ignored by an LLMNR sender. Sections 4.1 and 4.2.
Responders do not respond to LLMNR queries with the 'C' bit set;
since no response is expected, LLMNR senders do not retransmit.
Z Reserved for future use. Implementations of this specification Z Reserved for future use. Implementations of this specification
MUST set these bits to zero in both queries and responses. If MUST set these bits to zero in both queries and responses. If
these bits are set in a LLMNR query or response, implementations of these bits are set in a LLMNR query or response, implementations of
this specification MUST ignore them. Since reserved bits could this specification MUST ignore them. Since reserved bits could
conceivably be used for different purposes than in DNS, conceivably be used for different purposes than in DNS,
implementors are advised not to enable processing of these bits in implementors are advised not to enable processing of these bits in
an LLMNR implementation starting from a DNS code base. an LLMNR implementation starting from a DNS code base.
RCODE RCODE
skipping to change at page 9, line 6 skipping to change at page 9, line 17
A sender may send an LLMNR query for any legal resource record type A sender may send an LLMNR query for any legal resource record type
(e.g., A, AAAA, SRV, etc.) to the link-scope multicast address. (e.g., A, AAAA, SRV, etc.) to the link-scope multicast address.
As described in Section 2.4, a sender may also send a unicast query. As described in Section 2.4, a sender may also send a unicast query.
Sections 2 and 3 describe the circumstances in which LLMNR queries Sections 2 and 3 describe the circumstances in which LLMNR queries
may be sent. may be sent.
The sender MUST anticipate receiving no replies to some LLMNR The sender MUST anticipate receiving no replies to some LLMNR
queries, in the event that no responders are available within the queries, in the event that no responders are available within the
link-scope or in the event no positive non-null responses exist for link-scope or in the event no positive non-null responses exist for
the transmitted query. If no positive response is received, a the transmitted query. If no positive response is received to a
resolver treats it as a response that no records of the specified query other than a uniqueness query, a resolver treats it as a
type and class exist for the specified name (it is treated the same response that no records of the specified type and class exist for
as a response with RCODE=0 and an empty answer section). the specified name (it is treated the same as a response with RCODE=0
and an empty answer section).
Since the responder may order the RRs in the response so as to Since the responder may order the RRs in the response so as to
indicate preference, the sender SHOULD preserve ordering in the indicate preference, the sender SHOULD preserve ordering in the
response to the querying application. response to the querying application.
The sender MUST anticipate receiving multiple replies to the same The sender MUST anticipate receiving multiple replies to the same
LLMNR query, in the event that several LLMNR enabled computers LLMNR query, in the event that several LLMNR responders receive the
receive the query and respond with valid answers. When multiple query and respond with valid answers. When multiple valid answers
valid answers are received, they may first be concatenated, and then with the 'T' bit clear are received in response to a query they are
treated in the same manner that multiple RRs received from the same treated as follows:
DNS server would; the sender perceives no inherent conflict in the
receipt of multiple responses. [1] If the responses have the 'C' bit set, the responses are
concatenated and then treated in the same manner that multiple RRs
received from the same DNS server would.
[2] If one or more of the responses have the 'C' bit clear, a conflict
has been detected. The responses are concatenated, but are not
cached. A query for the same name, type and class is sent, with
the 'C' bit set. Conflict detection and resolution is described in
more detail in Section 4.2.
2.3. Responder behavior 2.3. Responder behavior
An LLMNR response MUST be sent to the sender via unicast. An LLMNR response MUST be sent to the sender via unicast.
Upon configuring an IP address, responders typically will synthesize Upon configuring an IP address, responders typically will synthesize
corresponding A, AAAA and PTR RRs so as to be able to respond to corresponding A, AAAA and PTR RRs so as to be able to respond to
LLMNR queries for these RRs. An SOA RR is synthesized only when a LLMNR queries for these RRs. An SOA RR is synthesized only when a
responder has another RR as well; the SOA RR MUST NOT be the only RR responder has another RR as well; the SOA RR MUST NOT be the only RR
that a responder has. However, in general whether RRs are manually that a responder has. However, in general whether RRs are manually
skipping to change at page 13, line 24 skipping to change at page 13, line 43
that address MUST be valid on the local link over which that address MUST be valid on the local link over which
LLMNR is used. LLMNR is used.
[b] If an IPv4 address is returned, it MUST be reachable [b] If an IPv4 address is returned, it MUST be reachable
through the link over which LLMNR is used. through the link over which LLMNR is used.
[c] If a name is returned (for example in a CNAME, MX [c] If a name is returned (for example in a CNAME, MX
or SRV RR), the name MUST be resolvable on the local or SRV RR), the name MUST be resolvable on the local
link over which LLMNR is used. link over which LLMNR is used.
[d] When LLMNR is implemented on a dual stack host, LLMNR SHOULD
be supported on both IPv4 and IPv6. An implementation only
supporting LLMNR over IPv6 SHOULD NOT return IPv4 addresses;
an implementation only supporting LLMNR over IPv4 SHOULD NOT
return IPv6 addresses.
Where multiple addresses represent valid responses to a query, the Where multiple addresses represent valid responses to a query, the
order in which the addresses are returned is as follows: order in which the addresses are returned is as follows:
[d] If the source address of the query is a link-scope address, [e] If the source address of the query is a link-scope address,
then the responder SHOULD include a link-scope address first then the responder SHOULD include a link-scope address first
in the response, if available. in the response, if available.
[e] If the source address of the query is a routable address, [f] If the source address of the query is a routable address,
then the responder MUST include a routable address first then the responder MUST include a routable address first
in the response, if available. in the response, if available.
2.7. Retransmission and jitter 2.7. Retransmission and jitter
An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
when to retransmit an LLMNR query and how long to collect responses when to retransmit an LLMNR query and how long to collect responses
to an LLMNR query. to an LLMNR query.
If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
then a sender SHOULD repeat the transmission of the query in order to then a sender SHOULD repeat the transmission of the query in order to
assure that it was received by a host capable of responding to it. assure that it was received by a host capable of responding to it.
Retransmission of UDP queries SHOULD NOT be attempted more than 3 Retransmission of UDP queries SHOULD NOT be attempted more than 3
times. Where LLMNR queries are sent using TCP, retransmission is times. Where LLMNR queries are sent using TCP, retransmission is
handled by the transport layer. Queries with the 'C' bit set MUST be handled by the transport layer. Queries with the 'C' bit set MUST be
sent over UDP and MUST NOT be retransmitted. sent over multicast UDP and MUST NOT be retransmitted.
Because an LLMNR sender cannot know in advance if a query sent using Because an LLMNR sender cannot know in advance if a query sent using
multicast will receive no response, one response, or more than one multicast will receive no response, one response, or more than one
response, the sender SHOULD wait for LLMNR_TIMEOUT in order to response, the sender SHOULD wait for LLMNR_TIMEOUT in order to
collect all possible responses, rather than considering the multicast collect all possible responses, rather than considering the multicast
query answered after the first response is received. A unicast query query answered after the first response is received. A unicast query
sender considers the query answered after the first response is sender considers the query answered after the first response is
received, so that it only waits for LLMNR_TIMEOUT if no response has received, so that it only waits for LLMNR_TIMEOUT if no response has
been received. been received.
skipping to change at page 17, line 31 skipping to change at page 18, line 8
An outage in the DNS configuration mechanism may result in hosts An outage in the DNS configuration mechanism may result in hosts
continuing to use LLMNR even once the outage is repaired. Since continuing to use LLMNR even once the outage is repaired. Since
LLMNR only enables linklocal name resolution, this represents a LLMNR only enables linklocal name resolution, this represents a
degradation in capabilities. As a result, hosts without a configured degradation in capabilities. As a result, hosts without a configured
DNS server may wish to periodically attempt to obtain DNS DNS server may wish to periodically attempt to obtain DNS
configuration if permitted by the configuration mechanism in use. In configuration if permitted by the configuration mechanism in use. In
the absence of other guidance, a default retry interval of one (1) the absence of other guidance, a default retry interval of one (1)
minute is RECOMMENDED. minute is RECOMMENDED.
4. Conflict resolution 4. Conflict Resolution
The uniqueness of a resource record depends on the nature of the name
in the query and type of the query. For example it is expected that:
- multiple hosts may respond to a query for an SRV type record A responder considers a name to be UNIQUE if multiple responses are
- multiple hosts may respond to a query for an A or AAAA type not expected in response to a query for that name, regardless of the
record for a cluster name (assigned to multiple hosts in type and class. By default, a responder SHOULD be configured to
the cluster) behave as though its names are UNIQUE on each interface on which
- only a single host may respond to a query for an A or AAAA LLMNR is enabled.
type record for a name.
By default, a responder SHOULD be configured to behave as though all When responding to a query for a UNIQUE name, the 'C' bit is clear in
RRs are UNIQUE on each interface on which LLMNR is enabled. the response. Where the name in the query is not UNIQUE, an LLMNR
responder sets the 'C' bit in the response. For example, where
multiple responders may respond to a query for an A or AAAA type
record for a cluster name (assigned to multiple hosts in the
cluster), the 'C' bit is set in the response, regardless of the type
and class of the query.
When name conflicts are detected, they SHOULD be logged. To detect To detect duplicate use of a name, an administrator can use a name
duplicate use of a name, an administrator can use a name resolution resolution utility which employs LLMNR and lists both responses and
utility which employs LLMNR and lists both responses and responders. responders. This would allow an administrator to diagnose behavior
This would allow an administrator to diagnose behavior and and potentially to intervene and reconfigure LLMNR responders who
potentially to intervene and reconfigure LLMNR responders who should should not be configured to respond to the same name.
not be configured to respond to the same name.
4.1. Uniqueness Verification 4.1. Uniqueness Verification
Prior to including a UNIQUE resource record in a response, for each Before responding with the 'T' bit clear to a query for a UNIQUE
UNIQUE resource record in a given interface's configuration, the host name, a responder MUST verify that there is no other host within the
MUST verify that there is no other host within the scope of LLMNR scope of LLMNR query propagation using the same name on that
query propagation that can return a resource record for the same interface.
name, type and class on that interface.
Once a responder has verified the uniqueness of a UNIQUE resource Prior to verifying uniqueness of a name, a responder MUST set the 'T'
record, if it receives an LLMNR query for that resource record, with bit in responses to queries for that name. Once a responder has
the 'C' bit clear, it MUST respond. verified the uniqueness of a name, if it receives an LLMNR query for
that name with the 'C' bit clear, it MUST respond, with the 'T' and
'C' bits clear.
Uniqueness verification is carried out when the host: Uniqueness verification is carried out when the host:
- starts up or is rebooted - starts up or is rebooted
- wakes from sleep (if the network interface was inactive - wakes from sleep (if the network interface was inactive
during sleep) during sleep)
- is configured to respond to LLMNR queries on an interface - is configured to respond to LLMNR queries on an interface
enabled for transmission and reception of IP traffic enabled for transmission and reception of IP traffic
- is configured to respond to LLMNR queries using additional - is configured to respond to LLMNR queries using additional
UNIQUE resource records UNIQUE resource records
- verifies the acquisition of a new IP address and configuration - verifies the acquisition of a new IP address and configuration
on an interface on an interface
To verify uniqueness, a responder MUST send an LLMNR query with the To verify uniqueness of a name, a responder MUST send an LLMNR query
'U' bit set for each UNIQUE resource record. If no response is for the name with the 'C' bit clear over all protocols on which it
received, the sender retransmits the query, as specified in Section responds to LLMNR queries (IPv4 and/or IPv6). Any query type will
2.7. If a response is received, the responder MUST NOT use the UNIQUE do, including 'ANY'.
resource record in response to LLMNR queries.
If no response is received, the sender retransmits the query, as
specified in Section 2.7. If a response is received with the 'T' bit
clear, the responder MUST NOT use the name in response to LLMNR
queries received over any protocol (IPv4 or IPv6). If a response is
received with the 'T' bit set, the responder MUST check if the source
IP address in the response, interpreted as an unsigned integer, is
less than the source IP address in the query. If so, the responder
MUST NOT use the name in response to LLMNR queries received over any
protocol (IPv4 or IPv6). For the purpose of uniqueness verification,
the contents of the answer section in a response is irrelevant.
Periodically carrying out uniqueness verification in an attempt to Periodically carrying out uniqueness verification in an attempt to
detect name conflicts is not necessary, wastes network bandwidth, and detect name conflicts is not necessary, wastes network bandwidth, and
may actually be detrimental. For example, if network links are may actually be detrimental. For example, if network links are
joined only briefly, and are separated again before any new joined only briefly, and are separated again before any new
communication is initiated, temporary conflicts are benign and no communication is initiated, temporary conflicts are benign and no
forced reconfiguration is required. Triggering a reconfiguration in forced reconfiguration is required. LLMNR responders SHOULD NOT
this case would not serve any useful purpose. LLMNR responders periodically attempt uniqueness verification.
SHOULD NOT periodically attempt uniqueness verification.
4.2. Conflict Detection and Defense 4.2. Ongoing Conflict Detection
Hosts on disjoint network links may configure the same name for use Hosts on disjoint network links may configure the same name for use
with LLMNR. If these separate network links are later joined or with LLMNR. If these separate network links are later joined or
bridged together, then there may be multiple hosts which are now on bridged together, then there may be multiple hosts which are now on
the same link, trying to use the same name. the same link, trying to use the same name.
There are several mechanisms by which ongoing name conflicts may be In order to enable ongoing detection of name conflicts, when an LLMNR
detected: sender receives multiple LLMNR responses to a query, the sender
behaves as follows:
[a] Receipt of a query with the 'U' bit set. Whenever an LLMNR
responder receives an LLMNR query for a UNIQUE resource record with
the 'U' bit set, if the source IP address does not match an IP
address configured on that interface, this indicates a conflict.
[b] Conflict notification queries. When an LLMNR sender receives
multiple LLMNR responses to a query, it MUST send another query for
the same resource record, this time with the 'C' bit set, with the
answers received included in the Additional section.
Queries with the 'C' bit set are considered advisory and responders [1] Responses with the 'T' bit set MUST be silently discarded.
MUST verify the existence of a conflict by other means before
acting on it. A responder receiving a query with the 'C' bit set
MUST NOT respond. If the resource record is not UNIQUE, then the
responder MUST ignore the query. If the resource record is UNIQUE,
then the responder MUST send its own query for the same resource
record, with the 'U' bit set. If a response is received, or if a
query with the 'U' bit set is received, then a conflict has been
detected.
An LLMNR responder MUST NOT ignore conflicts once detected. An LLMNR [2] If multiple responses remain, the sender MUST check if the 'C' bit
responder MUST respond to a conflict as described in either [1] or [2] is clear in any of the remaining responses. If so, a potential
below: conflict has been detected; the sender SHOULD send another query
for the same name, type and class, this time with the 'C' bit set.
The potentially conflicting resource records are included in the
additional section.
[1] Upon detecting a conflict, an LLMNR responder MAY elect to Responders receiving a query with the 'C' bit set behave as follows:
immediately stop using the conflicting UNIQUE resource record in
response to LLMNR queries.
The responder MAY also elect to configure a new name. However, [3] Queries with the 'C' bit set are considered advisory and responders
since name reconfiguration may be disruptive, this is not required, MUST verify the existence of a conflict before acting on it. A
and a responder may have been configured to respond to multiple responder receiving a query with the 'C' bit set MUST NOT respond.
names so that alternative names may already be available.
[2] If a responder currently has reasons to prefer using the name, and [4] A responder receiving a query for a non-UNIQUE name with the 'C'
it has not seen any other conflicting LLMNR queries within the last bit set silently discards the query. A responder receiving a query
DEFEND_INTERVAL seconds, then it MAY elect to defend its name, by for a UNIQUE name with the 'C' bit set MUST send its own query for
recording the time that the conflicting LLMNR query was received, the same name, type and class, with the 'C' bit clear. If a
and then sending multicast queries for its UNIQUE resource records, response is received with the 'T' bit clear, then a conflict has
with the 'U' bit set. been detected.
Having done this, an LLMNR responder can then continue to use the An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
name normally without any further special action. However, if this log them. Upon detecting a conflict, an LLMNR responder MUST
is not the first conflicting LLMNR query the responder has seen, immediately stop using the name in response to LLMNR queries received
and the time recorded for the previous conflicting LLMNR query is over any supported protocol, if the source IP address in the
recent, within DEFEND_INTERVAL, then the LLMNR responder MUST response, interpreted as an unsigned integer, is less than the source
immediately cease using the conflicting resource records. IP address in the uniqueness verification query.
This is necessary to ensure that two hosts do not get stuck in an After stopping the use of a name, the responder MAY elect to
endless loop with both hosts trying to defend the same name. configure a new name. However, since name reconfiguration may be
disruptive, this is not required, and a responder may have been
configured to respond to multiple names so that alternative names may
already be available.
4.3. Considerations for Multiple Interfaces 4.3. Considerations for Multiple Interfaces
A multi-homed host may elect to configure LLMNR on only one of its A multi-homed host may elect to configure LLMNR on only one of its
active interfaces. In many situations this will be adequate. active interfaces. In many situations this will be adequate.
However, should a host need to configure LLMNR on more than one of However, should a host need to configure LLMNR on more than one of
its active interfaces, there are some additional precautions it MUST its active interfaces, there are some additional precautions it MUST
take. Implementers who are not planning to support LLMNR on multiple take. Implementers who are not planning to support LLMNR on multiple
interfaces simultaneously may skip this section. interfaces simultaneously may skip this section.
skipping to change at page 24, line 38 skipping to change at page 25, line 12
LLMNR requires allocation of link-scope multicast IPv4 address LLMNR requires allocation of link-scope multicast IPv4 address
224.0.0.252, as well as link-scope multicast IPv6 address 224.0.0.252, as well as link-scope multicast IPv6 address
FF02:0:0:0:0:0:1:3. FF02:0:0:0:0:0:1:3.
7. Constants 7. Constants
The following timing constants are used in this protocol; they are The following timing constants are used in this protocol; they are
not intended to be user configurable. not intended to be user configurable.
DEFEND_INTERVAL 10 seconds (minimum interval between
defensive LLMNR queries).
JITTER_INTERVAL 100 ms JITTER_INTERVAL 100 ms
LLMNR_TIMEOUT 1 second (only if set statically) LLMNR_TIMEOUT 1 second (if set statically)
RTOinit 500 ms (initial value of LLMNR_TIMEOUT) RTOinit 500 ms (initial value of LLMNR_TIMEOUT)
RTOmax 5 seconds (maximum value of LLMNR_TIMEOUT) RTOmax 5 seconds (maximum value of LLMNR_TIMEOUT)
RTOmin 100 ms (minimum value of LLMNR_TIMEOUT) RTOmin 100 ms (minimum value of LLMNR_TIMEOUT)
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987. Specification", RFC 1035, November 1987.
skipping to change at page 27, line 13 skipping to change at page 27, line 34
their contribution to the current specification. Constructive input their contribution to the current specification. Constructive input
has also been received from Mark Andrews, Rob Austein, Randy Bush, has also been received from Mark Andrews, Rob Austein, Randy Bush,
Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
St. Johns, Sander Van-Valkenburg, and Brian Zill. St. Johns, Sander Van-Valkenburg, and Brian Zill.
Authors' Addresses Authors' Addresses
Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: levone@microsoft.com
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: +1 425 706 6605 Phone: +1 425 706 6605
EMail: bernarda@microsoft.com EMail: bernarda@microsoft.com
Dave Thaler Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: +1 425 703 8835 Phone: +1 425 703 8835
EMail: dthaler@microsoft.com EMail: dthaler@microsoft.com
Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: levone@microsoft.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
skipping to change at page 28, line 30 skipping to change at page 28, line 49
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Open Issues Open Issues
Open issues with this specification are tracked on the following web Open issues with this specification are tracked on the following web
site: site: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/