draft-ietf-dnsext-mdns-19.txt

bind-3.2.

necessary in order to poison the LLMNR cache, since LLMNR queries would
be sent even when the DNS server is available.  In addition, the LLMNR
cache, once poisoned, would take precedence over the DNS cache,
eliminating the benefits of cache separation.  As a result, LLMNR is
best thought of as a name resolution mechanism of last resort.




Esibov, Aboba & Thaler       Standards Track                   [Page 16]





INTERNET-DRAFT                    LLMNR                      12 May 2003


5.3.  Cache and port separation

In order to prevent responses to LLMNR queries from polluting the DNS
cache, LLMNR implementations MUST use a distinct, isolated cache for
LLMNR on each interface.  The use of separate caches is most effective
when LLMNR is used as a name resolution mechanism of last resort, since
this minimizes the opportunities for poisoning the LLMNR cache, and
decreases reliance on it.

LLMNR operates on a separate port from DNS, reducing the likelihood that
a DNS server will unintentionally respond to an LLMNR query.

5.4.  Authentication

LLMNR does not require use of DNSSEC, and as a result, responses 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 LLMNR responses.  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

This specification does not create any new name spaces for IANA
administration.  LLMNR requires allocation of a port TBD for both TCP
and UDP.  Assignment of the same port for both transports is requested.
LLMNR utilizes a link-scope multicast IPv4 address (224.0.0.251) that
has been previously allocated to LLMNR by IANA.  It also requires
allocation of a link-scope multicast IPv6 address.

7.  Normative References

[RFC1035]      Mockapetris, P., "Domain Names - Implementation and
               Specification", RFC 1035, November 1987.

[RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2136]      Vixie, P., et al., "Dynamic Updates in the Domain Name
               System (DNS UPDATE)", RFC 2136, April 1997.

[RFC2365]      Meyer, D., "Administratively Scoped IP Multicast", BCP
               23, RFC 2365, July 1998.




Esibov, Aboba & Thaler       Standards Track                   [Page 17]





INTERNET-DRAFT                    LLMNR                      12 May 2003


[RFC2373]      Hinden, R. and S. Deering, "IP Version 6 Addressing
               Architecture", RFC 2373, July 1998.

[RFC2460]      Deering, S. and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC 2460, December 1998.

[RFC2535]      Eastlake, D., "Domain Name System Security Extensions",
               RFC 2535, March 1999.

[RFC2988]      Paxson, V. and M. Allman, "Computing TCP's Retransmission
               Timer", RFC 2988, November 2000.

8.  Informative References

[RFC1536]      Kumar, A., et. al., "DNS Implementation Errors and
               Suggested Fixes", RFC 1536, October 1993.

[RFC2292]      Stevens, W. and M. Thomas, "Advanced Sockets API for
               IPv6", RFC 2292, February 1998.

[RFC2434]      Alvestrand, H. and T. Narten, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
               October 1998.

[RFC2553]      Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
               "Basic Socket Interface Extensions for IPv6", RFC 2553,
               March 1999.

[RFC2937]      Smith, C., "The Name Service Search Option for DHCP", RFC
               2937, September 2000.

[DHCPv6DNS]    Droms, R., "A Guide to Implementing Stateless DHCPv6
               Service", Internet draft (work in progress), draft-droms-
               dhcpv6-stateless-guide-01.txt, October 2002.

[DNSPerf]      Jung, J., et al., "DNS Performance and the Effectiveness
               of Caching", IEEE/ACM Transactions on Networking, Volume
               10, Number 5, pp. 589, October 2002.

[DNSDisc]      Durand, A., Hagino, I. and D. Thaler, "Well known site
               local unicast addresses to communicate with recursive DNS
               servers", Internet draft (work in progress), draft-ietf-
               ipv6-dns-discovery-07.txt, October 2002.

[IPV4Link]     Cheshire, S., Aboba, B. and E. Guttman, "Dynamic
               Configuration of IPv4 Link-Local Addresses", Internet
               draft (work in progress), draft-ietf-zeroconf-
               ipv4-linklocal-07.txt, August 2002.



Esibov, Aboba & Thaler       Standards Track                   [Page 18]





INTERNET-DRAFT                    LLMNR                      12 May 2003


[LLMNREnable]  Guttman, E., "DHCP LLMNR Enable Option", Internet draft
               (work in progress), draft-guttman-mdns-enable-02.txt,
               April 2002.

[NodeInfo]     Crawford, M., "IPv6 Node Information Queries", Internet
               draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
               lookups-09.txt, May 2002.

Acknowledgments

This work builds upon original work done on multicast DNS by Bill
Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
grant #F30602-99-1-0523. The authors gratefully acknowledge their
contribution to the current specification.  Constructive input has also
been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert
Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron
Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van-
Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku
Savela.

Authors' Addresses

Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: [e-mail]

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: [phone]
EMail: [e-mail]

Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: [phone]
EMail: [e-mail]







Esibov, Aboba & Thaler       Standards Track                   [Page 19]





INTERNET-DRAFT                    LLMNR                      12 May 2003


Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to  pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard.  Please address the information to the IETF Executive
Director.

Full Copyright Statement

Copyright (C) The Internet Society (2003).  All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.  The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns.  This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.







Esibov, Aboba & Thaler       Standards Track                   [Page 20]





INTERNET-DRAFT                    LLMNR                      12 May 2003


Open Issues

Open issues with this specification are tracked on the following web
site:

http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

Expiration Date

This memo is filed as <draft-ietf-dnsext-mdns-19.txt>,  and  expires
November 22, 2003.








































Esibov, Aboba & Thaler       Standards Track                   [Page 21]