Subject: Re: LLMNR is done

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Jan 2004 08:53:33 -0800 (PST)

>	maybe a stupid question (sorry) - has the interop issue with Apple
>	Rendezvous implementaiton resolved?  if not, i don't think the
>	protocol useful.  of course both Apple side as well as LLMNR side
>	should make effort to make it interoperable (Apple cannot just
>        force LLMNR be compatible with Rendezvous), in my opinion.

On  August 29, 2003 Olaf Kolkman posted the following message to the
DNSEXT WG mailing list summarizing the situation:

http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01620.html

In this message, he made the request that *all* changes required to
achieve interoperability be provided.  No answer was received.

Subsequently, I went back over the Rendezvous documents to look at the
differences.  These go well beyond the TTL and multicast address choices.
mDNS and LLMNR have taken different approaches on more than half a dozen
different points, many going back to the earliest drafts.  The
differences are more than cosmetic because the protocols began from
different assumptions and problem statements, and evolved in separate
ways from the beginning.  At this point, the protocols only share some
similarities in the use of the DNS packet format, and even here the
differences are substantial.

To sum up the situation, on October 6, 2003, Olafur posted the following
reply:
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01872.html

Known differences between Rendezvous and LLMNR
----------------------------------------------
a. Rendezvous uses multicast responses.  LLMNR uses unicast.
b. Rendezvous allows proxying; LLMNR does not.
c. Rendezvous uses the header bits differently, including AA, TC, RD,
RA, AD, CD
d. Rendezvous and LLMNR uses different retransmission strategies and
timers.
e. Rendezvous uses ".local" extension, LLMNR does not.
f. Rendezvous requires TTL=255; LLMNR uses TTL=1.
g. LLMNR supports unicast queries; Rendezvous does not.
h. LLMNR and Rendezvous use different multicast addresses and ports.

--
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: Mon, 26 Jan 2004 20:04:36 -0800

>In this message, he made the request that *all* changes required
>to achieve interoperability be provided.  No answer was received.

Unfortunately, *everything* seems subject to intense debate, even what 
the list of things to debate is. Before embarking on that debate, I asked 
if the working group had any interest in working for interoperability 
with the installed base. No answer was received.

>Known differences between Rendezvous and LLMNR

I think there are some misperceptions here; I should correct them.

>a. Rendezvous uses multicast responses.  LLMNR uses unicast.

Rendezvous uses both unicast and multicast responses, depending on what 
is most efficient. If only one client is likely to want a particular 
response, then unicast is used. If multiple clients are likely to want 
the response, then multicast is used.

>b. Rendezvous allows proxying; LLMNR does not.

Sleep proxy servers for power management are an important part of meeting 
Energy Star and Blue Angel energy consumption requirements. As the limits 
get tighter and tighter each year, it is going to become increasingly 
hard to sell products that don't have this kind of intelligent power 
management.

>c. Rendezvous uses the header bits differently, including AA, TC, RD,

Can you elaborate? I'm not aware of any substantive differences.

>d. Rendezvous and LLMNR uses different retransmission strategies and

Surely these are trivial differences that could be easily agreed.

>e. Rendezvous uses ".local" extension, LLMNR does not.

This is a red herring. The dot-local debate exists at a layer above 
Rendezvous/LLMNR. Apple (and others) use dot-local to trigger an explicit 
multicast query; other names may be looked up according via unicast or 
multicast depending on situation, just as with LLMNR.

>f. Rendezvous requires TTL=255; LLMNR uses TTL=1.

The TTL check is, as you know, to guarantee that packets really 
originated on the local link (*especially* unicast replies). I'm told 
that in the latest Windows XP Service Pack lots of services have been 
locked down the local link by default for "security", so I would have 
thought that having the ability to do the same for LLMNR would have met 
with Microsoft's approval in the current climate. Note that setting the 
TTL to 255 allows the receiver to check the TTL; it doesn't *require* the 
receiver to check if it doesn't want to.

>g. LLMNR supports unicast queries; Rendezvous does not.

Incorrect. Rendezvous supports unicast queries as well as multicast, and 
always has.

>h. LLMNR and Rendezvous use different multicast addresses and ports.

This is the ultimate red herring. They only use different multicast 
addresses and ports because of perceived differences (a)-(g).

