draft-ietf-dnsext-mdns-43.txt

bind 源码 最新实现 linux/unix/windows平台

DNSEXT Working Group                                       Bernard Aboba
INTERNET-DRAFT                                               Dave Thaler
Category: Standards Track                                   Levon Esibov
<draft-ietf-dnsext-mdns-43.txt>                    Microsoft Corporation
29 August 2005

              Linklocal Multicast Name Resolution (LLMNR)

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 15, 2006.

Copyright Notice

   Copyright (C) The Internet Society 2005.

Abstract

   The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
   name resolution in scenarios in which conventional DNS name
   resolution is not possible.  LLMNR supports all current and future
   DNS formats, types and classes, while operating on a separate port
   from DNS, and with a distinct resolver cache.  Since LLMNR only
   operates on the local link, it cannot be considered a substitute for
   DNS.





Aboba, Thaler & Esibov       Standards Track                    [Page 1]





INTERNET-DRAFT                    LLMNR                   29 August 2005


Table of Contents

1.     Introduction ..........................................    3
   1.1       Requirements ....................................    4
   1.2       Terminology .....................................    4
2.     Name Resolution Using LLMNR ...........................    4
   2.1       LLMNR Packet Format .............................    6
   2.2       Sender Behavior .................................    9
   2.3       Responder Behavior ..............................   10
   2.4       Unicast Queries and Responses ...................   12
   2.5       Off-link Detection ..............................   13
   2.6       Responder Responsibilities ......................   13
   2.7       Retransmission and Jitter .......................   14
   2.8       DNS TTL .........................................   15
   2.9       Use of the Authority and Additional Sections ....   15
3.     Usage model ...........................................   16
   3.1       LLMNR Configuration .............................   17
4.     Conflict Resolution ...................................   18
   4.1       Uniqueness Verification .........................   19
   4.2       Conflict Detection and Defense ..................   20
   4.3       Considerations for Multiple Interfaces ..........   21
   4.4       API issues ......................................   22
5.     Security Considerations ...............................   22
   5.1       Denial of Service ...............................   23
   5.2       Spoofing ...............,........................   23
   5.3       Authentication ..................................   24
   5.4       Cache and Port Separation .......................   25
6.     IANA considerations ...................................   25
7.     Constants .............................................   25
8.     References ............................................   25
   8.1       Normative References ............................   25
   8.2       Informative References ..........................   26
Acknowledgments ..............................................   27
Authors' Addresses ...........................................   28
Intellectual Property Statement ..............................   28
Disclaimer of Validity .......................................   29
Copyright Statement ..........................................   29














Aboba, Thaler & Esibov       Standards Track                    [Page 2]





INTERNET-DRAFT                    LLMNR                   29 August 2005


1.  Introduction

   This document discusses Link Local Multicast Name Resolution (LLMNR),
   which is based on the DNS packet format and supports all current and
   future DNS formats, types and classes.  LLMNR operates on a separate
   port from the Domain Name System (DNS), with a distinct resolver
   cache.

   The goal of LLMNR is to enable name resolution in scenarios in which
   conventional DNS name resolution is not possible.  Usage scenarios
   (discussed in more detail in Section 3.1) include situations in which
   hosts are not configured with the address of a DNS server; where the
   DNS server is unavailable or unreachable; where there is no DNS
   server authoritative for the name of a host, or where the
   authoritative DNS server does not have the desired RRs, as described
   in Section 2.

   Since LLMNR only operates on the local link, it cannot be considered
   a substitute for DNS.  Link-scope multicast addresses are used to
   prevent propagation of LLMNR traffic across routers, potentially
   flooding the network.  LLMNR queries can also be sent to a unicast
   address, as described in Section 2.4.

   Propagation of LLMNR packets on the local link is considered
   sufficient to enable name resolution in small networks.  In such
   networks, if a network has a gateway, then typically the network is
   able to provide DNS server configuration.  Configuration issues are
   discussed in Section 3.1.

   In the future, it may be desirable to consider use of multicast name
   resolution with multicast scopes beyond the link-scope.  This could
   occur if LLMNR deployment is successful, the need arises for
   multicast name resolution beyond the link-scope, or multicast routing
   becomes ubiquitous.  For example, expanded support for multicast name
   resolution might be required for mobile ad-hoc networks.

   Once we have experience in LLMNR deployment in terms of
   administrative issues, usability and impact on the network, it will
   be possible to reevaluate which multicast scopes are appropriate for
   use with multicast name resolution.  IPv4 administratively scoped
   multicast usage is specified in "Administratively Scoped IP
   Multicast" [RFC2365].

   Service discovery in general, as well as discovery of DNS servers
   using LLMNR in particular, is outside of the scope of this document,
   as is name resolution over non-multicast capable media.





