Subject: DNSEXT WGLC LLMNR-40 (Link-Local Multicast Name Resolution)

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Wed, 01 Jun 2005 10:58:06 -0400

This message starts a WGLC for LLMNR ending on June 17'th.

Short history: The working group issued a Last call on this document[1]
(version -22) in August 2003, after major changes version (34) was
advanced[2] to the IESG in August 2004. The AD raised issues of
omission in the design of the protocol.
This resulted in a number of significant changes in the document.
The current version (40) has addressed all the issued raised by the
AD and subsequently by others.
As the changes to the protocol document and protocol itself are significant
the AD asked the working group to review the document again.

Current version of the draft is at:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-40.txt

This document has an issues tracker at:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

Summary of changes since version 33:
  - How names are determined to be unique and conflict resolution.
  - Coexistence of LLMNR, DNS and multiple transport protocols, this
    relates to if/when LLMNR is used and over what transport.
  - Editorial and clarifications of text.

The document is on standards track.

Please reply either to working group mailing list or both chairs with
comments, or acknowledgement that you have no issues with the document.

	Olafur & Olaf
[1] http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01510.html
[2] http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01466.html

--
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: Stuart Cheshire <[email-masked]>
Date: Fri, 17 Jun 2005 15:07:37 +0100

>This message starts a WGLC for LLMNR ending on June 17'th.

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.

Some other general comments and questions:

   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.

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

   An LLMNR sender may send a request for any name.  However, by
   default, LLMNR requests SHOULD be sent only when one of the following
   conditions are met:

   [3] DNS servers respond to a DNS query with RCODE=3
       (Authoritative Name Error) or RCODE=0, and an empty
       answer section.

This seems to imply that *every* single failed name lookup on a 
LLMNR-enabled host has to suffer the full LLMNR timeout before returning 
to the caller.

For example, when I look up "foo" today, the DNS resolver client rapidly 
runs through my searchlist getting authoritative no-answer or NXDOMAIN 
responses for each one. With LLMNR, *every* single one of those failed 
lookups would have to wait a second or two for LLMNR to time out. What 
used to take mere milliseconds could now take 5-10 seconds to complete.

Is this rule intended to solve scenario (2), for users who have no domain 
in which they can legitimately register names? It certainly seems like 
it. This rule means I can call my laptop "wibble.amazon.com.", and after 
getting an authoritative NXDOMAIN error from amazon.com, your LLMNR 
client will then successfully resolve it via link-local multicast. This 
seems to be declaring open season on domain names. It says to users, "if 
you have no domain name, just take someone else's." On the home network, 
this cavalier hijacking of names will apparently work successfully, 
giving users the dubious impression that domain names are free for the 
taking.

   LLMNR implementations MUST
   accept UDP queries and responses as large as the smaller of the link
   MTU or 8192 octets.

I suggest 9000 bytes, the Ethernet jumbo frame size, as a natural packet 
size to pick. Allowing 40 bytes for IPv6 header and 8 for UDP header, 
that leaves 8952 for the DNS message, which allows for an 8K resource 
record to be carried (should such a thing ever be needed in future).

   T Tentative.  The 'T'entative bit is set in a response if the
     responder is authoritative for the name, but has not yet verified
     the uniqueness of one or more of the resource record(s) in the
     answer section.  A responder MUST ignore the 'T' bit in a query, if
     set.  When a response with the 'T' bit set is received in response
     to a uniqueness query, a conflict has been detected and a responder
     MUST resolve the conflict as described in Section 4.1.

The document says nothing about how response with the 'T' bit set are to 
be interpreted by senders. Should they be ignored, or used in answer to 
the question?

     If an LLMNR responder is authoritative for the name in a multicast
     query, but an error is encountered, the responder SHOULD send an
     LLMNR response with an RCODE of zero, no RRs in the answer section,
     and the TC bit set.

What kind of error is this anticipating? Either the responder knows the 
answer, or it does not. Some example of a plausible error would motivate 
this section.

     Since LLMNR responders only respond to LLMNR queries for names for
     which they are authoritative...

Is this NAMES for which they are authoritative, or RRSETs (i.e. 
name+type+class) for which they are authoritative? In some places the 
document implies that a responder 'owns' a name exclusively, for all 
types and classes with that name, and in others it seems to assume that 
the unit of logical ownership is the RRSET.

   The sender MUST anticipate receiving multiple replies to the same
   LLMNR query, in the event that several LLMNR enabled computers
   receive the query and respond with valid answers.  When multiple
   valid answers are received, they may first be concatenated, and then
   treated in the same manner that multiple RRs received from the same
   DNS server would.

This means that, even when a query is successfully answered in (say) just 
10ms, the sender has to wait for the full LLMNR timeout before returning 
results to the caller, in case there are other responses coming?

   Upon configuring an IP address, responders typically will synthesize
   corresponding A, AAAA and PTR RRs so as to be able to respond to
   LLMNR queries for these RRs.  An SOA RR is synthesized only when a
   responder has another RR as well

Another RR in addition to A, AAAA and PTR?

   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?

   If TCP connection setup cannot be completed in order to send a
   unicast TCP query, this is treated 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).

If TCP connection setup cannot be completed after how long?

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.

   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?

   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.

   An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
   for each transmission.  For example, the algorithms described in RFC
   2988 [RFC2988] (including exponential backoff) compute an RTO, which
   is used as the value of LLMNR_TIMEOUT.  Smaller values MAY be used
   for the initial RTO (discussed in Section 2 of [RFC2988], paragraph
   2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph
   2.4), and the maximum RTO (discussed in Section 2 of [RFC2988],
   paragraph 2.5).

For this computation, does it use the first or last response received? Or 
the average?

Is the RTO value computed as a single global? Per interface? Per 
responding device? (Some devices are slower than others.)

In any case, this approach has the flaw that the computed RTT estimate 
converges to zero. Suppose you wait for t seconds before giving up. All 
responses you get necessarily arrive in less than t seconds (ones that 
arrive later are not seen). The average arrival time is therefore always 
less than t, so on the next iteration you compute a smaller RTT estimate. 
As RTT shrinks, more and more of the slower responses are lost, causing 
RTT to be estimated only from the fast-responding set.

A specification of how to do dynamic RTT estimation in a multicast 
scenario like this needs much more than just a reference to RFC 2988.

   If no response is received, the sender retransmits the query, as
   specified in Section 2.7.  If a response is received with the 'T' bit
   clear, the responder MUST NOT use the name in response to LLMNR
   queries received over any protocol (IPv4 or IPv6).  If a response is
   received with the 'T' bit set, the responder MUST check if the source
   IP address in the response, interpreted as an unsigned integer, is
   less than the source IP address in the query.

This suffers from auto-immune response, in the case where a machine has 
both Ethernet and wireless connections, and (unknown to the machine) the 
Ethernet and wireless networks are bridged together.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org