draft-ietf-dnsext-mdns-18.txt   draft-ietf-dnsext-mdns-19.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-18.txt> Microsoft <draft-ietf-dnsext-mdns-19.txt> Microsoft
1 May 2003 12 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 1, line 36 skipping to change at page 1, line 36
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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
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 Service (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 .................................... 4
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 ................................. 5
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 .............................. 7 2.5 Off-link detection .............................. 8
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 ................................... 11 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 ....................... 16 5.3 Cache and port separation ....................... 17
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
This document discusses Link Local Multicast Name Resolution (LLMNR), This document discusses Link Local Multicast Name Resolution (LLMNR),
which operates on a separate port from DNS, with a distinct resolver which operates on a separate port from the Domain Name System (DNS),
cache, but does not change the format of DNS packets. LLMNR supports with a distinct resolver cache, but does not change the format of DNS
all current and future DNS formats, types and classes. However, since packets. LLMNR supports all current and future DNS formats, types and
LLMNR only operates on the local link, it cannot be considered a classes. However, since LLMNR only operates on the local link, it
substitute for DNS. cannot be considered a substitute for DNS.
The goal of LLMNR is to enable name resolution in scenarios in which The goal of LLMNR is to enable name resolution in scenarios in which
conventional DNS name resolution is not possible. These include conventional DNS name resolution is not possible. These include
scenarios in which hosts are not configured with the address of a DNS scenarios in which hosts are not configured with the address of a DNS
server, where configured DNS servers do not reply to a query, or where server, where configured DNS servers do not reply to a query, or where
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 a DNS server a network has a home gateway, then the network either has DNS and DHCPv4
or the home gateway can function as a DNS proxy. By implementing servers or the home gateway provides DHCPv4 and DNS server
Dynamic Host Configuration Service for IPv4 (DHCPv4) as well as a DNS functionality. By providing Dynamic Host Configuration Service for
proxy and dynamic DNS, home gateways can provide name resolution for the IPv4 (DHCPv4), as well as a DNS server with support for dynamic DNS,
names of hosts over IPv4 on the local network. 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 a
home gateway implementing Dynamic Host Configuration Service for IPv6
(DHCPv6) for DNS configuration [DHCPv6DNS], as well as a DNS proxy
supporting AAAA RRs and dynamic DNS, providing name resolution for the
names of hosts over IPv6 on the local network.
This should be adequate as long as home gateways implementing DNS For small IPv6 networks, equivalent functionality can be provided by
configuration also support dynamic DNS in some form. 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 33
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. Responders SHOULD respond to LLMNR queries for names authoritative for, except in the event of a discovered conflict, as
and addresses they are authoritative for. This applies to both forward described in Section 4. Responders SHOULD respond to LLMNR queries for
and reverse lookups. names and addresses they are authoritative for. This applies to both
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
owned by the responder. For example, if the host has a AAAA RR, but no owned by the responder. For example, if the host has a AAAA RR, but no
A RR, and an A RR query is received, the host would respond with RCODE=0 A RR, and an A RR query is received, the host would respond with RCODE=0
and an empty answer section. and an empty answer section.
If a DNS server is running on a host that supports LLMNR, the DNS server If a DNS server is running on a host that supports LLMNR, the DNS server
MUST respond to LLMNR queries only for the RRSets owned by the host on MUST respond to LLMNR queries only for the RRSets owned by the host on
which the server is running, but MUST NOT respond for other records for
which the server is running, but MUST NOT respond for other records for
which the server is authoritative. which the server is authoritative.
In conventional DNS terminology a DNS server authoritative for a zone is In conventional DNS terminology a DNS server authoritative for a zone is
authoritative for all the domain names under the zone root except for authoritative for all the domain names under the zone root except for
the branches delegated into separate zones. Contrary to conventional the branches delegated into separate zones. Contrary to conventional
DNS terminology, an LLMNR responder is authoritative only for the zone DNS terminology, an LLMNR responder is authoritative only for the zone
root. root.
For example the host "host.example.com." is not authoritative for the For example the host "host.example.com." is not authoritative for the
name "child.host.example.com." unless the host is configured with name "child.host.example.com." unless the host is configured with
skipping to change at page 11, line 19 skipping to change at page 11, line 19
send AAAA queries to the configured DNS server over IPv4. send AAAA queries to the configured DNS server over IPv4.
However, an IPv6-only host unconfigured with a DNS server suitable for However, an IPv6-only host unconfigured with a DNS server suitable for
use over IPv6 will be unable to resolve names using DNS. Since use over IPv6 will be unable to resolve names using DNS. Since
automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and
[DNSDisc]) are not yet widely deployed, and not all DNS servers support [DNSDisc]) are not yet widely deployed, and not all DNS servers support
IPv6, lack of IPv6 DNS configuration may be a common problem in the IPv6, lack of IPv6 DNS configuration may be a common problem in the
short term, and LLMNR may prove useful in enabling linklocal name short term, and LLMNR may prove useful in enabling linklocal name
resolution over IPv6. resolution over IPv6.
For example, a home gateway may implement a DNS proxy and DHCPv4, but For example, a home network may provide a DHCPv4 server but may not
not DHCPv6 for DNS configuration [DHCPv6DNS]. In such a circumstance, support DHCPv6 for DNS configuration [DHCPv6DNS]. In such a
IPv6-only hosts will not be configured with a DNS server. Where the DNS circumstance, IPv6-only hosts will not be configured with a DNS server.
proxy does not support dynamic client update over IPv6 or DHCPv6-based Where a DNS server is configured but does not support dynamic client
dynamic update of the DNS proxy, the home gateway will not be able to update over IPv6 or DHCPv6-based dynamic update, hosts on the home
dynamically register the names of IPv6 hosts. As a result, the DNS network will not be able to dynamically register or resolve the names of
proxy will respond to AAAA RR queries sent over IPv4 or IPv6 with an local IPv6 hosts. If the configured DNS server responds to AAAA RR
authoritative name error (RCODE=3). This prevents hosts from resolving queries sent over IPv4 or IPv6 with an authoritative name error
the names of IPv6-only hosts on the local link. In this situation, (RCODE=3), then it will not be possible to resolve the names of
LLMNR over IPv6 can be used for resolution of dynamic names. IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for
local name resolution.
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 3.2.1. Configuration consistency
skipping to change at page 12, line 33 skipping to change at page 12, line 35
uniqueness of a resource record depends on a nature of the name in 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: 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 hostname. type record for a hostname.
Every responder that responds to a LLMNR query and/or dynamic update Every responder that responds to an LLMNR query AND includes a UNIQUE
request AND includes a UNIQUE record in the response: record in the response:
1. MUST verify that there is no other host within the scope of the 1. MUST verify that there is no other host within the scope of the
LLMNR query propagation that can return a resource record LLMNR query propagation that can return a resource record
for the same name, type and class. for the same name, type and class.
2. MUST NOT include a UNIQUE resource record in the 2. MUST NOT include a UNIQUE resource record in the
response without having verified its uniqueness. response without having verified its uniqueness.
Where a host is configured to respond to LLMNR queries on more than one Where a host is configured to respond to LLMNR queries on more than one
interface, each interface should have its own independent LLMNR cache. interface, each interface should have its own independent LLMNR cache.
For each UNIQUE resource record in a given interface's cache, the host For each UNIQUE resource record in a given interface's configuration,
MUST verify resource record uniqueness on that interface. To accomplish the host MUST verify resource record uniqueness on that interface. To
this, the host MUST send an LLMNR query for each UNIQUE resource record. accomplish this, the host MUST send an LLMNR query for each UNIQUE
resource record.
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.
Note that this name conflict detection mechanism doesn't prevent name The name conflict detection mechanism doesn't prevent name conflicts
conflicts when previously partitioned segments are connected by a when previously partitioned segments are connected by a bridge. In such
bridge. In such a situation, name conflicts are detected when a sender a situation, name conflicts are detected when a sender receives more
receives more than one response to its LLMNR query. than one response to its LLMNR multicast query. In this case, the
sender sends the first response that it received to all responders that
In this case, the sender sends the first response that it received to responded to this query except the first one, using UDP unicast. A host
all responders that responded to this query except the first one, using that receives a query response containing a UNIQUE resource record that
unicast. A host that receives a query response containing a UNIQUE it owns, even if it didn't send such a query, MUST verify that no other
resource record that it owns, even if it didn't send such a query, MUST host within the LLMNR scope is authoritative for the same name, using
verify that no other host within the LLMNR scope is authoritative for the mechanism described above. Based on the result, the host detects
the same name, using the mechanism described above. Based on the whether there is a name conflict and acts accordingly.
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 22
| | | | | | | |
[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 forward a response from the first responder to the Host myhost will then send the first responder's response to the second
second responder, who will attempt to verify the uniqueness of host RR responder, who will attempt to verify the uniqueness of host RR for its
for its name, but will not discover a conflict, since the conflicting name, but will not discover a conflict, since the conflicting host
host resides on a different link. Therefore it will continue using its resides on a different link. Therefore it will continue using its name.
name.
Indeed, host myhost cannot distinguish between the situation shown in Host myhost cannot distinguish between the situation shown in Figure 2,
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
This illustrates that the proposed name conflict resolution mechanism This illustrates that the proposed name conflict resolution mechanism
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-18.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-19.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/