Aboba, Thaler & Esibov       Standards Track                    [Page 3]





INTERNET-DRAFT                    LLMNR                   29 August 2005


1.1.  Requirements

   In this document, several words are used to signify the requirements
   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
   and "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

1.2.  Terminology

   This document assumes familiarity with DNS terminology defined in
   [RFC1035].  Other terminology used in this document includes:

Positively Resolved
     Responses with RCODE set to zero are referred to in this document
     as "positively resolved".

Routable Address
     An address other than a Link-Local address.  This includes globally
     routable addresses, as well as private addresses.

Reachable
     An LLMNR responder considers one of its addresses reachable over a
     link if it will respond to an ARP or Neighbor Discovery query for
     that address received on that link.

Responder
     A host that listens to LLMNR queries, and responds to those for
     which it is authoritative.

Sender
     A host that sends an LLMNR query.

UNIQUE
     There are some scenarios when multiple responders may respond to
     the same query.  There are other scenarios when only one responder
     may respond to a query.  Names for which only a single responder is
     anticipated are referred to as UNIQUE.  Name uniqueness is
     configured on the responder, and therefore uniqueness verification
     is the responder's responsibility.

2.  Name Resolution Using LLMNR

   LLMNR is a peer-to-peer name resolution protocol that is not intended
   as a replacement for DNS.  LLMNR queries are sent to and received on
   port 5355.  The IPv4 link-scope multicast address a given responder
   listens to, and to which a sender sends queries, is 224.0.0.252.  The
   IPv6 link-scope multicast address a given responder listens to, and



Aboba, Thaler & Esibov       Standards Track                    [Page 4]





INTERNET-DRAFT                    LLMNR                   29 August 2005


   to which a sender sends all queries, is FF02:0:0:0:0:0:1:3.

   Typically a host is configured as both an LLMNR sender and a
   responder.  A host MAY be configured as a sender, but not a
   responder.  However, a host configured as a responder MUST act as a
   sender, if only to verify the uniqueness of names as described in
   Section 4.  This document does not specify how names are chosen or
   configured.  This may occur via any mechanism, including DHCPv4
   [RFC2131] or DHCPv6 [RFC3315].

   LLMNR usage MAY be configured manually or automatically on a per
   interface basis.  By default, LLMNR responders SHOULD be enabled on
   all interfaces, at all times.  Enabling LLMNR for use in situations
   where a DNS server has been configured will result in a change in
   default behavior without a simultaneous update to configuration
   information.  Where this is considered undesirable, LLMNR SHOULD NOT
   be enabled by default, so that hosts will neither listen on the link-
   scope multicast address, nor will they send queries to that address.

   By default, LLMNR queries MAY be sent only when one of the following
   conditions are met:

   [1] No manual or automatic DNS configuration has been performed.
       If DNS server address(es) have been configured, then LLMNR
       SHOULD NOT be used as the primary name resolution mechanism,
       although it MAY be used as a secondary name resolution
       mechanism.  A dual stack host SHOULD attempt to reach DNS
       servers overall protocols on which DNS server address(es) are
       configured, prior to sending LLMNR queries.  For dual stack
       hosts configured with DNS server address(es) for one protocol
       but not another, this inplies that DNS queries SHOULD be sent
       over the protocol configured with a DNS server, prior to
       sending LLMNR queries.

   [2] All attempts to resolve the name via DNS on all interfaces
       have failed after exhausting the searchlist.  This can occur
       because DNS servers did not respond, or because they
       responded to DNS queries with RCODE=3 (Authoritative Name
       Error) or RCODE=0, and an empty answer section.  Where a
       single resolver call generates DNS queries for A and AAAA RRs,
       an implementation MAY choose not to send LLMNR queries if any
       of the DNS queries is successful.  An LLMNR query SHOULD only
       be sent for the originally requested name;  a searchlist
       is not used to form additional LLMNR queries.

   While these conditions are necessary for sending an LLMNR query, they
   are not sufficient.  While an LLMNR sender MAY send a query for any
   name, it also MAY impose additional conditions on sending LLMNR



Aboba, Thaler & Esibov       Standards Track                    [Page 5]





INTERNET-DRAFT                    LLMNR                   29 August 2005


   queries.  For example, a sender configured with a DNS server MAY send
   LLMNR queries only for unqualified names and for fully qualified
   domain names within configured zones.

   A typical sequence of events for LLMNR usage is as follows:

   [a]  DNS servers are not configured or attempts to resolve the
        name via DNS have failed, after exhausting the searchlist.
        Also, the name to be queried satisfies the restrictions
        imposed by the implementation.

   [b]  An LLMNR sender sends an LLMNR query to the link-scope
        multicast address(es), unless a unicast query is indicated,
        as specified in Section 2.4.