Subject: Proposed Resolution of LLMNR Issue 85: General Comments

From: Bernard Aboba <[email-masked]>
Date: Fri, 15 Jul 2005 21:00:48 -0700 (PDT)

The text of LLMNR Issue 85 is enclosed below.  This and other LLMNR issues
are tracked on the LLMNR issues page:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

The proposed resolution is as follows:

Move the following sentence from Section 2 to Section 1:

"IPv4 administratively scoped multicast usage is specified in
"Administratively Scoped IP Multicast" [RFC2365]."

In Section 2.5, change:

"2.5.  "Off link" Detection

   For IPv4, an "on link" address is defined as a link-local address
   [IPv4Link] or an address whose prefix belongs to a subnet on the
   local link.  For IPv6 [RFC2460] an "on link" address is either a
   link-local address, defined in [RFC2373], or one belonging to a
   prefix that a Router Advertisement indicates is on-link [RFC2461].

   A sender MUST select a source address for LLMNR queries that is "on
   link".  The destination address of an LLMNR query MUST be a link-
   scope multicast address or an "on link" unicast address.

   A responder MUST select a source address for responses that is "on
   link". The destination address of an LLMNR response MUST be an "on
   link" unicast address."

To:

"2.5.  "Off link" Detection

A sender MUST select a source address for LLMNR queries that is
assigned on the interface on which the query is sent.  The destination
address of an LLMNR query MUST be a link-scope multicast address or a
unicast address.

A responder MUST select a source address for responses that is assigned
on the interface on which the query was received.  The destination
address of an LLMNR response MUST be a unicast address."

Add the following sentence to Section 2.6:

"IPv4 Link-Local addresses are defined in [RFC3927]. IPv6
Link-Local addresses are defined in [RFC2373]."

Delete references to [RFC2460] and [RFC2461].

----------------------------------------------------------------------------
Issue 85: General Comments
Submitter: Stuart Cheshire
Submitter email address: [email-masked]
Date first submitted: May 25, 2005
Reference:
Document: LLMNR-40
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Reading draft-ietf-dnsext-mdns-40.txt, the problem I ran into was trying
to understand what problem it is trying to solve. The abstract states
that it is for "ad-hoc networks operating without a Domain Name System
(DNS) server." Superficially that sounds all well and good, but what does
it really mean? When it says, "DNS server", does it mean "authoritative
name server", or "recursive name server"? The document needs to say
clearly which it is talking about, because they are very different
problems. One scenario is a device that has a name, but no authoritative
server to answer for that name. The other is a resolver client that wants
to look up a name, but has no recursive server to ask.

There are several problems I can imagine this document *might* be trying
to solve:

1. A device that has a conventionally allocated, properly delegated,
fully-qualified domain name, but there is no (authoritative) name server
to answer for that name.

2. A device that has *no* conventionally allocated, properly delegated,
fully-qualified domain name, because the user doesn't know how to do
that, or doesn't want to pay the annual fee to register a domain, or
simply because the device has just shipped from the factory, and doesn't
even have a human owner yet to go through the steps of allocating and
assigning a unique FQDN for it.

3. A client that wants to look up a host name, but there is no
authoritative name server for that name.

4. A client that wants to look up a host name, but there is no recursive
name server available for the client to talk to.

5. A client that wants to look up a host name, and there is an
authoritative name server for that name, but for whatever reason it's not
responding right now.

These are all very different scenarios, and the document needs to state
clearly which, if any (or all) of them it is addressing. Right now
reading the document feels a bit like playing the shell game, where you
try (usually unsuccessfully) to keep track of which shell has the pea
underneath as they slide around. Reading the document, I kept finding
things that didn't work for one or more of the above scenarios, but it
wasn't clear if that was a problem because it wasn't clear if the
document was seeking to solve that particular problem.

[BA] A host implementing IPv6 may require LLMNR for name
resolution in each of the scenarios you describe. For
example, an IPv6-only host may not have a DNS server
configured, or it may have an anycast DNS server address
configured, but there is no server present listening on
that address that is reachable from the hosts's location.

There is also an additional scenario not listed, which
is that a host may have an authoritative name server
which may not answer for all RR types. For example,
a home gateway may have a DNS server built-in which
may support DDNS via DHCPv4. However, the DNS
server may only answer with A RRs, not AAAA RRs, and
it may not answer queries over IPv6.

Scenario 1 cannot necessarily be distinguished
from Scenario 5, or even Scenario 4. For example, with IPv6,
anycast addresses can be configured for DNS servers, so that a DNS
server address can be configured but there is no DNS server
listening on the anycast address. Also, it is possible that
a DNS server may have been configured, but the host has moved to
an adhoc network where that server is no longer reachable.

