draft-ietf-dnsext-mdns-40.txt   draft-ietf-dnsext-mdns-41.txt 
DNSEXT Working Group Bernard Aboba DNSEXT Working Group Bernard Aboba
INTERNET-DRAFT Dave Thaler INTERNET-DRAFT Dave Thaler
Category: Standards Track Levon Esibov Category: Standards Track Levon Esibov
<draft-ietf-dnsext-mdns-40.txt> Microsoft <draft-ietf-dnsext-mdns-41.txt> Microsoft
25 May 2005 15 July 2005
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 33 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 November 22, 2005. This Internet-Draft will expire on January 22, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2005. Copyright (C) The Internet Society 2005.
Abstract Abstract
Today, with the rise of home networking, there are an increasing The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
number of ad-hoc networks operating without a Domain Name System name resolution in scenarios in which conventional DNS name
(DNS) server. The goal of Link-Local Multicast Name Resolution resolution is not possible. LLMNR supports all current and future
(LLMNR) is to enable name resolution in scenarios in which DNS formats, types and classes, while operating on a separate port
conventional DNS name resolution is not possible. LLMNR supports all from DNS, and with a distinct resolver cache. Since LLMNR only
current and future DNS formats, types and classes, while operating on operates on the local link, it cannot be considered a substitute for
a separate port from DNS, and with a distinct resolver cache. Since DNS.
LLMNR only operates on the local link, it cannot be considered a
substitute for DNS.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements .................................... 3 1.1 Requirements .................................... 4
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 ................................. 9 2.2 Sender Behavior ................................. 9
2.3 Responder Behavior .............................. 9 2.3 Responder Behavior .............................. 9
2.4 Unicast Queries ................................. 11 2.4 Unicast Queries ................................. 11
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 ....................... 13
2.8 DNS TTL ......................................... 14 2.8 DNS TTL ......................................... 15
2.9 Use of the Authority and Additional Sections .... 15 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 .................. 19 4.2 Conflict Detection and Defense .................. 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 ............................................. 24
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 .......................... 25
Acknowledgments .............................................. 26 Acknowledgments .............................................. 27
Authors' Addresses ........................................... 27 Authors' Addresses ........................................... 27
Intellectual Property Statement .............................. 27 Intellectual Property Statement .............................. 27
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 is based on 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.
The goal of LLMNR is to enable name resolution in scenarios in which The goal of LLMNR is to enable name resolution in scenarios in which
conventional DNS name resolution is not possible. These include conventional DNS name resolution is not possible. Usage scenarios
scenarios in which hosts are not configured with the address of a DNS (discussed in more detail in Section 3.1) include situations in which
server, where configured DNS servers do not reply to a query, or hosts are not configured with the address of a DNS server; where the
where they respond with errors, as described in Section 2. Since DNS server is unavailable or unreachable; where there is no DNS
LLMNR only operates on the local link, it cannot be considered a server authoritative for the name of a host, or where the
substitute for DNS. authoritative DNS server does not have the desired RRs, as described
in Section 2.
Link-scope multicast addresses are used to prevent propagation of Since LLMNR only operates on the local link, it cannot be considered
LLMNR traffic across routers, potentially flooding the network. a substitute for DNS. Link-scope multicast addresses are used to
LLMNR queries can also be sent to a unicast address, as described in prevent propagation of LLMNR traffic across routers, potentially
Section 2.4. flooding the network. LLMNR queries can also be sent to a unicast
address, as described in Section 2.4.
Propagation of LLMNR packets on the local link is considered Propagation of LLMNR packets on the local link is considered
sufficient to enable name resolution in small networks. The sufficient to enable name resolution in small networks. In such
assumption is that if a network has a gateway, then the network is networks, if a network has a gateway, then typically the network is
able to provide DNS server configuration. Configuration issues are able to provide DNS server configuration. Configuration issues are
discussed in Section 3.1. discussed in Section 3.1.
In the future, it may be desirable to consider use of multicast name In the future, it may be desirable to consider use of multicast name
resolution with multicast scopes beyond the link-scope. This could resolution with multicast scopes beyond the link-scope. This could
occur if LLMNR deployment is successful, the need arises for occur if LLMNR deployment is successful, the need arises for
multicast name resolution beyond the link-scope, or multicast routing multicast name resolution beyond the link-scope, or multicast routing
becomes ubiquitous. For example, expanded support for multicast name becomes ubiquitous. For example, expanded support for multicast name
resolution might be required for mobile ad-hoc networks. resolution might be required for mobile ad-hoc networks.
Once we have experience in LLMNR deployment in terms of Once we have experience in LLMNR deployment in terms of
administrative issues, usability and impact on the network, it will administrative issues, usability and impact on the network, it will
be possible to reevaluate which multicast scopes are appropriate for be possible to reevaluate which multicast scopes are appropriate for
use with multicast name resolution. use with multicast name resolution. IPv4 administratively scoped
multicast usage is specified in "Administratively Scoped IP
Multicast" [RFC2365].
Service discovery in general, as well as discovery of DNS servers Service discovery in general, as well as discovery of DNS servers
using LLMNR in particular, is outside of the scope of this document, using LLMNR in particular, is outside of the scope of this document,
as is name resolution over non-multicast capable media. as is name resolution over non-multicast capable media.
1.1. Requirements 1.1. Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
skipping to change at page 4, line 35 skipping to change at page 4, line 41
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
the same query. There are other scenarios when only one responder the same query. There are other scenarios when only one responder
may respond to a query. Resource records for which only a single may respond to a query. Names for which only a single responder is
responder is anticipated are referred to as UNIQUE. Resource anticipated are referred to as UNIQUE. Name uniqueness is
record uniqueness is configured on the responder, and therefore configured on the responder, and therefore uniqueness verification
uniqueness verification is the responder's responsibility. 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. The IPv4 link-scope multicast address a given responder
in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link- listens to, and to which a sender sends queries, is 224.0.0.252. The
scope multicast address a given responder listens to, and to which a IPv6 link-scope multicast address a given responder listens to, and
sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast to which a sender sends all queries, is FF02:0:0:0:0:0:1:3.
address a given responder listens to, and to which a sender sends all
queries, is FF02:0:0:0:0:0:1:3.
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, if only to verify the uniqueness of names as described in
This document does not specify how names are chosen or configured. Section 4. This document does not specify how names are chosen or
This may occur via any mechanism, including DHCPv4 [RFC2131] or configured. This may occur via any mechanism, including DHCPv4
DHCPv6 [RFC3315]. [RFC2131] or 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, at all times. Enabling LLMNR for use in situations
where a DNS server has been configured will result in a change in where a DNS server has been configured will result in a change in
default behavior without a simultaneous update to configuration default behavior without a simultaneous update to configuration
information. Where this is considered undesirable, LLMNR SHOULD NOT information. Where this is considered undesirable, LLMNR SHOULD NOT
be enabled by default, so that hosts will neither listen on the link- be enabled by default, so that hosts will neither listen on the link-
scope multicast address, nor will they send queries to that address. 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.
performed. If DNS server address(es) have been If DNS server address(es) have been configured, then LLMNR
configured, then LLMNR SHOULD NOT be used as the SHOULD NOT be used as the primary name resolution mechanism,
primary name resolution mechanism, although it MAY although it MAY be used as a secondary name resolution
be used as a secondary name resolution mechanism. mechanism. For dual stack hosts configured with DNS server
For dual stack hosts configured with DNS server address(es) for one protocol but not another, this implies
address(es) for one protocol but not another, that DNS queries SHOULD be sent over the protocol configured
this implies that DNS queries SHOULD be sent with a DNS server, prior to sending LLMNR queries.
over the protocol configured with a DNS
server, prior to sending LLMNR queries.
[2] DNS servers do not respond. For a dual stack
host, the host SHOULD attempt to reach
DNS servers over all protocols on which
DNS server address(es) are configured, prior
to use of LLMNR.
[3] DNS servers respond to a DNS query with RCODE=3 [2] All attempts to resolve the name via DNS on all interfaces
(Authoritative Name Error) or RCODE=0, and an empty have failed after exhausting the searchlist. This can occur
answer section. because DNS servers did not respond, or because they
responded to DNS queries with RCODE=3 (Authoritative Name
Error) or RCODE=0, and an empty answer section. A dual
stack host SHOULD attempt to reach DNS servers over all
protocols on which DNS server address(es) are configured,
prior to use of LLMNR.
A typical sequence of events for LLMNR usage is as follows: A typical sequence of events for LLMNR usage is as follows:
[a] DNS servers are not configured or do not respond to a [a] DNS servers are not configured or attempts to resolve the
DNS query, or respond with RCODE=3, or RCODE=0 and an name via DNS have failed, after exhausting the searchlist.
empty answer section.
[b] An LLMNR sender sends an LLMNR query to the link-scope [b] An LLMNR sender sends an LLMNR query to the link-scope
multicast address(es) defined in Section 2, unless a multicast address(es) defined in Section 2, unless a
unicast query is indicated. A sender SHOULD send LLMNR unicast query is indicated. A sender SHOULD send LLMNR
queries for PTR RRs via unicast, as specified in Section 2.4. queries for PTR RRs via unicast, as specified in Section 2.4.
[c] A responder responds to this query only if it is authoritative [c] A responder responds to this query only if it is authoritative
for the domain name in the query. A responder responds to a for the domain name in the query. A responder responds to a
multicast query by sending a unicast UDP response to the sender. multicast query by sending a unicast UDP response to the sender.
Unicast queries are responded to as indicated in Section 2.4. Unicast queries are responded to as indicated in Section 2.4.
[d] Upon reception of the response, the sender processes it. [d] Upon reception of the response, the sender processes it.
Further details of sender and responder behavior are provided in the Further details of sender and responder behavior are provided in the
sections that follow. sections that follow.
2.1. LLMNR Packet Format 2.1. LLMNR Packet Format
LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 LLMNR is based on the DNS packet format defined in [RFC1035] Section
for both queries and responses. LLMNR implementations SHOULD send 4 for both queries and responses. LLMNR implementations SHOULD send
UDP queries and responses only as large as are known to be UDP queries and responses only as large as are known to be
permissible without causing fragmentation. When in doubt a maximum permissible without causing fragmentation. When in doubt a maximum
packet size of 512 octets SHOULD be used. LLMNR implementations MUST packet size of 512 octets SHOULD be used. LLMNR implementations MUST
accept UDP queries and responses as large as the smaller of the link accept UDP queries and responses as large as the smaller of the link
MTU or 8192 octets. MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
octets for the header, VLAN tag and CRC).
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 |
skipping to change at page 7, line 28 skipping to change at page 7, line 28
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 C Conflict. When set within a request, the 'C'onflict bit indicates
that a sender has received multiple LLMNR responses to this query. that a sender has received multiple LLMNR responses to this query.
In an LLMNR response, if one or more resource records in the answer In an LLMNR response, if the name is considered UNIQUE, then the
section is UNIQUE, then the 'C' bit is clear, otherwise it is set. 'C' bit is clear, otherwise it is set. LLMNR senders do not
LLMNR senders do not retransmit queries with the 'C' bit set. retransmit queries with the 'C' bit set. Responders MUST NOT
Responders MUST NOT respond to LLMNR queries with the 'C' bit set, respond to LLMNR queries with the 'C' bit set, but may start the
but may start the uniqueness verification process, as described in uniqueness verification process, as described in Section 4.2.
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.
T Tentative. The 'T'entative bit is set in a response if the T Tentative. The 'T'entative bit is set in a response if the
responder is authoritative for the name, but has not yet verified responder is authoritative for the name, but has not yet verified
the uniqueness of one or more of the resource record(s) in the the uniqueness of one or more of the resource record(s) in the
answer section. A responder MUST ignore the 'T' bit in a query, if answer section. A responder MUST ignore the 'T' bit in a query, if
set. When a response with the 'T' bit set is received in response set. If a uniqueness query elicits a response with the 'T' bit
to a uniqueness query, a conflict has been detected and a responder set, a conflict has been detected and a responder MUST resolve the
MUST resolve the conflict as described in Section 4.1. conflict as described in Section 4.1. Otherwise, a response with
the 'T' bit set is silently discarded by the sender.
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
Response code -- this 4 bit field is set as part of LLMNR Response code -- this 4 bit field is set as part of LLMNR
responses. In an LLMNR query, the RCODE MUST be zero, and is responses. In an LLMNR query, the sender MUST set RCODE to zero;
ignored by the responder. The response to a multicast LLMNR query the responder ignores the RCODE and assumes it to be zero. The
MUST have RCODE set to zero. A sender MUST silently discard an response to a multicast LLMNR query MUST have RCODE set to zero. A
LLMNR response with a non-zero RCODE sent in response to a sender MUST silently discard an LLMNR response with a non-zero
multicast query. RCODE sent in response to a multicast query.
If an LLMNR responder is authoritative for the name in a multicast If an LLMNR responder is authoritative for the name in a multicast
query, but an error is encountered, the responder SHOULD send an query, but an error is encountered, the responder SHOULD send an
LLMNR response with an RCODE of zero, no RRs in the answer section, LLMNR response with an RCODE of zero, no RRs in the answer section,
and the TC bit set. This will cause the query to be resent using and the TC bit set. This will cause the query to be resent using
TCP, and allow the inclusion of a non-zero RCODE in the response to TCP, and allow the inclusion of a non-zero RCODE in the response to
the TCP query. Responding with the TC bit set is preferable to not the TCP query. Responding with the TC bit set is preferable to not
sending a response, since it enables errors to be diagnosed. sending a response, since it enables errors to be diagnosed.
Errors include those defined in [RFC2845], such as BADSIG(16),
BADKEY(17) and BADTIME(18).
Since LLMNR responders only respond to LLMNR queries for names for Since LLMNR responders only respond to LLMNR queries for names for
which they are authoritative, LLMNR responders MUST NOT respond which they are authoritative, LLMNR responders MUST NOT respond
with an RCODE of 3; instead, they should not respond at all. with an RCODE of 3; instead, they should not respond at all.
LLMNR implementations MUST support EDNS0 [RFC2671] and extended LLMNR implementations MUST support EDNS0 [RFC2671] and extended
RCODE values. RCODE values.
QDCOUNT QDCOUNT
An unsigned 16 bit integer specifying the number of entries in the An unsigned 16 bit integer specifying the number of entries in the
skipping to change at page 8, line 52 skipping to change at page 9, line 5
one. one.
ANCOUNT ANCOUNT
An unsigned 16 bit integer specifying the number of resource An unsigned 16 bit integer specifying the number of resource
records in the answer section. LLMNR responders MUST silently records in the answer section. LLMNR responders MUST silently
discard LLMNR queries with ANCOUNT not equal to zero. discard LLMNR queries with ANCOUNT not equal to zero.
NSCOUNT NSCOUNT
An unsigned 16 bit integer specifying the number of name server An unsigned 16 bit integer specifying the number of name server
resource records in the authority records section. Authority resource records in the authority records section. Authority
record section processing is described in Section 2.9. record section processing is described in Section 2.9. LLMNR
responders MUST silently discard LLMNR queries with NSCOUNT not
equal to zero.
ARCOUNT ARCOUNT
An unsigned 16 bit integer specifying the number of resource An unsigned 16 bit integer specifying the number of resource
records in the additional records section. Additional record records in the additional records section. Additional record
section processing is described in Section 2.9. section processing is described in Section 2.9.
2.2. Sender Behavior 2.2. Sender Behavior
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.
skipping to change at page 9, line 31 skipping to change at page 9, line 35
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, a
resolver treats it as a response that no records of the specified resolver treats it as a response that no records of the specified
type and class exist for the specified name (it is treated the same type and class exist for the specified name (it is treated the same
as a response with RCODE=0 and an empty answer section). 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
LLMNR query, in the event that several LLMNR enabled computers
receive the query and respond with valid answers. When multiple
valid answers are received, they may first be concatenated, and then
treated in the same manner that multiple RRs received from the same
DNS server would.
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 in addition to the SOA RR; the SOA RR MUST
that a responder has. However, in general whether RRs are manually NOT be the only RR that a responder has. However, in general whether
or automatically created is an implementation decision. RRs are manually or automatically created is an implementation
decision.
For example, a host configured to have computer name "host1" and to For example, a host configured to have computer name "host1" and to
be a member of the "example.com" domain, and with IPv4 address be a member of the "example.com" domain, and with IPv4 address
192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
authoritative for the following records: authoritative for the following records:
host1. IN A 192.0.2.1 host1. IN A 192.0.2.1
IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
host1.example.com. IN A 192.0.2.1 host1.example.com. IN A 192.0.2.1
skipping to change at page 12, line 23 skipping to change at page 12, line 23
Unicast UDP queries MUST be silently discarded. Unicast UDP queries MUST be silently discarded.
If TCP connection setup cannot be completed in order to send a If TCP connection setup cannot be completed in order to send a
unicast TCP query, this is treated as a response that no records of unicast TCP query, this is treated as a response that no records of
the specified type and class exist for the specified name (it is the specified type and class exist for the specified name (it is
treated the same as a response with RCODE=0 and an empty answer treated the same as a response with RCODE=0 and an empty answer
section). section).
2.5. "Off link" Detection 2.5. "Off link" Detection
For IPv4, an "on link" address is defined as a link-local address A sender MUST select a source address for LLMNR queries that is
[IPv4Link] or an address whose prefix belongs to a subnet on the assigned on the interface on which the query is sent. The
local link. For IPv6 [RFC2460] an "on link" address is either a destination address of an LLMNR query MUST be a link-scope multicast
link-local address, defined in [RFC2373], or one belonging to a address or a unicast address.
prefix that a Router Advertisement indicates is on-link [RFC2461].
A sender MUST select a source address for LLMNR queries that is "on
link". The destination address of an LLMNR query MUST be a link-
scope multicast address or an "on link" unicast address.
A responder MUST select a source address for responses that is "on A responder MUST select a source address for responses that is
link". The destination address of an LLMNR response MUST be an "on assigned on the interface on which the query was received. The
link" unicast address. destination address of an LLMNR response MUST be a unicast address.
On receiving an LLMNR query, the responder MUST check whether it was On receiving an LLMNR query, the responder MUST check whether it was
sent to a LLMNR multicast addresses defined in Section 2. If it was sent to a LLMNR multicast addresses defined in Section 2. If it was
sent to another multicast address, then the query MUST be silently sent to another multicast address, then the query MUST be silently
discarded. discarded.
Section 2.4 discusses use of TCP for LLMNR queries and responses. In Section 2.4 discusses use of TCP for LLMNR queries and responses. In
composing an LLMNR query using TCP, the sender MUST set the Hop Limit composing an LLMNR query using TCP, the sender MUST set the Hop Limit
field in the IPv6 header and the TTL field in the IPv4 header of the field in the IPv6 header and the TTL field in the IPv4 header of the
response to one (1). The responder SHOULD set the TTL or Hop Limit response to one (1). The responder SHOULD set the TTL or Hop Limit
skipping to change at page 13, line 23 skipping to change at page 13, line 18
option is available on some platforms to retrieve the IPv4 TTL of option is available on some platforms to retrieve the IPv4 TTL of
received packets with recvmsg(). [RFC2292] specifies similar received packets with recvmsg(). [RFC2292] specifies similar
options for setting and retrieving the IPv6 Hop Limit. options for setting and retrieving the IPv6 Hop Limit.
2.6. Responder Responsibilities 2.6. Responder Responsibilities
It is the responsibility of the responder to ensure that RRs returned It is the responsibility of the responder to ensure that RRs returned
in LLMNR responses MUST only include values that are valid on the in LLMNR responses MUST only include values that are valid on the
local interface, such as IPv4 or IPv6 addresses valid on the local local interface, such as IPv4 or IPv6 addresses valid on the local
link or names defended using the mechanism described in Section 4. link or names defended using the mechanism described in Section 4.
In particular: IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local
addresses are defined in [RFC2373]. In particular:
[a] If a link-scope IPv6 address is returned in a AAAA RR, [a] If a link-scope IPv6 address is returned in a AAAA RR,
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
skipping to change at page 13, line 50 skipping to change at page 13, line 46
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, [e] 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. Rather than using a static
to an LLMNR query. timeout, an LLMNR sender SHOULD dynamically compute the value of
LLMNR_TIMEOUT for each transmission, on a per-interface basis.
For example, the algorithms described in RFC 2988 [RFC2988] compute
an RTO (including exponential backoff), which is used as the value of
LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO
(discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO
(discussed in Section 2 of [RFC2988], paragraph 2.4), and the
maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).
Recommended values for constants (including LLMNR_TIMEOUT if it is
set statically) are given in Section 7. In order to take slow
responders into account, an LLMNR sender SHOULD include responses
received after LLMNR_TIMEOUT in the computations.
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 multicast UDP and MUST NOT be retransmitted. sent over multicast UDP and MUST NOT be retransmitted. Responses to
queries with the 'C' bit set are not taken into account within
retransmission timeout computations.
Because an LLMNR sender cannot know in advance if a query sent using 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. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
collect all possible responses, rather than considering the multicast has been received, or if it is necessary to collect all potential
query answered after the first response is received. A unicast query responses, such as if a uniqueness verification query is being made.
sender considers the query answered after the first response is Otherwise an LLMNR sender SHOULD consider a multicast query answered
received, so that it only waits for LLMNR_TIMEOUT if no response has after the first response is received, if that response has the 'C'
been received. bit clear.
An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT However, if the first response has the 'C' bit set, then the sender
for each transmission. For example, the algorithms described in RFC SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
2988 [RFC2988] (including exponential backoff) compute an RTO, which responses. When multiple valid answers are received, they may first
is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used be concatenated, and then treated in the same manner that multiple
for the initial RTO (discussed in Section 2 of [RFC2988], paragraph RRs received from the same DNS server would. A unicast query sender
2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph considers the query answered after the first response is received, so
2.4), and the maximum RTO (discussed in Section 2 of [RFC2988], that it only waits for LLMNR_TIMEOUT if no response has been
paragraph 2.5). received.
Since it is possible for a response with the 'C' bit clear to be
followed by a response with the 'C' bit set, an LLMNR sender SHOULD
be prepared to process additional responses for the purposes of
conflict detection and LLMNR_TIMEOUT estimation, even after it has
considered a query answered.
In order to avoid synchronization, the transmission of each LLMNR In order to avoid synchronization, the transmission of each LLMNR
query and response SHOULD delayed by a time randomly selected from query and response SHOULD delayed by a time randomly selected from
the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
responders responding with RRs which they have previously determined responders responding with names which they have previously
to be UNIQUE (see Section 4 for details). determined to be UNIQUE (see Section 4 for details).
Recommended values for constants (including LLMNR_TIMEOUT if it is
set statically) are given in Section 7.
2.8. DNS TTL 2.8. DNS TTL
The responder should insert a pre-configured TTL value in the records The responder should insert a pre-configured TTL value in the records
returned in an LLMNR response. A default value of 30 seconds is returned in an LLMNR response. A default value of 30 seconds is
RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
networks), the TTL value may need to be reduced. networks), the TTL value may need to be reduced.
Due to the TTL minimalization necessary when caching an RRset, all Due to the TTL minimalization necessary when caching an RRset, all
TTLs in an RRset MUST be set to the same value. TTLs in an RRset MUST be set to the same value.
skipping to change at page 16, line 37 skipping to change at page 16, line 47
DNS server over IPv4, while remaining unconfigured with a DNS server DNS server over IPv4, while remaining unconfigured with a DNS server
suitable for use over IPv6. suitable for use over IPv6.
In these situations, a dual stack host will send AAAA queries to the In these situations, a dual stack host will send AAAA queries to the
configured DNS server over IPv4. However, an IPv6-only host configured DNS server over IPv4. However, an IPv6-only host
unconfigured with a DNS server suitable for use over IPv6 will be unconfigured with a DNS server suitable for use over IPv6 will be
unable to resolve names using DNS. Automatic IPv6 DNS configuration unable to resolve names using DNS. Automatic IPv6 DNS configuration
mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
deployed, and not all DNS servers support IPv6. Therefore lack of deployed, and not all DNS servers support IPv6. Therefore lack of
IPv6 DNS configuration may be a common problem in the short term, and IPv6 DNS configuration may be a common problem in the short term, and
LLMNR may prove useful in enabling linklocal name resolution over LLMNR may prove useful in enabling link-local name resolution over
IPv6. IPv6.
Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
IPv6-only hosts may not be configured with a DNS server. Where there IPv6-only hosts may not be configured with a DNS server. Where there
is no DNS server authoritative for the name of a host or the is no DNS server authoritative for the name of a host or the
authoritative DNS server does not support dynamic client update over authoritative DNS server does not support dynamic client update over
IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
be able to do DNS dynamic update, and other hosts will not be able to be able to do DNS dynamic update, and other hosts will not be able to
resolve its name. resolve its name.
skipping to change at page 17, line 48 skipping to change at page 18, line 10
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 MAY depend on the nature of the By default, a responder SHOULD be configured to behave as though its
name in the query and type of the query. For example, multiple hosts name is UNIQUE on each interface on which LLMNR is enabled. However,
may respond to a query for an A or AAAA type record for a cluster it is also possible to configure multiple responders to be
name (assigned to multiple hosts in the cluster). By default, a authoritative for the same name. For example, multiple responders
responder SHOULD be configured to behave as though all RRs are UNIQUE MAY respond to a query for an A or AAAA type record for a cluster
on each interface on which LLMNR is enabled. name (assigned to multiple hosts in the cluster).
To detect duplicate use of a name, an administrator can use a name To detect duplicate use of a name, an administrator can use a name
resolution utility which employs LLMNR and lists both responses and resolution utility which employs LLMNR and lists both responses and
responders. This would allow an administrator to diagnose behavior responders. This would allow an administrator to diagnose behavior
and potentially to intervene and reconfigure LLMNR responders who and potentially to intervene and reconfigure LLMNR responders who
should not be configured to respond to the same name. should 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 with the Prior to sending an LLMNR response with the 'T' bit clear, a
'T' bit clear, for each UNIQUE resource record in a given interface's responder configured with a UNIQUE name MUST verify that there is no
configuration, the host MUST verify that there is no other host other host within the scope of LLMNR query propagation that is
within the scope of LLMNR query propagation that can return a authoritative for the same name on that interface.
resource record for the same name, type and class on that interface.
Once a responder has verified the uniqueness of a UNIQUE resource Once a responder has verified that its name is UNIQUE, if it receives
record, if it receives an LLMNR query for that resource record, with an LLMNR query for that name, with the 'C' bit clear, it MUST
the 'C' bit clear, it MUST respond, with the 'T' bit clear. Prior to respond, with the 'T' bit clear. Prior to verifying that its name is
verifying uniqueness, a responder MUST set the 'T' bit in responses. UNIQUE, a responder MUST set the 'T' bit in responses.
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, a responder MUST send an LLMNR query with the
'C' bit clear, over all protocols on which it responds to LLMNR 'C' bit clear, over all protocols on which it responds to LLMNR
queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
uniqueness of a name by sending a query for the name with type='ANY'. uniqueness of a name by sending a query for the name with type='ANY'.
If no response is received, the sender retransmits the query, as 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 specified in Section 2.7. If a response is received, the sender MUST
clear, the responder MUST NOT use the name in response to LLMNR check if the source address matches the address of any of its
queries received over any protocol (IPv4 or IPv6). If a response is interfaces; if so, then the response is not considered a conflict,
received with the 'T' bit set, the responder MUST check if the source since it originates from the sender.
IP address in the response, interpreted as an unsigned integer, is
less than the source IP address in the query. If so, the responder If a response is received with the 'T' bit clear, the responder MUST
MUST NOT use the name in response to LLMNR queries received over any NOT use the name in response to LLMNR queries received over any
protocol (IPv4 or IPv6). For the purpose of uniqueness verification, protocol (IPv4 or IPv6). If a response is received with the 'T' bit
the contents of the answer section in a response is irrelevant. 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. LLMNR responders SHOULD NOT forced reconfiguration is required. LLMNR responders SHOULD NOT
periodically attempt uniqueness verification. periodically attempt uniqueness verification.
4.2. Conflict Detection and Defense 4.2. Conflict Detection and Defense
skipping to change at page 19, line 32 skipping to change at page 19, line 47
sender receives multiple LLMNR responses to a query, it MUST check if sender receives multiple LLMNR responses to a query, it MUST check if
the 'C' bit is clear in any of the responses. If so, the sender the 'C' bit is clear in any of the responses. If so, the sender
SHOULD send another query for the same name, type and class, this SHOULD send another query for the same name, type and class, this
time with the 'C' bit set, with the potentially conflicting resource time with the 'C' bit set, with the potentially conflicting resource
records included in the additional section. records included in the additional section.
Queries with the 'C' bit set are considered advisory and responders Queries with the 'C' bit set are considered advisory and responders
MUST verify the existence of a conflict before acting on it. A MUST verify the existence of a conflict before acting on it. A
responder receiving a query with the 'C' bit set MUST NOT respond. responder receiving a query with the 'C' bit set MUST NOT respond.
If the query is for UNIQUE resource record(s), then the responder If the query is for a UNIQUE name, then the responder MUST send its
MUST send its own query for the same name, type and class, with the own query for the same name, type and class, with the 'C' bit clear.
'C' bit clear. If a response is received, then a conflict has been If a response is received, then a conflict has been detected.
detected.
An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
log them. Upon detecting a conflict, an LLMNR responder MUST log them. Upon detecting a conflict, an LLMNR responder MUST
immediately stop using the conflicting name in response to LLMNR immediately stop using the conflicting name in response to LLMNR
queries received over any supported protocol, if the source IP queries received over any supported protocol, if the source IP
address in the response, interpreted as an unsigned integer, is less address in the response, interpreted as an unsigned integer, is less
than the source IP address in the uniqueness verification query. than the source IP address in the uniqueness verification query.
After stopping the use of a name, the responder MAY elect to After stopping the use of a name, the responder MAY elect to
configure a new name. However, since name reconfiguration may be configure a new name. However, since name reconfiguration may be
disruptive, this is not required, and a responder may have been disruptive, this is not required, and a responder may have been
configured to respond to multiple names so that alternative names may configured to respond to multiple names so that alternative names may
already be available. already be available. A host that has stopped the use of a name may
attempt uniqueness verification again after the expiration of the TTL
of the conflicting response.
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 21, line 16 skipping to change at page 21, line 29
[A] [A]
| | | |
----- ----- ----- -----
| | | |
[myhost] [myhost]
Figure 3. Multiple paths to same host Figure 3. Multiple paths to same host
This illustrates that the proposed name conflict resolution mechanism This illustrates that the proposed name conflict resolution mechanism
does not support detection or resolution of conflicts between hosts does not support detection or resolution of conflicts between hosts
on different links. This problem can also occur with unicast DNS on different links. This problem can also occur with DNS when a
when a multi-homed host is connected to two different networks with multi-homed host is connected to two different networks with
separated name spaces. It is not the intent of this document to separated name spaces. It is not the intent of this document to
address the issue of uniqueness of names within DNS. address the issue of uniqueness of names within DNS.
4.4. API Issues 4.4. API Issues
[RFC2553] provides an API which can partially solve the name [RFC2553] provides an API which can partially solve the name
ambiguity problem for applications written to use this API, since the ambiguity problem for applications written to use this API, since the
sockaddr_in6 structure exposes the scope within which each scoped sockaddr_in6 structure exposes the scope within which each scoped
address exists, and this structure can be used for both IPv4 (using address exists, and this structure can be used for both IPv4 (using
v4-mapped IPv6 addresses) and IPv6 addresses. v4-mapped IPv6 addresses) and IPv6 addresses.
skipping to change at page 22, line 25 skipping to change at page 22, line 38
With LLMNR it is possible that hosts will allocate conflicting names With LLMNR it is possible that hosts will allocate conflicting names
for a period of time, or that attackers will attempt to deny service for a period of time, or that attackers will attempt to deny service
to other hosts by allocating the same name. Such attacks also allow to other hosts by allocating the same name. Such attacks also allow
hosts to receive packets destined for other hosts. hosts to receive packets destined for other hosts.
Since LLMNR is typically deployed in situations where no trust model Since LLMNR is typically deployed in situations where no trust model
can be assumed, it is likely that LLMNR queries and responses will be can be assumed, it is likely that LLMNR queries and responses will be
unauthenticated. In the absence of authentication, LLMNR reduces the unauthenticated. In the absence of authentication, LLMNR reduces the
exposure to such threats by utilizing UDP queries sent to a link- exposure to such threats by utilizing UDP queries sent to a link-
scope multicast address, as well as setting the TTL (IPv4) or Hop scope multicast address, as well as setting the TTL (IPv4) or Hop
Limit (IPv6) fields to one (1) on TCP queries and responses. Limit (IPv6) fields to one (1) on unicast queries and responses.
Using a TTL of one (1) to set up a TCP connection in order to send a Using a TTL of one (1) in order to send a unicast LLMNR query reduces
unicast LLMNR query reduces the likelihood of both denial of service the likelihood of both denial of service attacks and spoofed
attacks and spoofed responses. Checking that an LLMNR query is sent responses. Checking that an LLMNR query is sent to a link-scope
to a link-scope multicast address should prevent spoofing of multicast address should prevent spoofing of multicast queries by
multicast queries by off-link attackers. off-link attackers.
While this limits the ability of off-link attackers to spoof LLMNR While this limits the ability of off-link attackers to spoof LLMNR
queries and responses, it does not eliminate it. For example, it is queries and responses, it does not eliminate it. For example, it is
possible for an attacker to spoof a response to a query (such as an A possible for an attacker to spoof a response to a query (such as an A
or AAAA query for a popular Internet host), and by using a TTL or Hop or AAAA query for a popular Internet host), and by using a TTL or Hop
Limit field larger than one (1), for the forged response to reach the Limit field larger than one (1), for the forged response to reach the
LLMNR sender. LLMNR sender.
When LLMNR queries are sent to a link-scope multicast address, it is When LLMNR queries are sent to a link-scope multicast address, it is
possible that some routers may not properly implement link-scope possible that some routers may not properly implement link-scope
skipping to change at page 23, line 15 skipping to change at page 23, line 28
wireless networks such as 802.11, since attackers on a wired network wireless networks such as 802.11, since attackers on a wired network
will require physical access to the home network, while wireless will require physical access to the home network, while wireless
attackers may reside outside the home. Link-layer security can be of attackers may reside outside the home. Link-layer security can be of
assistance against these threats if it is available. assistance against these threats if it is available.
5.2. Usage Restriction 5.2. Usage Restriction
As noted in Sections 2 and 3, LLMNR is intended for usage in a As noted in Sections 2 and 3, LLMNR is intended for usage in a
limited set of scenarios. limited set of scenarios.
If an LLMNR query is sent whenever a DNS server does not respond in a Since an LLMNR query can be sent when DNS server(s) do not respond,
timely way, then an attacker can poison the LLMNR cache by responding an attacker can execute a denial of service attack on the DNS
to the query with incorrect information. To some extent, these server(s) and then poison the LLMNR cache by responding to an LLMNR
query with incorrect information. To some extent, these
vulnerabilities exist today, since DNS response spoofing tools are vulnerabilities exist today, since DNS response spoofing tools are
available that can allow an attacker to respond to a query more available that can allow an attacker to respond to a query more
quickly than a distant DNS server. quickly than a distant DNS server.
Since LLMNR queries are sent and responded to on the local-link, an Since LLMNR queries are sent and responded to on the local-link, an
attacker will need to respond more quickly to provide its own attacker will need to respond more quickly to provide its own
response prior to arrival of the response from a legitimate response prior to arrival of the response from a legitimate
responder. If an LLMNR query is sent for an off-link host, spoofing a responder. If an LLMNR query is sent for an off-link host, spoofing
response in a timely way is not difficult, since a legitimate a response in a timely way is not difficult, since a legitimate
response will never be received. response will never be received.
The vulnerability is more serious if LLMNR is given higher priority The vulnerability is more serious if LLMNR is given higher priority
than DNS among the enabled name resolution mechanisms. In such a than DNS among the enabled name resolution mechanisms. In such a
configuration, a denial of service attack on the DNS server would not configuration, a denial of service attack on the DNS server would not
be necessary in order to poison the LLMNR cache, since LLMNR queries be necessary in order to poison the LLMNR cache, since LLMNR queries
would be sent even when the DNS server is available. In addition, would be sent even when the DNS server is available. In addition,
the LLMNR cache, once poisoned, would take precedence over the DNS the LLMNR cache, once poisoned, would take precedence over the DNS
cache, eliminating the benefits of cache separation. As a result, cache, eliminating the benefits of cache separation. As a result,
LLMNR is only used as a name resolution mechanism of last resort. LLMNR is only used as a name resolution mechanism of last resort.
5.3. Cache and Port Separation 5.3. Cache and Port Separation
In order to prevent responses to LLMNR queries from polluting the DNS In order to prevent responses to LLMNR queries from polluting the DNS
cache, LLMNR implementations MUST use a distinct, isolated cache for cache, LLMNR implementations MUST use a distinct, isolated cache for
LLMNR on each interface. The use of separate caches is most effective LLMNR on each interface. The use of separate caches is most
when LLMNR is used as a name resolution mechanism of last resort, effective when LLMNR is used as a name resolution mechanism of last
since this minimizes the opportunities for poisoning the LLMNR cache, resort, since this minimizes the opportunities for poisoning the
and decreases reliance on it. LLMNR cache, and decreases reliance on it.
LLMNR operates on a separate port from DNS, reducing the likelihood LLMNR operates on a separate port from DNS, reducing the likelihood
that a DNS server will unintentionally respond to an LLMNR query. that a DNS server will unintentionally respond to an LLMNR query.
5.4. Authentication 5.4. Authentication
LLMNR implementations MAY support TSIG and/or SIG(0) security Since LLMNR does not support "delegated trust" (CD or AD bits), and
mechanisms. Since LLMNR does not support "delegated trust" (CD or AD LLMNR senders are unlikely to be DNSSEC-aware, in practice LLMNR is
bits), and LLMNR senders are unlikely to be DNSSEC-aware, in practice not compatible with DNSSEC.
LLMNR is not compatible with DNSSEC.
Since LLMNR implementations MAY NOT support TSIG or SIG(0), responses LLMNR implementations MAY support TSIG and/or SIG(0) security
to LLMNR queries may be unauthenticated. If authentication is mechanisms; where this is not supported, responses to LLMNR queries
desired, and a pre-arranged security configuration is possible, then may be unauthenticated. If authentication is desired, and a pre-
IPsec ESP with a null-transform MAY be used to authenticate unicast arranged security configuration is possible, then IPsec ESP with a
LLMNR queries and responses or LLMNR responses to multicast queries. null-transform MAY be used to authenticate unicast LLMNR queries and
In a small network without a certificate authority, this can be most responses or LLMNR responses to multicast queries. In a small
easily accomplished through configuration of a group pre-shared key network without a certificate authority, this can be most easily
for trusted hosts. accomplished through configuration of a group pre-shared key for
trusted hosts.
6. IANA Considerations 6. IANA Considerations
This specification creates one new name space: the reserved bits in This specification creates one new name space: the reserved bits in
the LLMNR header. These are allocated by IETF Consensus, in the LLMNR header. These are allocated by IETF Consensus, in
accordance with BCP 26 [RFC2434]. accordance with BCP 26 [RFC2434].
LLMNR requires allocation of port 5355 for both TCP and UDP. LLMNR requires allocation of port 5355 for both TCP and UDP.
LLMNR requires allocation of link-scope multicast IPv4 address LLMNR requires allocation of link-scope multicast IPv4 address
skipping to change at page 25, line 24 skipping to change at page 25, line 36
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998. 2365, July 1998.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
8.2. Informative References 8.2. Informative References
 End of changes. 

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