So, as I have said before, the only real show-stopping incompatibility I 
see is the decision on the TTL.

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Jan 2004 18:49:16 +0000

> I really have a hard time with the idea that LLMNR & Rendez-vous address
> different needs.

nevertheless i think the llmnr authors might in fact intend it for
a different use, in which case we could expect to see microsoft and
apple each implement both rendezvous and llmnr, which would lead to...

> There is so much overlap that, in a normal worl, convergence would be
> the most sensible avenue.

...convergence.  in which case, as long as ietf advances them in tandem,
and with well written applicability statements to motivate implementors
to put both of them in (where appropriate), then...

> If we, as a collection of vocal individuals, cannot put ego aside and
> can't converge, please, at least, let's make those two interoperable.

...we will have done the job we agreed to do when attending ietf functions.

if on the other hand alain (quoted above) is correct and these protocols
address identical needs or significantly overlapping needs, then it would
be irresponsible of us to advance both drafts, or to advance only one.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 27 Jan 2004 14:01:05 -0500

Following up on Bernard's assessment of the relationship between LLMNR and 
Rendezvous:

At 08:53 AM 1/26/2004 -0800, Bernard Aboba wrote:
>[...] The

My understanding is that LLMNR is designed:

* to avoid interference with and pollution of DNS information
* to transition gracefully to DNS
* to avoid generating bogus .local queries
* to avoid redfining key IP concepts like TTL
* to use TTL correctly so that LLMNR traffic is confined to a link, rather
   than redefining TTL to provide security (whch it doesn't provide, anyway)

I'm working here from observation,  not from any requirements explicitly set
out in <draft-ietf-dnsext-mdns-29.txt> or the dnsext WG charter...

- Ralph

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Jan 2004 19:26:08 +0000

> Paul - can you explain what you mean by "without either one of them having
> an ip address".  If I take that statement literally, I wonder why the IETF
> would be interested in a protocol that doesn't use IP?
> 
> - Ralph

i misspoke.  there was no dhcp server, no dhs server, no server of any kind.
of course there were ip addresses, but they were self assigned and invisible
to the user.

to get a non-rendezvous laptop to see a non-rendezvous desktop printer, i'd
have had to set, or at least know, one or both ip addresses.  and there would
not have been a way to get it to show up in the chooser/browser tool.

what this really comes down to is applicability.  yesterday here, aboba said
that rendezvous and llmnr were different protocols intended for different
uses.  if the community agrees, then both docs should be advanced, with clear
applicability statements.  if the community doesn't agree, then a new/merged
specification should be developed and advanced, with a notation that apple's
existing protocol is to enjoy no special advantage, regardless of the size
of their installed base.

re:

> At 05:38 PM 1/27/2004 +0000, Paul Vixie wrote:
> 
> >for example, i saw a demo where a mac found a desktop printer without
> >either one of them having an ip address, and a mac found an mp3 jukebox
> >without either one of them having an ip address.  the chooser/browser
> >widget just came up and showed what it found.  is this sufficiently
> >different from llmnr's target and purpose that we can reasonably say
> >that both protocols can be advanced, and both will be in the field, and
> >they are not competing approaches to the same problem space?
> 
> 
>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Jan 2004 19:34:38 +0000

> Where is Rendezvous under consideration in the IETF?

http://www.zeroconf.org/Rendezvous/
http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt

> I would be glad to see an informational RFC specifying Rendezvous.

i think that would be a cop-out.  if dns-sd ("apple's rendezvous") and
llmnr have the same target audience, then the existence of both protocols
is an indication of chaos or irresponsibility (depending on how far it
goes before it's stopped).  if they have different target audiences, then
both should be advanced, on the standards track, with clear applicability
statements to tell implementors which one they need, or why they need both.

---

From: Brad Hards <[email-masked]>
Date: Wed, 28 Jan 2004 18:58:15 +1100

> i think that would be a cop-out.  if dns-sd ("apple's rendezvous") and
The bit of Rendezvous you want is MDNS. DNS-SD is a peer to protocols like SLP 
(which could do name<->address conversion, but isn't really intended for 
that.

> statements to tell implementors which one they need, or why they need both.
These look pretty similar to me:

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.
The goal of LLMNR is to enable name resolution in scenarios in which
conventional DNS name resolution is not possible.  Since LLMNR only
operates on the local link, it cannot be considered a substitute for
DNS.

Abstract
   As networked devices become smaller, more portable, and more
   ubiquitous, the ability to operate with less configured
   infrastructure is increasingly important. In particular, the ability
   to look up host names and similar DNS resource record data types, in
   the absence of a conventional managed DNS server, is becoming
   essential.

I don't think those could be considered to be addresses distinct audiences. 
Where is the difference?

Brad

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Jan 2004 09:27:24 -0600

On Jan 28, 2004, at 5:33 AM, John Schnizlein wrote:
> It is worth noting that this 11th hour attempt to reverse the TTL=1
> decision in this WG is much like the 11th hour (after the chair
> announced ROUGH consensus) change in the Zero-Conf WG.

John, this isn't an 11th-hour attempt.   We've been arguing about this 
for several years now, without reaching consensus.   If you had the 
impression that there was consensus, it's only because the people who 
do not participate in the "consensus" have been quiet for a while 
because we have little hope that saying anything will be productive.

> There also,
> the old history of earlier consideration of TTL=1 was presented
> as justification for the reversal to support TTL=255. The change
> of the meaning of this field in the IP header is unnecessary and
> risky. That it hasn't caused trouble yet is insufficient justification.

Yes, you and several other people have repeatedly made this assertion.

So because of this, we will have two non-interoperating protocols that 
do the same thing.   That's a real world problem that can be 
demonstrated on networks today.   How do I know?   Because it's already 
caused trouble for me personally and for people for whom I provide 
network support - people who are not John Schnizlein or Ted Lemon and 
cannot debug these problems without our help.   This interoperability 
problem is a direct result of what appears to be a completely 
theoretical argument.

> Why all this new reference to Rendezvous? Note that it was not
> mentioned in the Zero-Conf charter at all. Zero-Conf progressed
> as if independent of a single vendor's implementation until near
> the end.

Rendezvous happened, as far as I can tell, because the Zeroconf working 
group failed.   By which I mean that although there was strong 
agreement among proponents of zeroconf about what to do, there was 
strong resistance to the idea of the IETF pushing any kind of zeroconf, 
and this prevented the working group from succeeding.   We have some 
drafts in/near last call now, but it's a Pyrrhic victory - I'd rather 
implement Rendezvous than zeroconf.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Jan 2004 13:05:37 -0800 (PST)

LLMNR was designed to handle situations in which hosts are highly
mobile, and to be extensible to use in larger scopes, if the initial
deployments prove successful.  These situations do not lend themselves
to multicast responses.

For a highly mobile situation, with a DNS TTL close to zero, multicast
responses are not useful to any host other than the one sending the
original query, yet they need to be processed by all hosts for marginal
benefit.

Multicast responses also do not scale beyond link-local scope to
situations where hundreds or even thousands of hosts could be listening
across a site. Given the design goals of LLMNR, multicast queries were
precluded early on.

While the content of queries might indeed be a higher layer issue,
it is very relevant to the interoperability question.  A host sending
a query for a ".local" name will not receive a response unless the
target also is configured with a ".local" name.  So in practice,
converging LLMNR and Rendezvous yields no useful benefits unless
the hosts also adopt the Rendezvous namespace model.

The problem with that model is that it requires users to either
type the ".local" extension, or for ".local" to be put into the
searchlist.  The former is a problem for users used to a flat
namespace (e.g. http://foo, which can be resolved via RFC 1001-1002,
NetBIOS over TCP/IP).  The latter results in lots of bogus
".local" queries.

In terms of proxying and power management, name conflict detection
can be run when systems power up again, and since name conflicts
are relatively unlikely, there is no need in LLMNR to
deploy proxies for this purpose, particularly in mobile
environments where they are likely to be serving up out of
date information.  In any case, since proxies depend on multicast
responses, once those are eliminated to improve scaling, they
can't be used anyway.

In terms of differing uses of the header bits, and other sections
of the DNS packet, almost every bit and field is used differently
in LLMNR and Rendezvous.

LLMNR does not allow multiple questions in a query, since these
are known to cause confusion.  Therefore there is no need to use the
TC bit in a query, as Rendezvous does.  Since LLMNR is not a service
discovery protocol, there is no need to implement known answer
suppression.

Since in LLMNR there are no proxies or non-authoritative answers, there
is no need to use the RA or AA bits either.

LLMNR specifies more strict handling of SOA and NS RRs in
order to handle the different delegation model of a peer-to-peer
name resolution protocol.

The CD or AD bits do not apply to a peer-to-peer name
resolution protocol where there is no implicit trust, so LLMNR does not
use them.

In order to be compatible with DNSSEC, LLMNR requires support
for EDNS0, which has its own way of handling MTU issues.  In
LLMNR automatically sending a packet of link MTU size would
not be wise because of the need to allow extension to larger
scopes going forward. So LLMNR and Rendezvous don't even handle MTU issues
the same way.

Rather than disallowing all non-zero RCODEs, LLMNR allows
error messages to be used in response to unicast queries,
in order to permit problem diagnosis and enable use of
DNSSEC & TSIG.

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 28 Jan 2004 14:27:53 -0800

> across a site. Given the design goals of LLMNR, multicast queries were

I'm confused. LLMNR is only useful when there is no configured DNS, 
otherwise all queries go to unicast DNS and only fall back to LLMNR if 
the unicast DNS query fails (which one can not rely on). What sort of 
scenario are you likely to run in to where there would be no unicast 
DNS but there are routers configured to handle multicast? Where is this 
mentioned as a design goal?

It seems like LLMNR has a subset of the mDNS functionality. LLMNR 
focuses on solving the problem of resolving DNS entries when there is 
no DNS server. mDNS attempts to solve the problem of resolving DNS 
names when there is no DNS as well as resolving names even when there 
is a configured DNS server. In a number of situations, people may end 
up on the same network where names for the addresses they receive are 
arbitrary or nonexistent. A common example would be two people meeting 
in an airport and joining the same wireless network at the airport. If 
they had private addresses, there would be no point in using dynamic 
DNS to register their address. LLMNR wouldn't work.

-josh

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Jan 2004 15:45:39 -0800 (PST)

>I'm confused. LLMNR is only useful when there is no configured DNS,

LLMNR can be used where there is a configured DNS server as well, but
where the DNS server doesn't answer, or responds with RCODE=3 or RCODE=0
and no answers in the answer section.  See Section 2 for details.

Also note that LLMNR prefers unicast queries for PTR RRs, and does not use
multicast responses, to avoid unnecessary multicast traffic that would
become a problem if the scope were expanded beyond link local. See Section
2.4.

>What sort of scenario are you likely to run in to where there would be no
>unicast DNS but there are routers configured to handle multicast? Where
>is this mentioned as a design goal?

If the user has a router at home that includes support for DHCPv4 only and
no support for IPV6 DNS configuration or resolution of AAAA queries, then
LLMNR can be used to resolve names of IPv6-only hosts on the local
network.  See Section 3.1.

>It seems like LLMNR has a subset of the mDNS functionality.

mDNS is focussed on discovery of stationary services. LLMNR is about name
resolution in environments which may be highly mobile.  They are different
problems and different design choices were made to address them.

>LLMNR focuses on solving the problem of resolving DNS entries when there
>is no DNS server. mDNS attempts to solve the problem of resolving DNS
>names when there is no DNS as well as resolving names even when there is
>a configured DNS server.

LLMNR handles both situations.  LLMNR can be used to resolve any name. See
Section 2.

>If they had private addresses, there would be no point in using dynamic
DNS to register their address. >LLMNR wouldn't work.

LLMNR can resolve a name with any kind of address. LLMNR doesn't rely on
dynamic DNS or support dynamic DNS update op codes.  See Section 2.1.

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 29 Jan 2004 14:50:42 -0800

> and no answers in the answer section.  See Section 2 for details.

Counting on DNS to return RCODE=3 or RCODE=0 with no answers is error 
prone. Unless you or someone you know is responsible for a domain, you 
can't guarantee that a query will fail. If you use an unqualified name, 
the resolver may attempt to append a search domain first, which may 
result in a successful unicast DNS query for a name you were not 
expecting. Maybe I'm missing something obvious? Otherwise, it seems 
that LLMNR is unreliable (nearly useless) when there is a configured 
DNS server.

-josh