Subject: Proposed resolution to LLMNR Issue #4

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Mar 2003 09:40:29 -0800 (PST)

Issue 4: Introduction Unclear
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: March 7, 2003
Reference:
Document: LLMNR-13
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

The introduction is unclear that LLMNR is not a replacement for DNS.
Having the text explicitly say that LLMNR cannot be used
for communication outside a single link would make sense.

Replace Section 1 with the following:

"1. Introduction

This document discusses Link-Local Multicast Name Resolution (LLMNR),
which operates on a separate port from 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 RCODE set to NXRRSET.

LLMNR queries are sent to and received on port TBD using a LINKLOCAL
address as specified in "Administratively Scoped IP Multicast" [RFC2365]
for IPv4 and the "solicited name" LINKLOCAL multicast addresses for
IPv6, and using a unicast address as described in Section 2.3. The LLMNR
LINKLOCAL address to be used for IPv4 is 224.0.0.251. LINKLOCAL
addresses are used to prevent propagation of LLMNR traffic across
routers, potentially flooding the network.

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 a DNS server or
the home gateway can function as a DNS proxy. By implementing DHCPv4 as
well as a DNS proxy and dynamic DNS, home gateways can provide name
resolution for the names of hosts over IPv4 on the local network.

For small IPv6 networks, equivalent functionality can be provided by a
home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as
well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name
resolution for the names of hosts over IPv6 on the local network.

This should be adequate as long as home gateways implementing DNS
configuration also support dynamic DNS in some form.

In the future, LLMNR may be defined to support greater than LINKLOCAL
multicast scope. 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 adhoc networking
scenarios.

Once we have experience in LLMNR deployment in terms of administrative
issues, usability and impact on the network it will be possible
reevaluate which multicast scopes are appropriate for use with multicast
name resolution mechanisms.

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>