draft-ietf-dnsext-mdns-20.txt   draft-ietf-dnsext-mdns-21.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-20.txt> Microsoft <draft-ietf-dnsext-mdns-21.txt> Microsoft
21 May 2003 9 June 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 27 skipping to change at page 2, line 27
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 ....................... 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
skipping to change at page 4, line 19 skipping to change at page 4, line 19
Responder A host that listens to LLMNR queries, and responds to Responder A host that listens to LLMNR queries, and responds to
those for which it is authoritative. those for which it is authoritative.
Sender A host that sends an LLMNR query. Typically a host is Sender A host that sends an LLMNR query. Typically a host is
configured as both a sender and a responder. However, a configured as both a sender and a responder. However, a
host may be configured as a sender, but not a responder host may be configured as a sender, but not a responder
or as a responder, but not a sender. or as a responder, but not a sender.
Routable address Routable address
An address other than a linklocal address. This includes An address other than a Link-Local address. This
site local and globally routable addresses, as well as includes globally routable addresses, as well as private
private addresses. addresses.
2. Name resolution using LLMNR 2. Name resolution using LLMNR
A typical sequence of events for LLMNR usage is as follows: A typical sequence of events for LLMNR usage is as follows:
[1] A sender needs to resolve a query for a name "host.example.com", [1] A sender needs to resolve a query for a name "host.example.com",
so it sends an LLMNR query to the link-scope multicast address. so it sends an LLMNR query to the link-scope multicast address.
[2] A responder responds to this query only if it is authoritative [2] A responder responds to this query only if it is authoritative
for the domain name "host.example.com". The responder sends for the domain name "host.example.com". The responder sends
skipping to change at page 12, line 46 skipping to change at page 12, line 46
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 configuration, For each UNIQUE resource record in a given interface's configuration,
the host MUST verify resource record uniqueness on that interface. To the host MUST verify resource record uniqueness on that interface. To
accomplish this, the host MUST send an LLMNR query for each UNIQUE accomplish this, the host MUST send an LLMNR query for each UNIQUE
resource record. 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 rebooted
- is configured to respond to the LLMNR queries on an interface or - wakes from sleep (if the network interface was inactive during sleep)
- is configured to respond to the LLMNR queries on an interface
- 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
- detects that an interface is connected and is usable
(e.g. an IEEE 802 hardware link-state change indicating that a
cable was attached or that an association has occurred with a
wireless base station and that any required authentication has
completed)
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 order when previously partitioned segments are connected by a bridge. In order
to minimize the chance of conflicts in such a situation, it is to minimize the chance of conflicts in such a situation, it is
recommended that steps be taken to ensure hostname uniqueness. For recommended that steps be taken to ensure hostname uniqueness. For
example, the hostname could be chosen randomly from a large pool of example, the hostname could be chosen randomly from a large pool of
skipping to change at page 13, line 18 skipping to change at page 13, line 23
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 order when previously partitioned segments are connected by a bridge. In order
to minimize the chance of conflicts in such a situation, it is to minimize the chance of conflicts in such a situation, it is
recommended that steps be taken to ensure hostname uniqueness. For recommended that steps be taken to ensure hostname uniqueness. For
example, the hostname could be chosen randomly from a large pool of example, the hostname could be chosen randomly from a large pool of
potential names, or the hostname could be assigned via a process potential names, or the hostname could be assigned via a process
designed to guarantee uniqueness. designed to guarantee uniqueness.
When name conflicts are detected, they SHOULD be logged. To detect
duplicate use of a name, an administrator can use a name resolution
utility which employs LLMNR and lists both responses and responders.
This would allow an administrator to diagnose behavior and potentially
to intervene and reconfigure LLMNR responders who should not be
configured to respond to the same name.
4.1. Considerations for Multiple Interfaces 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.
A multi-homed host checks the uniqueness of UNIQUE records as described A multi-homed host checks the uniqueness of UNIQUE records as described
skipping to change at page 18, line 40 skipping to change at page 18, line 52
10, Number 5, pp. 589, October 2002. 10, Number 5, pp. 589, October 2002.
[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site [DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site
local unicast addresses to communicate with recursive DNS local unicast addresses to communicate with recursive DNS
servers", Internet draft (work in progress), draft-ietf- servers", Internet draft (work in progress), draft-ietf-
ipv6-dns-discovery-07.txt, October 2002. ipv6-dns-discovery-07.txt, October 2002.
[IPV4Link] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic [IPV4Link] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", Internet Configuration of IPv4 Link-Local Addresses", Internet
draft (work in progress), draft-ietf-zeroconf- draft (work in progress), draft-ietf-zeroconf-
ipv4-linklocal-07.txt, August 2002. ipv4-linklocal-08.txt, June 2003.
[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft [LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft
(work in progress), draft-guttman-mdns-enable-02.txt, (work in progress), draft-guttman-mdns-enable-02.txt,
April 2002. April 2002.
[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet [NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet
draft (work in progress), draft-ietf-ipn-gwg-icmp-name- draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
lookups-09.txt, May 2002. lookups-09.txt, May 2002.
Acknowledgments Acknowledgments
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-20.txt>, and expires This memo is filed as <draft-ietf-dnsext-mdns-21.txt>, and expires
November 22, 2003. December 22, 2003.
 End of changes. 

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