draft-ietf-dnsext-mdns-19.txt

bind-3.2.

DNSEXT Working Group                                        Levon Esibov
INTERNET-DRAFT                                             Bernard Aboba
Category: Standards Track                                    Dave Thaler
<draft-ietf-dnsext-mdns-19.txt>                                Microsoft
12 May 2003


              Linklocal Multicast Name Resolution (LLMNR)

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

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.

Copyright Notice

Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

Today, with the rise of home networking, there are an increasing number
of ad-hoc networks operating without a Domain Name System (DNS) server.
In order to allow name resolution in such environments, Link-Local
Multicast Name Resolution (LLMNR) is proposed.  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.












Esibov, Aboba & Thaler       Standards Track                    [Page 1]





INTERNET-DRAFT                    LLMNR                      12 May 2003


Table of Contents

1.     Introduction ..........................................    3
   1.1       Requirements ....................................    4
   1.2       Terminology .....................................    4
2.     Name resolution using LLMNR ...........................    4
   2.1       Sender behavior .................................    5
   2.2       Responder behavior ..............................    5
   2.3       Unicast queries .................................    6
   2.4       Addressing ......................................    7
   2.5       Off-link detection ..............................    8
   2.6       Retransmissions .................................    8
   2.7       DNS TTL .........................................    9
3.     Usage model ...........................................    9
   3.1       Unqualified names ...............................   10
   3.2       LLMNR configuration .............................   10
4.     Conflict resolution ...................................   12
   4.1       Considerations for multiple interfaces ..........   13
   4.2       API issues ......................................   14
5.     Security considerations ...............................   15
   5.1       Scope restriction ...............................   15
   5.2       Usage restriction ...............................   16
   5.3       Cache and port separation .......................   17
   5.4       Authentication ..................................   17
6.     IANA considerations ...................................   17
7.     Normative References ..................................   17
8.     Informative References ................................   18
Acknowledgments ..............................................   19
Authors' Addresses ...........................................   19
Intellectual Property Statement ..............................   20
Full Copyright Statement .....................................   20




















Esibov, Aboba & Thaler       Standards Track                    [Page 2]





INTERNET-DRAFT                    LLMNR                      12 May 2003


1.  Introduction

This document discusses Link Local Multicast Name Resolution (LLMNR),
which operates on a separate port from the Domain Name System (DNS),
with a distinct resolver cache, but does not change the format of DNS
packets.  LLMNR supports all current and future DNS formats, types and
classes.  However, since LLMNR only operates on the local link, it
cannot be considered a substitute for DNS.

The goal of LLMNR is to enable name resolution in scenarios in which
conventional DNS name resolution is not possible.  These include
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
they respond with errors, as described in Section 3.

LLMNR queries are sent to and received on port TBD.  Link-scope
multicast addresses are used to prevent propagation of LLMNR traffic
across routers, potentially flooding the network; for details, see
Section 2.4.  LLMNR queries can also be sent to a unicast address, as
described in Section 2.3.

Propagation of LLMNR packets on the local link is considered sufficient
to enable name resolution in small networks.  The assumption is that if
a network has a home gateway, then the network either has DNS and DHCPv4
servers or the home gateway provides DHCPv4 and DNS server
functionality.  By providing  Dynamic Host Configuration Service for
IPv4 (DHCPv4),  as well as a DNS server with support for dynamic DNS,
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
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
multicast.  This would occur if LLMNR deployment is successful, the
assumption that LLMNR is not needed on multiple links proves incorrect,
and multicast routing becomes ubiquitous.  For example, it is not clear
that this assumption will be valid in large ad hoc networking scenarios.

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 mechanisms.




Esibov, Aboba & Thaler       Standards Track                    [Page 3]





INTERNET-DRAFT                    LLMNR                      12 May 2003


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.

1.1.  Requirements

In this document, several words are used to signify the requirements of
the specification.  These words are often capitalized.  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

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.  Typically a host is
               configured as both a sender and a responder.  However, a
               host may be configured as a sender, but not a responder
               or as a responder, but not a sender.

Routable address
               An address other than a linklocal address.  This includes
               site local and globally routable addresses, as well as
               private addresses.

2.  Name resolution using LLMNR

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",
    so it sends an LLMNR query to the link-scope multicast address.

[2] A responder responds to this query only if it is authoritative
    for the domain name "host.example.com".  The responder sends
    a response to the sender via unicast over UDP.

[3] Upon the reception of the response, the sender performs the checks
    described in Section 2.5.  If these conditions are met, then the
    sender uses and caches the returned response.  If not, then the
    sender ignores the response and continues waiting for the response.

Further details of sender and responder behavior are provided in the
sections that follow.






Esibov, Aboba & Thaler       Standards Track                    [Page 4]





INTERNET-DRAFT                    LLMNR                      12 May 2003


2.1.  Sender behavior

A sender sends an LLMNR query for any legal resource record  type (e.g.
A/AAAA, SRV, PTR, etc.) to the link-scope multicast address.  As
described in Section 2.3, a sender may also send a unicast query. An
LLMNR sender MAY send a request for any name.

The RD (Recursion Desired) bit MUST NOT be set in a query.  If a
responder receives a query with the header containing RD set bit, the
responder MUST ignore the RD bit.

The sender MUST anticipate receiving no replies to some LLMNR queries,
in the event that no responders are available within the link-scope or
in the event no positive non-null responses exist for the transmitted
query.  If no positive response is received, a resolver treats it as a
response that no records of the specified type and class exist for the
specified name (it is treated the same as a response with RCODE=0 and an
empty answer section).

2.2.  Responder behavior

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
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
to verify the uniqueness of names as described in Section 4.

Responders MUST NOT respond to LLMNR queries for names they are not
authoritative for, except in the event of a discovered conflict, as
described in Section 4.  Responders SHOULD respond to LLMNR queries for
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
LLMNR queries is authoritative for the name "host.example.com.".  On
receiving an LLMNR A/AAAA resource record query for the name
"host.example.com." the host authoritatively responds with A/AAAA
record(s) that contain IP address(es) in the RDATA of the resource
record.

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
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
and an empty answer section.

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



Esibov, Aboba & Thaler       Standards Track                    [Page 5]





INTERNET-DRAFT                    LLMNR                      12 May 2003


which the server is running, but MUST NOT respond for other records for
which the server is authoritative.

In conventional DNS terminology a DNS server authoritative for a zone is
authoritative for all the domain names under the zone root except for
the branches delegated into separate zones.  Contrary to conventional
DNS terminology, an LLMNR responder is authoritative only for the zone
root.

For example the host "host.example.com." is not authoritative for the