draft-ietf-dnsext-mdns-37.txt   draft-ietf-dnsext-mdns-38.txt 
DNSEXT Working Group Levon Esibov DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler Category: Standards Track Dave Thaler
<draft-ietf-dnsext-mdns-37.txt> Microsoft <draft-ietf-dnsext-mdns-38.txt> Microsoft
20 October 2004 19 February 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 April 22, 2005. This Internet-Draft will expire on August 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2004. 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
(LLMNR) is to enable name resolution in scenarios in which (LLMNR) is to enable name resolution in scenarios in which
conventional DNS name resolution is not possible. LLMNR supports all conventional DNS name resolution is not possible. LLMNR supports all
current and future DNS formats, types and classes, while operating on current and future DNS formats, types and classes, while operating on
a separate port from DNS, and with a distinct resolver cache. Since a separate port from DNS, and with a distinct resolver cache. Since
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 ................................. 8
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 .............................. 11 2.5 Off-link detection .............................. 12
2.6 Responder responsibilities ...................... 12 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 ......................................... 14
2.9 Use of the authority and additional sections .... 14 2.9 Use of the authority and additional sections .... 14
3. Usage model ........................................... 14 3. Usage model ........................................... 15
3.1 LLMNR configuration ............................. 15 3.1 LLMNR configuration ............................. 16
4. Conflict resolution ................................... 17 4. Conflict resolution ................................... 17
4.1 Considerations for multiple interfaces .......... 18 4.1 Uniqueness Verification ......................... 18
4.2 API issues ...................................... 19 4.2 Conflict Detection and Defense .................. 18
5. Security considerations ............................... 20 4.3 Considerations for multiple interfaces .......... 20
5.1 Scope restriction ............................... 20 4.4 API issues ...................................... 21
5.2 Usage restriction ............................... 21 5. Security considerations ............................... 21
5.3 Cache and port separation ....................... 22 5.1 Scope restriction ............................... 22
5.4 Authentication .................................. 22 5.2 Usage restriction ............................... 23
6. IANA considerations ................................... 22 5.3 Cache and port separation ....................... 23
7. References ............................................ 23 5.4 Authentication .................................. 24
7.1 Normative References ............................ 23 6. IANA considerations ................................... 24
7.2 Informative References .......................... 23 7. Constants ............................................. 24
Acknowledgments .............................................. 25 8. References ............................................ 24
Authors' Addresses ........................................... 25 8.1 Normative References ............................ 24
Intellectual Property Statement .............................. 25 8.2 Informative References .......................... 25
Disclaimer of Validity ....................................... 26 Acknowledgments .............................................. 26
Copyright Statement .......................................... 26 Authors' Addresses ........................................... 27
Intellectual Property Statement .............................. 27
Disclaimer of Validity ....................................... 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.
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
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| Z| Z| Z| Z| Z| RCODE | |QR| Opcode | Z|TC| U| C| Z| Z| Z| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT | | QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT | | ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT | | NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | | ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
skipping to change at page 7, line 24 skipping to change at page 7, line 24
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
bit MUST NOT be set in an LLMNR response, and if set is ignored by
an LLMNR sender. If the U bit is set in an LLMNR query, this
indicates that the sender believes that it is authoritative for the
name. See Section 4.1 and 4.2 for discussion of name conflict
detection.
C Conflict - specifies that a sender has previously received multiple
LLMNR responses to this query. The C bit MUST NOT be set in an
LLMNR response, and if set is ignored by an LLMNR sender.
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
Response code -- this 4 bit field is set as part of LLMNR Response code -- this 4 bit field is set as part of LLMNR
skipping to change at page 10, line 11 skipping to change at page 10, line 25
[b] Responders MUST direct responses to the port from which the query [b] Responders MUST direct responses to the port from which the query
was sent. When queries are received via TCP this is an inherent was sent. When queries are received via TCP this is an inherent
part of the transport protocol. For queries received by UDP the part of the transport protocol. For queries received by UDP the
responder MUST take note of the source port and use that as the responder MUST take note of the source port and use that as the
destination port in the response. Responses MUST always be sent destination port in the response. Responses MUST always be sent
from the port to which they were directed. from the port to which they were directed.
[c] Responders MUST respond to LLMNR queries for names and addresses [c] Responders MUST respond to LLMNR queries for names and addresses
they are authoritative for. This applies to both forward and they are authoritative for. This applies to both forward and
reverse lookups. reverse lookups, with the exception of queries with the 'C' bit
set, which do not elicit a response.
[d] Responders MUST NOT respond to LLMNR queries for names they are not [d] Responders MUST NOT respond to LLMNR queries for names they are not
authoritative for. authoritative for.
[e] Responders MUST NOT respond using data from the LLMNR or DNS [e] Responders MUST NOT respond using data from the LLMNR or DNS
resolver cache. resolver cache.
[f] If a DNS server is running on a host that supports LLMNR, the DNS [f] If a DNS server is running on a host that supports LLMNR, the DNS
server MUST respond to LLMNR queries only for the RRSets relating server MUST respond to LLMNR queries only for the RRSets relating
to the host on which the server is running, but MUST NOT respond to the host on which the server is running, but MUST NOT respond
skipping to change at page 13, line 34 skipping to change at page 13, line 46
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. handled by the transport layer. Queries with the 'C' bit set MUST be
sent over 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.
An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
for each transmission. For example, the algorithms described in RFC for each transmission. For example, the algorithms described in RFC
2988 [RFC2988] (including exponential backoff) compute an RTO, which 2988 [RFC2988] (including exponential backoff) compute an RTO, which
is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used
for the initial RTO (discussed in Section 2 of [RFC2988], paragraph for the initial RTO (discussed in Section 2 of [RFC2988], paragraph
2.1), the minimum 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], 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988],
paragraph 2.5). Recommended values are an initial RTO of 500ms, a paragraph 2.5).
minimum RTO of 100ms, and a maximum RTO of 5 seconds.
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 100 ms. This delay MAY be avoided by responders the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
responding with RRs which they have previously determined to be responders responding with RRs which they have previously determined
UNIQUE (see Section 4 for details). 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 14, line 37 skipping to change at page 15, line 5
delegation semantics as it does in the DNS. Responders MAY have NS delegation semantics as it does in the DNS. Responders MAY have NS
records associated with the names for which they are authoritative, records associated with the names for which they are authoritative,
but they SHOULD NOT include these NS records in the authority but they SHOULD NOT include these NS records in the authority
sections of responses. sections of responses.
Responders SHOULD insert an SOA record into the authority section of Responders SHOULD insert an SOA record into the authority section of
a negative response, to facilitate negative caching as specified in a negative response, to facilitate negative caching as specified in
[RFC2308]. The owner name of this SOA record MUST be equal to the [RFC2308]. The owner name of this SOA record MUST be equal to the
query name. query name.
In LLMNR, the additional section is only intended for use by EDNS0, In LLMNR, the additional section is primarily intended for use by
TSIG and SIG(0). As a result, senders MAY only include pseudo RR- EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set,
types in the additional section of a query; responders MUST ignore senders MAY only include pseudo RR-types in the additional section of
the additional section of queries containing other RR types. a query; unless the 'C' bit is set, responders MUST ignore the
additional section of queries containing other RR types.
In queries where the 'C' bit is set, the sender SHOULD include the
conflicting RRs in the additional section. Since conflict
notifications are advisory, responders SHOULD log information from
the additional section, but otherwise MUST ignore the additional
section.
Senders MUST NOT cache RRs from the authority or additional section Senders MUST NOT cache RRs from the authority or additional section
of a response as answers, though they may be used for other purposes of a response as answers, though they may be used for other purposes
such as negative caching. such as negative caching.
3. Usage model 3. Usage model
Since LLMNR is a secondary name resolution mechanism, its usage is in Since LLMNR is a secondary name resolution mechanism, its usage is in
part determined by the behavior of DNS implementations. This part determined by the behavior of DNS implementations. This
document does not specify any changes to DNS resolver behavior, such document does not specify any changes to DNS resolver behavior, such
skipping to change at page 17, line 22 skipping to change at page 17, line 44
in the query and type of the query. For example it is expected that: 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 - multiple hosts may respond to a query for an SRV type record
- multiple hosts may respond to a query for an A or AAAA type - multiple hosts may respond to a query for an A or AAAA type
record for a cluster name (assigned to multiple hosts in record for a cluster name (assigned to multiple hosts in
the cluster) the cluster)
- only a single host may respond to a query for an A or AAAA - only a single host may respond to a query for an A or AAAA
type record for a name. type record for a name.
By default, a responder SHOULD be configured to behave as though all By default, a responder SHOULD be configured to behave as though all
RRs are UNIQUE on each interface on which LLMNR is enabled. Prior to RRs are UNIQUE on each interface on which LLMNR is enabled.
including a UNIQUE resource record in a response, for each UNIQUE
resource record in a given interface's configuration, the host MUST
verify that there is no other host within the scope of LLMNR query
propagation that can return a resource record for the same name, type
and class on that interface. Once a responder has verified the
uniqueness of a UNIQUE resource record, if it receives an LLMNR query
for that resource record, it MUST respond.
To verify uniqueness, a responder MUST send an LLMNR query for each When name conflicts are detected, they SHOULD be logged. To detect
UNIQUE resource record. If no response is received after a suitable duplicate use of a name, an administrator can use a name resolution
number of attempts (see Section 2.7), the responder can use the utility which employs LLMNR and lists both responses and responders.
UNIQUE resource record in response to LLMNR queries. If a response This would allow an administrator to diagnose behavior and
is received, the responder MUST NOT use the UNIQUE resource record in potentially to intervene and reconfigure LLMNR responders who should
response to LLMNR queries. not be configured to respond to the same name.
4.1. Uniqueness Verification
Prior to including a UNIQUE resource record in a response, for each
UNIQUE resource record in a given interface's configuration, the host
MUST verify that there is no other host within the scope of LLMNR
query propagation that can return a resource record for the same
name, type and class on that interface.
Once a responder has verified the uniqueness of a UNIQUE resource
record, if it receives an LLMNR query for that resource record, with
the 'C' bit clear, it MUST respond.
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
The name conflict detection mechanism doesn't prevent name conflicts To verify uniqueness, a responder MUST send an LLMNR query with the
when previously partitioned segments are connected by a bridge. It 'U' bit set for each UNIQUE resource record. If no response is
also does not prevent deadlocks where two hosts attempt to verify received, the sender retransmits the query, as specified in Section
uniqueness of the same RR, yet neither can yet respond to queries 2.7. If a response is received, the responder MUST NOT use the UNIQUE
since uniqueness has not yet been verified. resource record in response to LLMNR queries.
In order to minimize the chance of conflicts in such situations, it Periodically carrying out uniqueness verification in an attempt to
is recommended that steps be taken to ensure name uniqueness. For detect name conflicts is not necessary, wastes network bandwidth, and
example, the name could be chosen randomly from a large pool of may actually be detrimental. For example, if network links are
potential names, or the name could be assigned via a process designed joined only briefly, and are separated again before any new
to guarantee uniqueness. communication is initiated, temporary conflicts are benign and no
forced reconfiguration is required. Triggering a reconfiguration in
this case would not serve any useful purpose. LLMNR responders
SHOULD NOT periodically attempt uniqueness verification.
When name conflicts are detected, they SHOULD be logged. To detect 4.2. Conflict Detection and Defense
duplicate use of a name, an administrator can use a name resolution
utility which employs LLMNR and lists both responses and responders.
This would allow an administrator to diagnose behavior and
potentially to intervene and reconfigure LLMNR responders who should
not be configured to respond to the same name.
4.1. Considerations for Multiple Interfaces Hosts on disjoint network links may configure the same name for use
with LLMNR. If these separate network links are later joined or
bridged together, then there may be multiple hosts which are now on
the same link, trying to use the same name.
There are several mechanisms by which ongoing name conflicts may be
detected:
[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
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
responder MUST respond to a conflict as described in either [1] or [2]
below:
[1] Upon detecting a conflict, an LLMNR responder MAY elect to
immediately stop using the conflicting UNIQUE resource record in
response to LLMNR queries.
The responder MAY also elect to 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.
[2] If a responder currently has reasons to prefer using the name, and
it has not seen any other conflicting LLMNR queries within the last
DEFEND_INTERVAL seconds, then it MAY elect to defend its name, by
recording the time that the conflicting LLMNR query was received,
and then sending multicast queries for its UNIQUE resource records,
with the 'U' bit set.
Having done this, an LLMNR responder can then continue to use the
name normally without any further special action. However, if this
is not the first conflicting LLMNR query the responder has seen,
and the time recorded for the previous conflicting LLMNR query is
recent, within DEFEND_INTERVAL, then the LLMNR responder MUST
immediately cease using the conflicting resource records.
This is necessary to ensure that two hosts do not get stuck in an
endless loop with both hosts trying to defend the same name.
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.
Where a host is configured to issue LLMNR queries on more than one Where a host is configured to issue LLMNR queries on more than one
interface, each interface maintains its own independent LLMNR interface, each interface maintains its own independent LLMNR
skipping to change at page 19, line 37 skipping to change at page 21, line 23
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 unicast DNS
when a multi-homed host is connected to two different networks with when a 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.2. 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.
Following the example in Figure 2, an application on 'myhost' issues Following the example in Figure 2, an application on 'myhost' issues
the request getaddrinfo("A", ...) with ai_family=AF_INET6 and the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
skipping to change at page 23, line 5 skipping to change at page 24, line 33
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
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. References 7. Constants
7.1. Normative References The following timing constants are used in this protocol; they are
not intended to be user configurable.
DEFEND_INTERVAL 10 seconds (minimum interval between
defensive LLMNR queries).
JITTER_INTERVAL 100 ms
LLMNR_TIMEOUT 1 second (only if set statically)
RTOinit 500 ms (initial value of LLMNR_TIMEOUT)
RTOmax 5 seconds (maximum value of LLMNR_TIMEOUT)
RTOmin 100 ms (minimum value of LLMNR_TIMEOUT)
8. 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.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 23, line 49 skipping to change at page 25, line 42
[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.
7.2. Informative References 8.2. Informative References
[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested [RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
Fixes", RFC 1536, October 1993. Fixes", RFC 1536, October 1993.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
skipping to change at page 26, line 28 skipping to change at page 28, line 23
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). 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/