Perhaps if you would provide a list of things that you found
that didn't work, then we could better address the issue.
   For example, a host configured to have computer name "host1" and to
   be a member of the "example.com" domain, and with IPv4 address
   192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
   authoritative for the following records:

   host1. IN A 192.0.2.1
          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6

This seems to be the most egregious pollution of the top level of the DNS
namespace. If I call my television "tv.myhouse.", then that means it
answers for the name "tv." How does that coexist with the global DNS
records for Tuvalu?

[BA] Since there is no concept of delegation in LLMNR, configuring
a host to answer LLMNR queries for "tv.myhouse" or even "tv" will
not cause a responder to answer queries for "foo.tv" or any other name
within
the tv TLD.

2.5.  "Off link" Detection

   For IPv4, an "on link" address is defined as a link-local address
   [IPv4Link] or an address whose prefix belongs to a subnet on the
   local link.

How does a given device *know* what subnets are on the local link? To
know this, a device has to have perfectly accurate configuration
information, but the whole point of LLMNR is for scenarios where
configuration infrastructure has failed, and the device is left to fend
for itself as best it can. To be useful, the device has to be able to
operate even if some or all of its configuration information is wrong.

[BA] Section 2.5 should only relate to what source addresses a host
can use in responding to an LLMNR query. However, there are also two
instances where it also talks about whether a destination address
is "on link". By removing those two instances we can remove the
need for the host to know what prefixes are on the link, and only
depend on its knowing what addresses have been assigned on which
interfaces.

   Section 2.4 discusses use of TCP for LLMNR queries and responses.  In
   composing an LLMNR query using TCP, the sender MUST set the Hop Limit
   field in the IPv6 header and the TTL field in the IPv4 header of the
   response to one (1).  The responder SHOULD set the TTL or Hop Limit
   settings on the TCP listen socket to one (1) so that SYN-ACK packets
   will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
   prevents an incoming connection from off-link since the sender will
   not receive a SYN-ACK from the responder.

A common enterprise configuration is to have two or more IP subnets
overlayed on the same physical link. (You can argue that this is
misconfiguration, but it is still common.) This means that two laptops
sitting next to each other on the same Ethernet hub can be apparently two
hops from each other. Setting the TTL to 1 means that half of the LAN
becomes unreachable from the other half.
Also, how does this interact with multi-link subnets?

[BA] In this scenario, the router could send an ICMP redirect
if it wanted the host to treat the other subnet as local. It
is also possible that the router would include a built-in DNS
server so that LLMNR would not be necessary.

With respect to "multi-link" subnets, some instances of these
do not decrement TTL and others (MANET) do. In those that do,
my understanding is that LLMNR queries will not propagate
beyond the link scope either.

Since DNS PTR queries frequently fail, applications need
to be prepared for this. So using TCP and setting
the TTL field to 1 for PTR RR queries shouldn't have much
negative impact.

   For UDP queries and responses, the Hop Limit field in the IPv6 header
   and the TTL field in the IPV4 header MAY be set to any value.
   However, it is RECOMMENDED that the value 255 be used for
   compatibility with Apple Bonjour [Bonjour].

Has this compatibility been tested? I don't have access to any LLMNR
implementation. (I don't even know if there are any LLMNR
implementations). Windows users can easily test this by just downloaded
Bonjour for Windows.

<http://www.apple.com/bonjour/>

If one of the LLMNR supporters could try it, that would be very useful
information.

[BA] To my knowledge compatibility has not been tested. Since
you submitted the original comment that lead to the incorporation
of this text, can you suggest something more appropriate?

   IPv4 administratively scoped multicast usage is specified
   in "Administratively Scoped IP Multicast" [RFC2365].

Does LLMNR use Administratively Scoped IP Multicast?

   The IPv4 link-
   scope multicast address a given responder listens to, and to which a
   sender sends queries, is 224.0.0.252.

Why this address? My mDNS protocol uses link-local address 224.0.0.251
for consistency with Administratively Scoped Multicast addresses, which
are allocated from the top down. 239.x.x.251 was the Administratively
Scoped address group originally allocated for mDNS; for consistency I
picked 224.0.0.251 as its link-local counterpart. The Administratively
Scoped address group 239.x.x.252 is allocated for MZAP, which does not
(as far as I know) have anything to do with LLMNR.

[BA] 224.0.0.252 was the address assigned by IANA. The "252" has no
broader significance.  LLMNR does not use Administratively Scoped IP
Multicast.

<http://www.iana.org/assignments/multicast-addresses>

--
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/>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 19 Jul 2005 06:47:01 -0700 (PDT)

Here are additional changes made to resolve this issue:

Change the abstract to:

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

In Section 1, change:

"  This document discusses Link Local Multicast Name Resolution (LLMNR),
   which utilizes 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.  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 2.  Since
   LLMNR only operates on the local link, it cannot be considered a
   substitute for DNS."

To:

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