draft-ietf-dnsext-mdns-19.txt   draft-ietf-dnsext-mdns-20.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-19.txt> Microsoft <draft-ietf-dnsext-mdns-20.txt> Microsoft
12 May 2003 21 May 2003
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 8 skipping to change at page 2, line 8
Today, with the rise of home networking, there are an increasing number Today, with the rise of home networking, there are an increasing number
of ad-hoc networks operating without a Domain Name System (DNS) server. of ad-hoc networks operating without a Domain Name System (DNS) server.
In order to allow name resolution in such environments, Link-Local In order to allow name resolution in such environments, Link-Local
Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all
current and future DNS formats, types and classes, while operating on a current and future DNS formats, types and classes, while operating on a
separate port from DNS, and with a distinct resolver cache. separate port from DNS, and with a distinct resolver cache.
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 Sender behavior ................................. 5 2.1 Sender behavior ................................. 4
2.2 Responder behavior .............................. 5 2.2 Responder behavior .............................. 5
2.3 Unicast queries ................................. 6 2.3 Unicast queries ................................. 6
2.4 Addressing ...................................... 7 2.4 Addressing ...................................... 7
2.5 Off-link detection .............................. 8 2.5 Off-link detection .............................. 7
2.6 Retransmissions ................................. 8 2.6 Retransmissions ................................. 8
2.7 DNS TTL ......................................... 9 2.7 DNS TTL ......................................... 9
3. Usage model ........................................... 9 3. Usage model ........................................... 9
3.1 Unqualified names ............................... 10 3.1 Unqualified names ............................... 10
3.2 LLMNR configuration ............................. 10 3.2 LLMNR configuration ............................. 10
4. Conflict resolution ................................... 12 4. Conflict resolution ................................... 12
4.1 Considerations for multiple interfaces .......... 13 4.1 Considerations for multiple interfaces .......... 13
4.2 API issues ...................................... 14 4.2 API issues ...................................... 14
5. Security considerations ............................... 15 5. Security considerations ............................... 15
5.1 Scope restriction ............................... 15 5.1 Scope restriction ............................... 15
5.2 Usage restriction ............................... 16 5.2 Usage restriction ............................... 16
5.3 Cache and port separation ....................... 17 5.3 Cache and port separation ....................... 16
5.4 Authentication .................................. 17 5.4 Authentication .................................. 17
6. IANA considerations ................................... 17 6. IANA considerations ................................... 17
7. Normative References .................................. 17 7. Normative References .................................. 17
8. Informative References ................................ 18 8. Informative References ................................ 18
Acknowledgments .............................................. 19 Acknowledgments .............................................. 19
Authors' Addresses ........................................... 19 Authors' Addresses ........................................... 19
Intellectual Property Statement .............................. 20 Intellectual Property Statement .............................. 20
Full Copyright Statement ..................................... 20 Full Copyright Statement ..................................... 20
1. Introduction 1. Introduction
skipping to change at page 3, line 28 skipping to change at page 3, line 28
they respond with errors, as described in Section 3. they respond with errors, as described in Section 3.
LLMNR queries are sent to and received on port TBD. Link-scope LLMNR queries are sent to and received on port TBD. Link-scope
multicast addresses are used to prevent propagation of LLMNR traffic multicast addresses are used to prevent propagation of LLMNR traffic
across routers, potentially flooding the network; for details, see across routers, potentially flooding the network; for details, see
Section 2.4. LLMNR queries can also be sent to a unicast address, as Section 2.4. LLMNR queries can also be sent to a unicast address, as
described in Section 2.3. described in Section 2.3.
Propagation of LLMNR packets on the local link is considered sufficient Propagation of LLMNR packets on the local link is considered sufficient
to enable name resolution in small networks. The assumption is that if to enable name resolution in small networks. The assumption is that if
a network has a home gateway, then the network either has DNS and DHCPv4 a network has a home gateway, then the network is able to provide DNS
servers or the home gateway provides DHCPv4 and DNS server server configuration and a DNS server is available that is authoritative
functionality. By providing Dynamic Host Configuration Service for for the names of local hosts and can support dynamic DNS. Configuration
IPv4 (DHCPv4), as well as a DNS server with support for dynamic DNS, issues are discussed in Section 3.2.
which is also authoritative for the A RRs of local hosts, it is possible
to support resolution of local host names over IPv4.
For small IPv6 networks, equivalent functionality can be provided by
implementing Dynamic Host Configuration Service for IPv6 (DHCPv6) for
DNS configuration [DHCPv6DNS], as well providing a DNS server with
support for dynamic DNS, which is also authoritative for the AAAA RRs of
local hosts, it is possible to support the resolution of local host
names over IPv6 as well as IPv4.
In the future, LLMNR may be defined to support greater than link-scope In the future, LLMNR may be defined to support greater than link-scope
multicast. This would occur if LLMNR deployment is successful, the multicast. This would occur if LLMNR deployment is successful, the
assumption that LLMNR is not needed on multiple links proves incorrect, assumption that LLMNR is not needed on multiple links proves incorrect,
and multicast routing becomes ubiquitous. For example, it is not clear and multicast routing becomes ubiquitous. For example, it is not clear
that this assumption will be valid in large ad hoc networking scenarios. that this assumption will be valid in large ad hoc networking scenarios.
Once we have experience in LLMNR deployment in terms of administrative Once we have experience in LLMNR deployment in terms of administrative
issues, usability and impact on the network it will be possible to issues, usability and impact on the network it will be possible to
reevaluate which multicast scopes are appropriate for use with multicast reevaluate which multicast scopes are appropriate for use with multicast
skipping to change at page 5, line 33 skipping to change at page 5, line 22
2.2. Responder behavior 2.2. Responder behavior
A responder MUST listen on UDP port TBD on the link-scope multicast A responder MUST listen on UDP port TBD on the link-scope multicast
address(es) and on UDP and TCP port TBD on the unicast address(es) that address(es) and on UDP and TCP port TBD on the unicast address(es) that
could be set as the source address(es) when the responder responds to could be set as the source address(es) when the responder responds to
the LLMNR query. A host configured as a responder MUST act as a sender the LLMNR query. A host configured as a responder MUST act as a sender
to verify the uniqueness of names as described in Section 4. to verify the uniqueness of names as described in Section 4.
Responders MUST NOT respond to LLMNR queries for names they are not Responders MUST NOT respond to LLMNR queries for names they are not
authoritative for, except in the event of a discovered conflict, as authoritative for. Responders SHOULD respond to LLMNR queries for names
described in Section 4. Responders SHOULD respond to LLMNR queries for and addresses they are authoritative for. This applies to both forward
names and addresses they are authoritative for. This applies to both and reverse lookups.
forward and reverse lookups.
As an example, a computer "host.example.com." configured to respond to As an example, a computer "host.example.com." configured to respond to
LLMNR queries is authoritative for the name "host.example.com.". On LLMNR queries is authoritative for the name "host.example.com.". On
receiving an LLMNR A/AAAA resource record query for the name receiving an LLMNR A/AAAA resource record query for the name
"host.example.com." the host authoritatively responds with A/AAAA "host.example.com." the host authoritatively responds with A/AAAA
record(s) that contain IP address(es) in the RDATA of the resource record(s) that contain IP address(es) in the RDATA of the resource
record. record.
If a responder is authoritative for a name, it MAY respond with RCODE=0 If a responder is authoritative for a name, it MAY respond with RCODE=0
and an empty answer section, if the type of query does not match a RR and an empty answer section, if the type of query does not match a RR
skipping to change at page 9, line 16 skipping to change at page 8, line 50
responding to it. Since a multicast query sender cannot know beforehand responding to it. Since a multicast query sender cannot know beforehand
whether it will receive no response, one response, or more than one whether it will receive no response, one response, or more than one
response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all
possible responses, rather than considering the multicast query answered possible responses, rather than considering the multicast query answered
after the first response is received. A unicast query sender considers after the first response is received. A unicast query sender considers
the query answered after the first response is received, so that it only the query answered after the first response is received, so that it only
waits for LLMNR_TIMEOUT if no response has been received. waits for LLMNR_TIMEOUT if no response has been received.
LLMNR implementations SHOULD dynamically estimate the timeout value LLMNR implementations SHOULD dynamically estimate the timeout value
(LLMNR_TIMEOUT) based on the last response received, on a per-interface (LLMNR_TIMEOUT) based on the last response received, on a per-interface
basis, using the algorithms described in [RFC2988], with a minimum basis. The algorithms described in [RFC2988] are suggested, with a
timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD
attempted more than 3 times. Where LLMNR queries are sent using TCP, NOT be attempted more than 3 times. Where LLMNR queries are sent using
retransmission is handled by the transport layer.
TCP, retransmission is handled by the transport layer.
2.7. DNS TTL 2.7. DNS TTL
The responder should use a pre-configured TTL value in the records The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response. Due to the TTL minimalization returned in the LLMNR query response. Due to the TTL minimalization
necessary when caching an RRset, all TTLs in an RRset MUST be set to the necessary when caching an RRset, all TTLs in an RRset MUST be set to the
same value. In the additional and authority section of the response the same value. In the additional and authority section of the response the
responder includes the same records as a DNS server would insert in the responder includes the same records as a DNS server would insert in the
response to the unicast DNS query. response to the unicast DNS query.
skipping to change at page 10, line 48 skipping to change at page 10, line 35
[1] Request the name with the current domain appended. [1] Request the name with the current domain appended.
[2] Request just the name. [2] Request just the name.
This is the behavior suggested by [RFC1536]. LLMNR uses this technique This is the behavior suggested by [RFC1536]. LLMNR uses this technique
to resolve unqualified host names. to resolve unqualified host names.
3.2. LLMNR configuration 3.2. LLMNR configuration
LLMNR usage MAY be configured manually or automatically on a per LLMNR usage MAY be configured manually or automatically on a per
interface basis. By default, LLMNR responders SHOULD be enabled on all interface basis. By default, LLMNR Responders SHOULD be enabled on all
interfaces, at all times. interfaces, at all times.
Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
possible for a dual stack host to be configured with the address of a possible for a dual stack host to be configured with the address of a
DNS server over IPv4, while remaining unconfigured with a DNS server DNS server over IPv4, while remaining unconfigured with a DNS server
suitable for use over IPv6. In these situations, a dual stack host will suitable for use over IPv6.
send AAAA queries to the configured DNS server over IPv4.
However, an IPv6-only host unconfigured with a DNS server suitable for In these situations, a dual stack host will send AAAA queries to the
use over IPv6 will be unable to resolve names using DNS. Since configured DNS server over IPv4. However, an IPv6-only host
automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and unconfigured with a DNS server suitable for use over IPv6 will be unable
[DNSDisc]) are not yet widely deployed, and not all DNS servers support to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms
IPv6, lack of IPv6 DNS configuration may be a common problem in the (such as [DHCPv6DNS] and [DNSDisc]) are not yet widely deployed, and not
short term, and LLMNR may prove useful in enabling linklocal name all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration
resolution over IPv6. may be a common problem in the short term, and LLMNR may prove useful in
enabling linklocal name resolution over IPv6.
For example, a home network may provide a DHCPv4 server but may not Where a DHCPv4 server is available but not a DHCPv6 server [DHCPv6DNS],
support DHCPv6 for DNS configuration [DHCPv6DNS]. In such a IPv6-only hosts may not be configured with a DNS server. Where there is
circumstance, IPv6-only hosts will not be configured with a DNS server. no DNS server authoritative for the names of hosts on the local network
Where a DNS server is configured but does not support dynamic client or the authoritative DNS server does not support dynamic client update
update over IPv6 or DHCPv6-based dynamic update, hosts on the home over IPv6 or DHCPv6-based dynamic update, hosts on the home network will
network will not be able to dynamically register or resolve the names of not be able to dynamically register or resolve the names of local IPv6
local IPv6 hosts. If the configured DNS server responds to AAAA RR hosts. For example, if the configured DNS server responds to AAAA RR
queries sent over IPv4 or IPv6 with an authoritative name error queries sent over IPv4 or IPv6 with an authoritative name error
(RCODE=3), then it will not be possible to resolve the names of (RCODE=3), then it will not be possible to resolve the names of
IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for
local name resolution. local name resolution.
Similarly, if a DHCPv4 server is available providing DNS server
configuration, and the DNS server authoritative for the A RRs of local
hosts also supports either dynamic client update over IPv4 or
DHCPv4-based dynamic update, then resolution of the names of local IPv4
hosts can be provided over IPv4 without LLMNR. However, if there is no
DNS server authoritative for the names of local hosts, or the
authoritative DNS server does not support dynamic update, then LLMNR may
prove useful in enabling linklocal name resoltion over IPv4.
Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
configure LLMNR on an interface. The LLMNR Enable Option, described in configure LLMNR on an interface. The LLMNR Enable Option, described in
[LLMNREnable], can be used to explicitly enable or disable use of LLMNR [LLMNREnable], can be used to explicitly enable or disable use of LLMNR
on an interface. The LLMNR Enable Option does not determine whether or on an interface. The LLMNR Enable Option does not determine whether or
in which order DNS itself is used for name resolution. The order in in which order DNS itself is used for name resolution. The order in
which various name resolution mechanisms should be used can be specified which various name resolution mechanisms should be used can be specified
using the Name Service Search Option for DHCP [RFC2937]. using the Name Service Search Option for DHCP [RFC2937].
3.2.1. Configuration consistency
It is possible that DNS configuration mechanisms will go in and out of It is possible that DNS configuration mechanisms will go in and out of
service. In these circumstances, it is possible for hosts within an service. In these circumstances, it is possible for hosts within an
administrative domain to be inconsistent in their DNS configuration. administrative domain to be inconsistent in their DNS configuration.
For example, where DHCP is used for configuring DNS servers, one or more For example, where DHCP is used for configuring DNS servers, one or more
DHCP servers can go down. As a result, hosts configured prior to the DHCP servers can fail. As a result, hosts configured prior to the
outage will be configured with a DNS server, while hosts configured outage will be configured with a DNS server, while hosts configured
after the outage will not. Alternatively, it is possible for the DNS after the outage will not. Alternatively, it is possible for the DNS
configuration mechanism to continue functioning while configured DNS configuration mechanism to continue functioning while configured DNS
servers fail. servers fail.
Unless unconfigured hosts periodically retry configuration, an outage in Unless unconfigured hosts periodically retry configuration, an outage in
the DNS configuration mechanism will result in hosts continuing to the DNS configuration mechanism will result in hosts continuing to use
prefer LLMNR even once the outage is repaired. Since LLMNR only enables LLMNR even once the outage is repaired. Since LLMNR only enables
linklocal name resolution, this represents an unnecessary degradation in linklocal name resolution, this represents an unnecessary degradation in
capabilities. As a result, it is recommended that hosts without a capabilities. As a result, it is recommended that hosts without a
configured DNS server periodically attempt to obtain DNS configuration. configured DNS server periodically attempt to obtain DNS configuration.
A default retry interval of two (2) minutes is RECOMMENDED. A default retry interval of two (2) minutes is RECOMMENDED.
4. Conflict resolution 4. Conflict resolution
The sender MUST anticipate receiving multiple replies to the same LLMNR The sender MUST anticipate receiving multiple replies to the same LLMNR
query, in the event that several LLMNR enabled computers receive the query, in the event that several LLMNR enabled computers receive the
query and respond with valid answers. When this occurs, the responses query and respond with valid answers. When this occurs, the responses
skipping to change at page 13, line 12 skipping to change at page 13, line 4
By default, a host SHOULD be configured to behave as though all RRs are By default, a host SHOULD be configured to behave as though all RRs are
UNIQUE. Uniqueness verification is carried out when the host: UNIQUE. Uniqueness verification is carried out when the host:
- starts up or - starts up or
- is configured to respond to the LLMNR queries on an interface or - is configured to respond to the LLMNR queries on an interface or
- is configured to respond to the LLMNR queries using additional - is configured to respond to the LLMNR queries using additional
UNIQUE resource records. UNIQUE resource records.
When a host that owns a UNIQUE record receives an LLMNR query for that When a host that owns a UNIQUE record receives an LLMNR query for that
record, the host MUST respond. After the client receives a response, it record, the host MUST respond. After the client receives a response, it
MUST check whether the response arrived on another interface. If this MUST check whether the response arrived on another interface. If this
is the case, then the client can use the UNIQUE resource record in is the case, then the client can use the UNIQUE resource record in
response to LLMNR queries. If not, then it MUST NOT use the UNIQUE response to LLMNR queries. If not, then it MUST NOT use the UNIQUE
resource record in response to LLMNR queries. 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 such when previously partitioned segments are connected by a bridge. In order
a situation, name conflicts are detected when a sender receives more to minimize the chance of conflicts in such a situation, it is
than one response to its LLMNR multicast query. In this case, the recommended that steps be taken to ensure hostname uniqueness. For
sender sends the first response that it received to all responders that example, the hostname could be chosen randomly from a large pool of
responded to this query except the first one, using UDP unicast. A host potential names, or the hostname could be assigned via a process
that receives a query response containing a UNIQUE resource record that designed to guarantee uniqueness.
it owns, even if it didn't send such a query, MUST verify that no other
host within the LLMNR scope is authoritative for the same name, using
the mechanism described above. Based on the result, the host detects
whether there is a name conflict and acts accordingly.
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. However, active interfaces. In many situations this will be adequate. However,
should a host need to configure LLMNR on more than one of its active should a host need to configure LLMNR on more than one of its active
interfaces, there are some additional precautions it MUST take. interfaces, there are some additional precautions it MUST take.
Implementers who are not planning to support LLMNR on multiple Implementers who are not planning to support LLMNR on multiple
interfaces simultaneously may skip this section. interfaces simultaneously may skip this section.
skipping to change at page 14, line 22 skipping to change at page 14, line 16
| | | | | | | |
[A] [myhost] [A] [A] [myhost] [A]
Figure 2. Off-segment name conflict Figure 2. Off-segment name conflict
If host myhost is configured to use LLMNR on both interfaces, it will If host myhost is configured to use LLMNR on both interfaces, it will
send LLMNR queries on both interfaces. When host myhost sends a query send LLMNR queries on both interfaces. When host myhost sends a query
for the host RR for name "A" it will receive a response from hosts on for the host RR for name "A" it will receive a response from hosts on
both interfaces. both interfaces.
Host myhost will then send the first responder's response to the second
responder, who will attempt to verify the uniqueness of host RR for its
name, but will not discover a conflict, since the conflicting host
resides on a different link. Therefore it will continue using its name.
Host myhost cannot distinguish between the situation shown in Figure 2, Host myhost cannot distinguish between the situation shown in Figure 2,
and that shown in Figure 3 where no conflict exists. and that shown in Figure 3 where no conflict exists.
[A] [A]
| | | |
----- ----- ----- -----
| | | |
[myhost] [myhost]
Figure 3. Multiple paths to same host Figure 3. Multiple paths to same host
skipping to change at page 21, line 14 skipping to change at page 21, line 14
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
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dnsext-mdns-19.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-20.txt>, and expires
November 22, 2003. November 22, 2003.
 End of changes. 

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