draft-ietf-dnsext-mdns-34.txt   draft-ietf-dnsext-mdns-35.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-34.txt> Microsoft <draft-ietf-dnsext-mdns-35.txt> Microsoft
10 August 2004 2 September 2004
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 2, line 8 skipping to change at page 2, line 8
(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
LLMNR only operates on the local link, it cannot be considered a LLMNR only operates on the local link, it cannot be considered a
substitute for DNS. substitute for DNS.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements .................................... 4 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 .............................. 8 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 .............................. 11
2.6 Responder responsibilities ...................... 12 2.6 Responder responsibilities ...................... 12
2.7 Retransmission and jitter ....................... 13 2.7 Retransmission and jitter ....................... 13
2.8 DNS TTL ......................................... 13 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 ........................................... 14
3.1 LLMNR configuration ............................. 15 3.1 LLMNR configuration ............................. 15
4. Conflict resolution ................................... 16 4. Conflict resolution ................................... 17
4.1 Considerations for multiple interfaces .......... 18 4.1 Considerations for multiple interfaces .......... 18
4.2 API issues ...................................... 19 4.2 API issues ...................................... 19
5. Security considerations ............................... 20 5. Security considerations ............................... 20
5.1 Scope restriction ............................... 20 5.1 Scope restriction ............................... 20
5.2 Usage restriction ............................... 21 5.2 Usage restriction ............................... 21
5.3 Cache and port separation ....................... 22 5.3 Cache and port separation ....................... 22
5.4 Authentication .................................. 22 5.4 Authentication .................................. 22
6. IANA considerations ................................... 22 6. IANA considerations ................................... 22
7. References ............................................ 22 7. References ............................................ 22
7.1 Normative References ............................ 22 7.1 Normative References ............................ 22
skipping to change at page 3, line 37 skipping to change at page 3, line 37
sufficient to enable name resolution in small networks. The sufficient to enable name resolution in small networks. The
assumption is that if a network has a gateway, then the network is assumption is that if a network has a gateway, then 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 networking scenarios, resolution might be required for mobile ad-hoc networks.
or where no DNS server is available that is authoritative for the
names of local hosts, and can support dynamic DNS, such as in
wireless hotspots.
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.
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.
skipping to change at page 4, line 27 skipping to change at page 4, line 21
Positively Resolved Positively Resolved
Responses with RCODE set to zero are referred to in this document Responses with RCODE set to zero are referred to in this document
as "positively resolved". as "positively resolved".
Routable Address Routable Address
An address other than a Link-Local address. This includes globally An address other than a Link-Local address. This includes globally
routable addresses, as well as private addresses. routable addresses, as well as private addresses.
Reachable Reachable
An address is considered reachable over a link if either an ARP or An LLMNR responder considers one of its addresses reachable over a
neighbor discovery cache entry exists for the address on the link. link if it will respond to an ARP or Neighbor Discovery query for
that address sent over the link.
Responder Responder
A host that listens to LLMNR queries, and responds to those for A host that listens to LLMNR queries, and responds to those for
which it is authoritative. which it is authoritative.
Sender Sender
A host that sends an LLMNR query. A host that sends an LLMNR query.
UNIQUE
There are some scenarios when multiple responders may respond to
the same query. There are other scenarios when only one responder
may respond to a query. Resource records for which only a single
responder is anticipated are referred to as UNIQUE. Resource
record uniqueness is configured on the responder, and therefore
uniqueness verification is the responder's responsibility.
2. Name resolution using LLMNR 2. Name resolution using LLMNR
LLMNR is a peer-to-peer name resolution protocol that is not intended LLMNR is a peer-to-peer name resolution protocol that is not intended
as a replacement for DNS. LLMNR queries are sent to and received on as a replacement for DNS. LLMNR queries are sent to and received on
port 5355. IPv4 administratively scoped multicast usage is specified port 5355. IPv4 administratively scoped multicast usage is specified
in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link- in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-
scope multicast address a given responder listens to, and to which a scope multicast address a given responder listens to, and to which a
sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast
address a given responder listens to, and to which a sender sends all address a given responder listens to, and to which a sender sends all
queries, is FF02:0:0:0:0:0:1:3. queries, is FF02:0:0:0:0:0:1:3.
skipping to change at page 5, line 23 skipping to change at page 5, line 26
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. If an interface has been configured with DNS performed. If an interface has been configured with DNS
server address(es), then LLMNR SHOULD NOT be used as the server address(es), or if DNS server address(es) have
primary name resolution mechanism on that interface, although been configured which apply to all interfaces, then
it MAY be used as a name resolution mechanism of last resort. LLMNR SHOULD NOT be used as the primary name resolution
mechanism on that interface, although it MAY be used
as a secondary name resolution mechanism.
[2] DNS servers do not respond. [2] DNS servers do not respond.
[3] DNS servers respond to a DNS query with RCODE=3 [3] DNS servers respond to a DNS query with RCODE=3
(Authoritative Name Error) or RCODE=0, and an empty (Authoritative Name Error) or RCODE=0, and an empty
answer section. answer section.
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 do not respond to a
skipping to change at page 6, line 12 skipping to change at page 6, line 19
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 utilizes the DNS packet format defined in [RFC1035] Section 4
for both queries and responses. LLMNR implementations SHOULD send 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 permitted by the link accept UDP queries and responses as large as the smaller of the link
MTU. MTU or 8192 octets.
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 6, line 42 skipping to change at page 6, line 49
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | | ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where: where:
ID A 16 bit identifier assigned by the program that generates any kind ID A 16 bit identifier assigned by the program that generates any kind
of query. This identifier is copied from the query to the response of query. This identifier is copied from the query to the response
and can be used by the sender to match responses to outstanding and can be used by the sender to match responses to outstanding
queries. The ID field in a query SHOULD be set to a pseudo-random queries. The ID field in a query SHOULD be set to a pseudo-random
value. value. For advice on generation of pseudo-random values, please
consult [RFC1750].
QR A one bit field that specifies whether this message is an LLMNR QR A one bit field that specifies whether this message is an LLMNR
query (0), or an LLMNR response (1). query (0), or an LLMNR response (1).
OPCODE OPCODE
A four bit field that specifies the kind of query in this message. A four bit field that specifies the kind of query in this message.
This value is set by the originator of a query and copied into the This value is set by the originator of a query and copied into the
response. This specification defines the behavior of standard response. This specification defines the behavior of standard
queries and responses (opcode value of zero). Future queries and responses (opcode value of zero). Future
specifications may define the use of other opcodes with LLMNR. specifications may define the use of other opcodes with LLMNR.
skipping to change at page 7, line 4 skipping to change at page 7, line 14
QR A one bit field that specifies whether this message is an LLMNR QR A one bit field that specifies whether this message is an LLMNR
query (0), or an LLMNR response (1). query (0), or an LLMNR response (1).
OPCODE OPCODE
A four bit field that specifies the kind of query in this message. A four bit field that specifies the kind of query in this message.
This value is set by the originator of a query and copied into the This value is set by the originator of a query and copied into the
response. This specification defines the behavior of standard response. This specification defines the behavior of standard
queries and responses (opcode value of zero). Future queries and responses (opcode value of zero). Future
specifications may define the use of other opcodes with LLMNR. specifications may define the use of other opcodes with LLMNR.
LLMNR senders and responders MUST support standard queries (opcode LLMNR senders and responders MUST support standard queries (opcode
value of zero). LLMNR queries with unsupported OPCODE values MUST value of zero). LLMNR queries with unsupported OPCODE values MUST
be silently discarded by responders. be silently discarded by responders.
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 an LLMNR response, by an LLMNR responder. If the TC bit is set in an LLMNR response,
then the sender MAY use the response if it contains all necessary then the sender SHOULD discard the response and resend the LLMNR
information, or the sender MAY discard the response and resend the query over TCP using the unicast address of the responder as the
LLMNR query over TCP using the unicast address of the responder as destination address. See [RFC2181] and Section 2.4 of this
the 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.
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.
skipping to change at page 8, line 27 skipping to change at page 8, line 35
record section processing is described in Section 2.9. record section processing is described in Section 2.9.
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.
As described in Section 2.4, a sender may also send a unicast query. As described in Section 2.4, a sender may also send a unicast query.
Sections 2 and 3 describe the circumstances in which LLMNR queries Sections 2 and 3 describe the circumstances in which LLMNR queries
may be sent. may be sent.
The sender MUST anticipate receiving no replies to some LLMNR The sender MUST anticipate receiving no replies to some LLMNR
queries, in the event that no responders are available within the queries, in the event that no responders are available within the
link-scope or in the event no positive non-null responses exist for link-scope or in the event no positive non-null responses exist for
the transmitted query. If no positive response is received, a the transmitted query. If no positive response is received, 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; the sender perceives no inherent conflict in the
receipt of multiple responses.
2.3. Responder behavior 2.3. Responder behavior
An LLMNR response MUST be sent to the sender via unicast. An LLMNR response MUST be sent to the sender via unicast.
Upon configuring an IP address responders typically will synthesize Upon configuring an IP address, responders typically will synthesize
corresponding A, AAAA and PTR RRs so as to be able to respond to corresponding A, AAAA and PTR RRs so as to be able to respond to
LLMNR queries for these RRs. An SOA RR is synthesized only when a LLMNR queries for these RRs. An SOA RR is synthesized only when a
responder has another RR as well; the SOA RR MUST NOT be the only RR responder has another RR as well; the SOA RR MUST NOT be the only RR
that a responder has. However, in general whether RRs are manually that a responder has. However, in general whether RRs are manually
or automatically created is an implementation decision. 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:
skipping to change at page 9, line 23 skipping to change at page 9, line 39
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
IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
1.2.0.192.in-addr.arpa. IN PTR host1. 1.2.0.192.in-addr.arpa. IN PTR host1.
IN PTR host1.example.com. IN PTR host1.example.com.
6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2. 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
ip6.arpa IN PTR host1. ip6.arpa IN PTR host1. (line split for formatting reasons)
IN PTR host1.example.com. IN PTR host1.example.com.
An LLMNR responder might be further manually configured with the name An LLMNR responder might be further manually configured with the name
of a local mail server with an MX RR included in the "host1." and of a local mail server with an MX RR included in the "host1." and
"host1.example.com." records. "host1.example.com." records.
In responding to queries: In responding to queries:
[a] Responders MUST listen on UDP port 5355 on the link-scope multicast [a] Responders MUST listen on UDP port 5355 on the link-scope multicast
address(es) defined in Section 2, and on UDP and TCP port 5355 on address(es) defined in Section 2, and on UDP and TCP port 5355 on
the unicast address(es) that could be set as the source address(es) the unicast address(es) that could be set as the source address(es)
when the responder responds to the LLMNR query. when the responder responds to the LLMNR query.
[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 SHOULD 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.
[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 cached data. [e] Responders MUST NOT respond using data from the LLMNR or DNS
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
for other records for which the server is authoritative. DNS for other records for which the server is authoritative. DNS
servers also MUST NOT send LLMNR queries in order to resolve DNS servers also MUST NOT send LLMNR queries in order to resolve DNS
queries. queries.
[g] If a responder is authoritative for a name, it MAY respond with [g] If a responder is authoritative for a name, it SHOULD respond with
RCODE=0 and an empty answer section, if the type of query does not RCODE=0 and an empty answer section, if the type of query does not
match a RR that the responder has. match a RR that the responder has.
As an example, a host configured to respond to LLMNR queries for the As an example, a host configured to respond to LLMNR queries for the
name "foo.example.com." is authoritative for the name name "foo.example.com." is authoritative for the name
"foo.example.com.". On receiving an LLMNR query for an A RR with the "foo.example.com.". On receiving an LLMNR query for an A RR with the
name "foo.example.com." the host authoritatively responds with A name "foo.example.com." the host authoritatively responds with A
RR(s) that contain IP address(es) in the RDATA of the resource RR(s) that contain IP address(es) in the RDATA of the resource
record. If the responder has a AAAA RR, but no A RR, and an A RR record. If the responder has a AAAA RR, but no A RR, and an A RR
query is received, the responder would respond with RCODE=0 and an query is received, the responder would respond with RCODE=0 and an
skipping to change at page 11, line 36 skipping to change at page 11, line 51
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 For IPv4, an "on link" address is defined as a link-local address
[IPv4Link] or an address whose prefix belongs to a subnet on the [IPv4Link] or an address whose prefix belongs to a subnet on the
local link. For IPv6 [RFC2460] an "on link" address is either a local link. For IPv6 [RFC2460] an "on link" address is either a
link-local address, defined in [RFC2373], or an address whose prefix link-local address, defined in [RFC2373], or one belonging to a
belongs to a subnet on the local link. prefix that a Router Advertisement indicates is on-link [RFC2461].
A sender MUST select a source address for LLMNR queries that is "on 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- link". The destination address of an LLMNR query MUST be a link-
scope multicast address or an "on link" unicast address. 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 "on
link". The destination address of an LLMNR response MUST be an "on link". The destination address of an LLMNR response MUST be an "on
link" unicast address. link" 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
skipping to change at page 12, line 14 skipping to change at page 12, line 28
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
settings on the TCP listen socket to one (1) so that SYN-ACK packets settings on the TCP listen socket to one (1) so that SYN-ACK packets
will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
prevents an incoming connection from off-link since the sender will prevents an incoming connection from off-link since the sender will
not receive a SYN-ACK from the responder. not receive a SYN-ACK from the responder.
For UDP queries and responses the Hop Limit field in the IPv6 header, For UDP queries and responses, the Hop Limit field in the IPv6 header
and the TTL field in the IPV4 header MAY be set to any value. and the TTL field in the IPV4 header MAY be set to any value.
However, it is RECOMMENDED that the value 255 be used for However, it is RECOMMENDED that the value 255 be used for
compatibility with Apple Rendezvous. compatibility with Apple Rendezvous.
Implementation note: Implementation note:
In the sockets API for IPv4 [POSIX], the IP_TTL and In the sockets API for IPv4 [POSIX], the IP_TTL and
IP_MULTICAST_TTL socket options are used to set the TTL of IP_MULTICAST_TTL socket options are used to set the TTL of
outgoing unicast and multicast packets. The IP_RECVTTL socket outgoing unicast and multicast packets. The IP_RECVTTL socket
option is available on some platforms to retrieve the IPv4 TTL of option is available on some platforms to retrieve the IPv4 TTL of
skipping to change at page 13, line 12 skipping to change at page 13, line 24
available. This encourages use of routable address(es) for available. This encourages use of routable address(es) for
establishment of new connections. establishment of new connections.
2.7. Retransmission and jitter 2.7. Retransmission and jitter
An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
when to retransmit an LLMNR query and how long to collect responses when to retransmit an LLMNR query and how long to collect responses
to an LLMNR query. to an LLMNR query.
If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
then a sender MAY 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.
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. It is suggested that the computation of for each transmission. For example, the algorithms described in RFC
LLMNR_TIMEOUT be based on the response times for earlier LLMNR 2988 [RFC2988] (including exponential backoff) compute an RTO, which
queries sent on the same interface. 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 example, the algorithms described in RFC 2988 [RFC2988] 2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph
(including exponential backoff) compute an RTO, which is used as the 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988],
value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial paragraph 2.5). Recommended values are an initial RTO of 500ms, a
RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum minimum RTO of 100ms, and a maximum RTO of 5 seconds.
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 are an initial RTO of 1 second, a minimum RTO of In order to avoid synchronization, the transmission of each LLMNR
200ms, and a maximum RTO of 5 seconds. In order to avoid query and response SHOULD delayed by a time randomly selected from
synchronization, the transmission of each LLMNR query and response the interval 0 to 100 ms. This delay MAY be avoided by responders
SHOULD delayed by a time randomly selected from the interval 0 to 100 responding with RRs which they have previously determined to be
ms. This delay MAY be avoided by responders responding with RRs UNIQUE (see Section 4 for details).
which they have previously determined to be UNIQUE (see Section 4 for
details).
2.8. DNS TTL 2.8. DNS TTL
The responder should use a pre-configured TTL value in the records The responder should insert a pre-configured TTL value in the records
returned 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.
2.9. Use of the authority and additional sections 2.9. Use of the authority and additional sections
Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
concept of delegation. In LLMNR, the NS resource record type may be concept of delegation. In LLMNR, the NS resource record type may be
skipping to change at page 14, line 23 skipping to change at page 14, line 32
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.
Responders SHOULD NOT perform DNS additional section processing, In LLMNR, the additional section is only intended for use by EDNS0,
except as required for EDNS0 and DNSSEC. TSIG and SIG(0). As a result, senders MAY only include pseudo RR-
types in the additional section of a query; responders MUST ignore
the additional section of queries containing other RR types.
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 15, line 42 skipping to change at page 16, line 6
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.
For example, if the configured DNS server responds to AAAA RR queries For example, if the configured DNS server responds to all AAAA RR
sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), queries sent over IPv4 or IPv6 with an authoritative name error
then it will not be possible to resolve the names of IPv6-only hosts. (RCODE=3), then it will not be possible to resolve the names of
In this situation, LLMNR over IPv6 can be used for local name IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for
resolution. local name resolution.
Similarly, if a DHCPv4 server is available providing DNS server Similarly, if a DHCPv4 server is available providing DNS server
configuration, and DNS server(s) exist which are authoritative for configuration, and DNS server(s) exist which are authoritative for
the A RRs of local hosts and support either dynamic client update the A RRs of local hosts and support either dynamic client update
over IPv4 or DHCPv4-based dynamic update, then the names of local over IPv4 or DHCPv4-based dynamic update, then the names of local
IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no
DNS server is authoritative for the names of local hosts, or the DNS server is authoritative for the names of local hosts, or the
authoritative DNS server(s) do not support dynamic update, then LLMNR authoritative DNS server(s) do not support dynamic update, then LLMNR
enables linklocal name resolution over IPv4. enables linklocal name resolution over IPv4.
skipping to change at page 16, line 31 skipping to change at page 16, line 43
an administrative domain to be inconsistent in their DNS an administrative domain to be inconsistent in their DNS
configuration. configuration.
For example, where DHCP is used for configuring DNS servers, one or For example, where DHCP is used for configuring DNS servers, one or
more DHCP servers can fail. As a result, hosts configured prior to more DHCP servers can fail. As a result, hosts configured prior to
the outage will be configured with a DNS server, while hosts the outage will be configured with a DNS server, while hosts
configured after the outage will not. Alternatively, it is possible configured after the outage will not. Alternatively, it is possible
for the DNS configuration mechanism to continue functioning while for the DNS configuration mechanism to continue functioning while
configured DNS servers fail. configured DNS servers fail.
Unless unconfigured hosts periodically retry configuration, an outage An outage in the DNS configuration mechanism may result in hosts
in the DNS configuration mechanism will result in hosts continuing to continuing to use LLMNR even once the outage is repaired. Since
use LLMNR even once the outage is repaired. Since LLMNR only enables LLMNR only enables linklocal name resolution, this represents a
linklocal name resolution, this represents an unnecessary degradation degradation in capabilities. As a result, hosts without a configured
in capabilities. As a result, it is recommended that hosts without a DNS server may wish to periodically attempt to obtain DNS
configured DNS server periodically attempt to obtain DNS configuration if permitted by the configuration mechanism in use. In
configuration. For example, where DHCP is used for DNS the absence of other guidance, a default retry interval of one (1)
configuration, [RFC2131] recommends a maximum retry interval of 64 minute is RECOMMENDED.
seconds. In the absence of other guidance, a default retry interval
of one (1) minute is RECOMMENDED.
4. Conflict resolution 4. Conflict resolution
The sender MUST anticipate receiving multiple replies to the same The uniqueness of a resource record depends on the nature of the name
LLMNR query, in the event that several LLMNR enabled computers in the query and type of the query. For example it is expected that:
receive the query and respond with valid answers. When this occurs,
the responses may first be concatenated, and then treated in the same
manner that multiple RRs received from the same DNS server would; the
sender perceives no inherent conflict in the receipt of multiple
responses.
There are some scenarios when multiple responders MAY respond to the
same query. There are other scenarios when only one responder MAY
respond to a query. Resource records for which the latter queries
are submitted are referred as UNIQUE throughout this document. The
uniqueness of a resource record depends on a nature of the name in
the query and type of the query. For example it is expected that:
- multiple hosts may respond to a query for an SRV type record - 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.
Every responder that responds to an LLMNR query AND includes a UNIQUE By default, a responder SHOULD be configured to behave as though all
record in the response: RRs are UNIQUE on each interface on which LLMNR is enabled. Prior to
including a UNIQUE resource record in a response, for each UNIQUE
[1] MUST verify that there is no other host within the resource record in a given interface's configuration, the host MUST
scope of the LLMNR query propagation that can return verify that there is no other host within the scope of LLMNR query
a resource record for the same name, type and class. propagation that can return a resource record for the same name, type
and class on that interface. Once a responder has verified the
[2] MUST NOT include a UNIQUE resource record in the uniqueness of a UNIQUE resource record, if it receives an LLMNR query
response without having verified its uniqueness. for that resource record, it MUST respond.
Where a host is configured to issue LLMNR queries on more than one To verify uniqueness, a responder MUST send an LLMNR query for each
interface, each interface should have its own independent LLMNR UNIQUE resource record. If no response is received after a suitable
cache. For each UNIQUE resource record in a given interface's number of attempts (see Section 2.7), the responder can use the
configuration, the host MUST verify resource record uniqueness on UNIQUE resource record in response to LLMNR queries. If a response
that interface. To accomplish this, the host MUST send an LLMNR is received, the responder MUST check whether the response arrived on
query for each UNIQUE resource record. an interface different from the one on which the query was sent. If
the response arrives on a different interface, the responder can use
the UNIQUE resource record in response to LLMNR queries. If not,
then it MUST NOT use the UNIQUE resource record in response to LLMNR
queries.
By default, a host SHOULD be configured to behave as though all RRs Uniqueness verification is carried out when the host:
are UNIQUE. 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 the 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 the LLMNR queries using additional - is configured to respond to LLMNR queries using additional
UNIQUE resource records UNIQUE resource records
- detects that an interface is connected and is usable - verifies the acquisition of a new IP address and configuration
(e.g. an IEEE 802 hardware link-state change indicating on an interface
that a cable was attached or completion of authentication
(and if needed, association) with a wireless base station
or adhoc network
When a host that has a UNIQUE record receives an LLMNR query for that
record, the host MUST respond. After the client receives a response,
it MUST check whether the response arrived on an interface different
from the one on which the query was sent. If the response arrives on
a different interface, the client can use the UNIQUE resource record
in response to LLMNR queries. If not, then it MUST NOT use the
UNIQUE resource record in response to LLMNR queries.
The name conflict detection mechanism doesn't prevent name conflicts The name conflict detection mechanism doesn't prevent name conflicts
when previously partitioned segments are connected by a bridge. In when previously partitioned segments are connected by a bridge. In
order to minimize the chance of conflicts in such a situation, it is order to minimize the chance of conflicts in such a situation, it is
recommended that steps be taken to ensure name uniqueness. For recommended that steps be taken to ensure name uniqueness. For
example, the name could be chosen randomly from a large pool of example, the name could be chosen randomly from a large pool of
potential names, or the name could be assigned via a process designed potential names, or the name could be assigned via a process designed
to guarantee uniqueness. to guarantee uniqueness.
When name conflicts are detected, they SHOULD be logged. To detect When name conflicts are detected, they SHOULD be logged. To detect
skipping to change at page 18, line 35 skipping to change at page 18, line 25
4.1. Considerations for Multiple Interfaces 4.1. 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
interface, each interface maintains its own independent LLMNR
resolver cache, containing the responses to LLMNR queries.
A multi-homed host checks the uniqueness of UNIQUE records as A multi-homed host checks the uniqueness of UNIQUE records as
described in Section 4. The situation is illustrated in figure 1. described in Section 4. The situation is illustrated in figure 1.
---------- ---------- ---------- ----------
| | | | | | | |
[A] [myhost] [myhost] [A] [myhost] [myhost]
Figure 1. Link-scope name conflict Figure 1. Link-scope name conflict
In this situation, the multi-homed myhost will probe for, and defend, In this situation, the multi-homed myhost will probe for, and defend,
skipping to change at page 22, line 22 skipping to change at page 22, line 19
LLMNR on each interface. The use of separate caches is most effective LLMNR on each interface. The use of separate caches is most effective
when LLMNR is used as a name resolution mechanism of last resort, when LLMNR is used as a name resolution mechanism of last resort,
since this minimizes the opportunities for poisoning the LLMNR cache, since this minimizes the opportunities for poisoning the LLMNR cache,
and decreases reliance on it. 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 not support DNSSEC or TSIG, and as a LLMNR implementations MAY support TSIG and/or SIG(0) security
result, responses to LLMNR queries may be unauthenticated. If mechanisms. Since LLMNR does not support "delegated trust" (CD or AD
authentication is desired, and a pre-arranged security configuration bits), and LLMNR senders are unlikely to be DNSSEC-aware, in practice
is possible, then IPsec ESP with a null-transform MAY be used to LLMNR is not compatible with DNSSEC.
authenticate LLMNR responses. In a small network without a
certificate authority, this can be most easily accomplished through Since LLMNR implementations MAY NOT support TSIG or SIG(0), responses
configuration of a group pre-shared key for trusted hosts. to LLMNR queries may be unauthenticated. If authentication is
desired, and a pre-arranged security configuration is possible, then
IPsec ESP with a null-transform MAY be used to authenticate unicast
LLMNR queries and responses or LLMNR responses to multicast queries.
In a small network without a certificate authority, this can be most
easily 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 23, line 27 skipping to change at page 23, line 30
[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 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (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.
7.2. Informative References 7.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
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.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997. April 1997.
[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", [RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
RFC 2292, February 1998. RFC 2292, February 1998.
 End of changes. 

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