draft-ietf-dnsext-mdns-33.txt   draft-ietf-dnsext-mdns-34.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-33.txt> Microsoft <draft-ietf-dnsext-mdns-34.txt> Microsoft
18 July 2004 10 August 2004
Linklocal Multicast Name Resolution (LLMNR) Linklocal Multicast Name Resolution (LLMNR)
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 7, line 40 skipping to change at page 7, line 40
ignored by the responder. The response to a multicast LLMNR query ignored by the responder. The response to a multicast LLMNR query
MUST have RCODE set to zero. A sender MUST silently discard an MUST have RCODE set to zero. A sender MUST silently discard an
LLMNR response with a non-zero RCODE sent in response to a LLMNR response with a non-zero RCODE sent in response to a
multicast query. multicast query.
If an LLMNR responder is authoritative for the name in a multicast If an LLMNR responder is authoritative for the name in a multicast
query, but an error is encountered, the responder SHOULD send an query, but an error is encountered, the responder SHOULD send an
LLMNR response with an RCODE of zero, no RRs in the answer section, LLMNR response with an RCODE of zero, no RRs in the answer section,
and the TC bit set. This will cause the query to be resent using and the TC bit set. This will cause the query to be resent using
TCP, and allow the inclusion of a non-zero RCODE in the response to TCP, and allow the inclusion of a non-zero RCODE in the response to
the TCP query. Responding with the TC bit set is preferrable to the TCP query. Responding with the TC bit set is preferable to not
not sending a response, since it enables errors to be diagnosed. sending a response, since it enables errors to be diagnosed.
Since LLMNR responders only respond to LLMNR queries for names for Since LLMNR responders only respond to LLMNR queries for names for
which they are authoritative, LLMNR responders MUST NOT respond which they are authoritative, LLMNR responders MUST NOT respond
with an RCODE of 3; instead, they should not respond at all. with an RCODE of 3; instead, they should not respond at all.
LLMNR implementations MUST support EDNS0 [RFC2671] and extended LLMNR implementations MUST support EDNS0 [RFC2671] and extended
RCODE values. RCODE values.
QDCOUNT QDCOUNT
An unsigned 16 bit integer specifying the number of entries in the An unsigned 16 bit integer specifying the number of entries in the
skipping to change at page 9, line 10 skipping to change at page 9, line 10
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
10.1.1.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:
host1. IN A 10.1.1.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 10.1.1.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.1.1.10.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.ip6.arpa 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.
IN PTR host1. ip6.arpa IN PTR host1.
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)
skipping to change at page 17, line 40 skipping to change at page 17, line 40
interface, each interface should have its own independent LLMNR interface, each interface should have its own independent LLMNR
cache. For each UNIQUE resource record in a given interface's cache. For each UNIQUE resource record in a given interface's
configuration, the host MUST verify resource record uniqueness on configuration, the host MUST verify resource record uniqueness on
that interface. To accomplish this, the host MUST send an LLMNR that interface. To accomplish this, the host MUST send an LLMNR
query for each UNIQUE resource record. query for each UNIQUE resource record.
By default, a host SHOULD be configured to behave as though all RRs By default, a host SHOULD be configured to behave as though all RRs
are UNIQUE. 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 during sleep) - 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 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 the LLMNR queries using additional
UNIQUE resource records UNIQUE resource records
- detects that an interface is connected and is usable - detects that an interface is connected and is usable
(e.g. an IEEE 802 hardware link-state change indicating (e.g. an IEEE 802 hardware link-state change indicating
that a cable was attached or completion of authentication that a cable was attached or completion of authentication
(and if needed, association) with a wireless base station (and if needed, association) with a wireless base station
or adhoc network or adhoc network
skipping to change at page 20, line 15 skipping to change at page 20, line 16
have a sin6_scope_id value that disambiguates which interface is used have a sin6_scope_id value that disambiguates which interface is used
to reach the address. Of course, to the application, Figures 2 and 3 to reach the address. Of course, to the application, Figures 2 and 3
are still indistinguishable, but this API allows the application to are still indistinguishable, but this API allows the application to
communicate successfully with any address in the list. communicate successfully with any address in the list.
5. Security Considerations 5. Security Considerations
LLMNR is by nature a peer-to-peer name resolution protocol. It is LLMNR is by nature a peer-to-peer name resolution protocol. It is
therefore inherently more vulnerable than DNS, since existing DNS therefore inherently more vulnerable than DNS, since existing DNS
security mechanisms are difficult to apply to LLMNR. While tools security mechanisms are difficult to apply to LLMNR. While tools
exist to alllow an attacker to spoof a response to a DNS query, exist to allow an attacker to spoof a response to a DNS query,
spoofing a response to an LLMNR query is easier since the query is spoofing a response to an LLMNR query is easier since the query is
sent to a link-scope multicast address, where every host on the sent to a link-scope multicast address, where every host on the
logical link will be made aware of it. logical link will be made aware of it.
In order to address the security vulnerabilities, the following In order to address the security vulnerabilities, the following
mechanisms are contemplated: mechanisms are contemplated:
[1] Scope restrictions. [1] Scope restrictions.
[2] Usage restrictions. [2] Usage restrictions.
[3] Cache and port separation. [3] Cache and port separation.
skipping to change at page 24, line 23 skipping to change at page 24, line 23
Number 5, pp. 589, October 2002. Number 5, pp. 589, October 2002.
[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local [DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
unicast addresses to communicate with recursive DNS servers", unicast addresses to communicate with recursive DNS servers",
Internet draft (work in progress), draft-ietf-ipv6-dns- Internet draft (work in progress), draft-ietf-ipv6-dns-
discovery-07.txt, October 2002. discovery-07.txt, October 2002.
[IPV4Link] [IPV4Link]
Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", Internet draft (work in of IPv4 Link-Local Addresses", Internet draft (work in
progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, May progress), draft-ietf-zeroconf-ipv4-linklocal-17.txt, July
2004. 2004.
[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- [POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
Portable Operating System Interface (POSIX). Open Group Portable Operating System Interface (POSIX). Open Group
Technical Standard: Base Specifications, Issue 6, December Technical Standard: Base Specifications, Issue 6, December
2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
[LLMNREnable] [LLMNREnable]
Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
in progress), draft-guttman-mdns-enable-02.txt, April 2002. in progress), draft-guttman-mdns-enable-02.txt, April 2002.
[NodeInfo] [NodeInfo]
Crawford, M., "IPv6 Node Information Queries", Internet draft Crawford, M., "IPv6 Node Information Queries", Internet draft
(work in progress), draft-ietf-ipn-gwg-icmp-name- (work in progress), draft-ietf-ipn-gwg-icmp-name-
lookups-09.txt, May 2002. lookups-09.txt, May 2002.
Acknowledgments Acknowledgments
This work builds upon original work done on multicast DNS by Bill This work builds upon original work done on multicast DNS by Bill
Manning and Bill Woodcock. Bill Manning's work was funded under DARPA Manning and Bill Woodcock. Bill Manning's work was funded under
grant #F30602-99-1-0523. The authors gratefully acknowledge their DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge
contribution to the current specification. Constructive input has their contribution to the current specification. Constructive input
also been received from Mark Andrews, Stuart Cheshire, Randy Bush, has also been received from Mark Andrews, Rob Austein, Randy Bush,
Robert Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
Guttman, Myron Hattig, Thomas Narten, Christian Huitema, Erik Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Brian Zill, Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
Keith Moore and Markku Savela. Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
St. Johns, Sander Van-Valkenburg, and Brian Zill.
Authors' Addresses Authors' Addresses
Levon Esibov Levon Esibov
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: levone@microsoft.com EMail: levone@microsoft.com
 End of changes. 

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