Subject: DNSEXT WGLC Summary: LLMNR

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Tue, 21 Oct 2003 15:24:04 -0400

This last call has concluded.
There was been extensive discussion about this draft.
A number of new issues raised and closed. The most new document
version (-24) reflects all the issues raised and closed in the
working group last call.

Summary: the working group has reached consensus to advance this
document as a standards track document.

This document is of high quality and the process that lead to this state
is well documented on the document issues
tracker website: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html.

Some issues raised during the last call that where rejected.  This is
normal and expected. This even holds for objections based on
shipping code tailored to an older version of this document, as no
specification is to be considered final until after publication as an RFC.
In particular there was extensive discussion about the TTL==[1 or 255]
in this case the WG decided that it had made the right choice by
selecting 1, see
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue 47
http://psg.com/lists/namedroppers/namedroppers.2003/msg01609.html

         Olafur 

--
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, 21 Oct 2003 19:10:48 -0700 (PDT)

On Wed, Oct 22, 2003 Mark Baker said:

>I concur.

>I hope the WG appreciates what a mess it's creating.  Is the TTL issue
>really *that* important?

Yes, it is.

If there is one critical achievement that is most important about the
Internet it is the ability of hosts from different vendors to interoperate
with TCP/IP.  Today it is possible to take two hosts from almost
any TCP/IP implementation and do things like transfer files (FTP).  We've
gotten so used to doing this that at times we don't appreciate how
valuable this is -- or how easily this basic interoperability can be
broken.

Whatever else we do in the IETF, there is one thing that a specification
must never do -- that is to break the basic interoperability of TCP/IP.
If a new IETF specification can somehow make it impossible
for two hosts which formerly interoperated to transfer a file that
specification is fundamentally broken. It's one thing to create useless
specifications -- but it's another thing to break fundamental aspects
of the Internet architecture.  The most important task of any IETF WG is
to "do no harm".

There are times when a poorly designed protocol, if deployed on a small
scale,  will not be harmful, but when deployed on a wide scale, can have
large undesirable effects.  The standardization of such a protocol cannot
be justified purely on the basis of its immediate usefulness -- in fact it is
precisely those protocols that are thought to be most useful which can
create the biggest problems.  So the issue here is not 'why doesn't the
IETF bless this cool thing', but rather "what are the implications
if this 'cool thing' were to be ubiquitously deployed on the Internet?"
As IETF participants, we have the obligation to look beyond the short
term to the long-term implications.

The reality is that the early IPv4 Link-Local and mDNS specifications,
were they to be widely deployed, have the potential to do serious damage.

In IPv4 Link-Local, setting TTL=255 in IPv4 and testing for this breaks
basic TCP/IP interoperability.  Most IPv4 hosts today do not set TTL=255,
and therefore any IPv4 host which requires TTL=255 in received packets
will be unable to communicate with most existing hosts.  If a host with a
routable IPv4 address does not use this when available, and sets and tests
for TTL=255, then it is possible for two hosts which both have routable
addresses and formerly were able to communicate will be unable to talk to
each other.

This behavior was considered so problematic that when the IPv4 Link-Local
specification went to IETF last call, there was an outpouring of concern
about the consequences of its ill-considered design.  As a result, the
ZEROCONF WG has had to spend the last year rewriting the IPv4 Link-Local
specification so as to "do no harm".  The current specification no longer
mandates a test for a TTL value, and prefers a routable address when
available.  It is perhaps not as "useful" as the early versions -- but it
also does not break the basic interoperability of TCP/IP.

Similar considerations arose in the design of the LLMNR protocol.  In
order to "do no harm" it was necessary to avoid adding new saddlebags to
an old hourse -- such as trying to use DNS as a global service discovery
mechanism, as DNS-SD does. It's one thing to ship something like this on a
small proportion of Internet hosts -- but it's another thing entirely to
attempt deploy something like that on a global scale.  Making major
modifications to protocols that form the fundamental underpinings of the
Internet (such as DNS and BGP) is not just another "bad idea" -- it has
the potential to cause major problems with the Internet architecture.

The DNSEXT WG wisely decided that going down this road was inappropriate.
It also decided that to avoid the potential for multicast storms it was
necessary to restrict use of mDNS to link-scope.  Furthermore, it was
critical to enforce port and cache separation so that LLMNR could not be
used to pollute the DNS cache and vice versa.

To "do no harm" LLMNR needs to guarantee that it will come up with the
same answer to a query as DNS would if the RRs are available, so that in
normal use the results of a gethostbyname() call do not depend on which
mechanism is used.  To avoid leaking IPv4 Link-Local addresses beyond
their scope, it is necessary for LLMNR to only return addresses and
names valid on the interface on which the query was received and also
to preferrentially return routable addresses when they are available.
As the issues list shows, each of these issues resulted in changes being
made to the LLMNR specification that caused it to diverge from the early
mDNS specifications, but each change was carefully considered and thought through.
While LLMNR has been a journey of a thousand steps, it is far from a
random walk.

While many of these decisions made LLMNR somewhat less 'useful' -- at the
same time, they also made major problems less likely.  The  Internet is no
longer an experiment today -- it's mission-critical infrastructure that
millions of people rely on every day.  That implies a higher level of due
diligence.

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 22 Oct 2003 00:34:56 -0700

> of the Internet architecture.  The most important task of any IETF WG 

At the end of the discussion listed for issue 2 "TTL=255 on send, check 
on receive?", the following suggests that the working group did not 
seem concerned with the issue of breaking things by using TTL 255.

"[BA] -

At IETF 56, the discussion seemed to indicate that sending with TTL=255
and checking on receipt would "do no harm" so that it was ok. The major
issues encountered in Zeroconf WG with IPv4LL don't seem to apply here,
since there are no legacy LLMNR implementations out there that set TTL 
to
something other than 255, so we have a clean slate. Also, even if the
IPv4LL draft doesn't specify setting or checking of TTL, an application
can still do so. So I'd like to recommend that we keep the existing -14
text that mandates setting TTL=255 and checking it."

I'm going to assume [BA] is short for Bernard Aboba.

I can find no argument on the issues page that TTL 255 would do harm. 
The first mention of using a TTL of 1 is in Issue 33: PTR via Unicast. 
That suggestion was that PTR queries be sent unicast and a TTL of 1 be 
used. Issue 34 "Unicast Query Transport Issues" suggests sending 
unicast queries using TCP and setting the TTL to 1. This isn't 
recommended because TTL 255 breaks anything, it is recommended in an 
attempt to make the responses more difficult to spoof.

The question of using some special domain such as ".local" surfaced a 
number of times. Use of a special domain such as dot-local would 
address many of the issues I brought up in my last email. The dot-local 
solution was always shot down with the response "use unqualified 
names". See issue #1. During the last call, Issue 45 was brought up, 
"Handling of Unqualified Names". The resolution was the removal of all 
references to unqualified names. The end result is no solution to Issue 
#1. A side effect of this is that Apple chose to use the top level 
domain 'local', being unable to get input other than "don't do that" 
from the working group. Instead of picking a domain that was likely to 
be unused and getting blessing so that everyone could coordinate and 
avoid using that domain, we picked a domain that was mostly unused and 
ran in to a few problems with sites that were using local as an 
internal domain. My impression is that the IETF exists to solve 
problems like that, not by ignoring them but by working through them.

The resolution to each of the LLMNR issues on their own may have made 
sense when only that issue was examined. The combination of the 
resolutions to each of these issues is a document that, while 
technically correct, has lost it's purpose.

I'm not sure what is to be done at this point. As one can see by 
reading the issues page 
<http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html>, the working 
group has spun on many of these issues a number of times. I do know 
that the draft, as it stands, is not useful.

> used to pollute the DNS cache and vice versa.

I never made any mention of DNS-SD. I never suggested that we use 
multicast beyond the local link for mDNS. I'm not sure where the 
discussion about separation of caches came in to play. mDNS does a 
better job of keeping things separate. mDNS does not resolve any query 
unless the name ends in dot-local. An mDNS answer will not overwrite 
any DNS entry unless that DNS entry ends in dot-local.

> mDNS specifications, but each change was carefully considered and 

I'm not sure I follow. You say that it must "come up with the same 
answer to a query as DNS would". You also mention issues of leaking 
link-local addresses beyond their scope. Link-local addresses are not 
supposed to be in DNS records. In the case where LLMNR is used, it does 
make sense to respond with link-local addresses that are relevant on 
that network. That's precisely what mDNS does. mDNS doesn't pretend to 
attempt to give the same answers DNS would.

> millions of people rely on every day.  That implies a higher level of 

Reading again through the list of issues and the resolutions, I don't 
see due diligence. I do see a pattern. The working group constantly 
goes back and forth on a number of issues, never really settling on one 
solution for very long. It seems more like the spec is what it is 
because it ended up in last call when it did. If we had gone on for 
another month or stopped a month earlier, who's to say it wouldn't be 
drastically different?

I don't know how to solve this problem. The same arguments will 
probably continue to play out. We could publish LLMNR as it is, and it 
would be largely useless. We could attempt to address some of the 
issues, but we might just get stuck spinning again. How do we solve 
this?

-josh

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Oct 2003 09:04:11 -0700 (PDT)

>on receive?", the following suggests that the working group did not seem
>concerned with the issue of breaking things by using TTL 255.

It's worth understanding the history here.  The decision to set TTL=255
and check it on reception within mDNS was largely based on this same
technique being use in early IPv4 Link-Local versions.  However, doing
this in IPv4 Link-Local breaks TCP/IP interoperabilty and so the ZEROCONF
WG chose to overturn this.  Since the only existing hosts setting TTL=255
and checking it in mDNS are also doing this within IPv4 Link-Local, those
hosts are unable to communicate with the majority of existing TCP/IP
hosts.

It's not possible to achieve "backward compatibility" with an
implementation that is not interoperable with TCP/IP.  What use is it to
be able to resolve the name of a host that will drop all packets sent
to it because they don't have TTL=255?  That's just a recipe for user
frustration. If no real interoperability is achievable, then at least we
need to ensure that the separate flavors of TCP/IP do not interfere
with one another.  That's why LLMNR operates on a separate port and
multicast address than mDNS.

>number of times. Use of a special domain such as dot-local would address
>many of the issues I brought up in my last email.

As detailed in Issue #22, this was extensively debated and no real
benefits were found to using the ".local" domain.  If two machines are
trying to communicate, one named erik.sun.com and another named
bernard.microsoft.com, then for names to be resolved it is
necessary to add ".local" to the searchlist, so that a query for
erik.sun.com.local can be made. But this just results in additional
packets on the wire for no real benefit.

>resolutions to each of these issues is a document that, while technically
>correct, has lost it's purpose.

The "purpose" that you're referring to is service discovery, not name
resolution.  LLMNR focusses only on name resolution -- but since there was
never IETF consensus on use of mDNS for service discovery, it's hard to
argue that this purpose was "lost".  LLMNR *does* solve the link-scope
name resolution problem.

>I'm not sure what is to be done at this point. As one can see by reading
>the issues page <http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html>,
>the working group has spun on many of these issues a number of times.

It's true that there has been a lot of debate and reversal of positions. I
attribute this to a lack of an appreciation of the difficulties involved
in touching fundamental aspects of the Internet architecture -- IPv4 and
name resolution.  That kind of tinkering simply cannot proceed except with
extreme caution.  The early versions of the IPv4 Link-Local and mDNS
specifications did not exhibit the required due diligence. I fear we will
be dealing with the damage they created for years to come.

>In the case where LLMNR is used, it does make sense to
>respond with link-local addresses that are relevant on that network.

Sure, but not in preference to routable addresses if available.  In order
to "do no harm" it is necessary for two hosts with routable addresses to
be able to continue to interoperate with TCP/IP, even if they differ in
their implementation of IPv4 Link-Local.  For that to work, routable
addresses need to be preferred.

>That's precisely what mDNS does. mDNS doesn't pretend to attempt to give
>the same answers DNS would.

This causes breakage where the IPv4 Link-Local implementations are not
interoperable (as they are not today).

> If we had gone on for another month or stopped a month earlier, who's to
> say it wouldn't be drastically different?

Both the IPv4 Link-Local and LLMNR specifications have changed a lot in
the last year, but they have changed consistently as the result of a
better understanding of the problems caused by the early IPv4 LL and mDNS
specifications.  The consistent justification for the changes has been a
concern for maintaining basic TCP/IP interoperability, which is the
foundation of the Internet as we know it.

>We could attempt to address some of the issues, but we
>might just get stuck spinning again. How do we solve this?

If there were interest in a genuine solution, it would start by giving up
on the TTL=255 check in IPv4 Link-Local implementations, and preferring
routable addresses where available.  If that were done, at least basic
TCP/IP interoperability could be maintained.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Oct 2003 19:57:46 -0700 (PDT)

>You have hosts with names like erik.sun.com and bernard.microsoft.com,
>therefore, you see no benefit. If someone has a host with a private
>address, a very common scenario in homes and small offices thanks to the
>evils of NAT, their host has no name.

Why does their host not have a name? The hostname need not be dependent on
the address.

> They can't use LLMNR.

Sure they can.  LLMNR doesn't care what the host's IP address is.

> LLMNR doesn't provide a way to name a host.

Why does a name resolution protocol need to take care of selection of host
names?  In many cases today the hostname is selected by the OEM and ships
with the PC or device.

> Originally, it was proposed that people use unqualified names.

In -24 LLMNR can be used to query any RR for any name.  So
there's no need to care about the definition of an "unqualified name".

>The interoperability problem lies in implementations of IPv4LL that check
>for TTL 255. This has nothing to do with LLMNR or mDNS.

It does, because it has been suggested that if LLMNR were to adopt
set TTL=255, check on reception, then interoperability would result. On
August 30, 2003 the DNSEXT WG Co-Chair Olaf Kolkman asked for a list of
*all* the changes that would be required beyond just the TTL change:

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

To this day there has been no response to this question.  I believe it is
accurate to say that just making the TTL change would not generate any
useful interoperability scenarios, because an LLMNR responder still would
not respond to a query for a ".local" name.

Even if it were to do that (for backward compatibility sake), we *still*
wouldn't have interoperability if the LLMNR host also didn't implement
DNS-SD.  And even if it did that, we wouldn't have interoperability where
IPv4 Link-Local addresses were used unless the LLMNR host also set
TTL=255 on send.

Given this, it's hard for me to conclude that the requested TTL change
has any purpose beyond producing "PowerPoint interoperability" -- the
ability to claim conformance without real interoperability.

If this is wrong, please enlighten us with the details of what changes are
needed in order to achieve some useful level of interoperability.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Oct 2003 22:52:52 -0500

> Why does their host not have a name? The hostname need not be 

My computer's name right now is "mdzadpa".   When I got it, it didn't 
have a name.   It chose a name when I customized it - the name it chose 
was "Ted Lemon's Computer".   This is very like what Microsoft's own 
software does, although I think it would have chosen the name 
"TEDLEMON".

Now, how does my computer go from here to having a fully-qualified 
name?   I bought it to use at home.   It doesn't belong to my employer. 
   It's not "mdzadpa.nominum.com."   It doesn't belong to my ISP.   It's 
not "mdzadpa.speakeasy.net."  For the average user, this is not going 
to change.   It really doesn't make sense for the computer to identify 
itself as either of the two fully-qualified names I just suggested, 
and, indeed, my ISP wouldn't let me identify my computer that way.

So for my computer to go around claiming to be "mdzadpa.speakeasy.net." 
would be incorrect behavior.   That is not its name.   This is true 
whether my computer is a Mac or a PC.   Unix machines, maybe less true. 
   Linux, I don't know.   Cell phones, all bets are off.   But for the 
vast majority of the computers that are presently connected to the 
network and that could benefit from LLMNR, there is no correct FQDN to 
assign them.   So if you don't have a rule for producing an FQDN based 
on the unqualified name the user chose, that computer simply is not 
going to be able to identify itself using LLMNR.   This means that 
LLMNR is effectively useless for the vast majority of all computers on 
which it's ever likely to be implemented, unless the LLMNR 
implementation does something extra-protocular to generate an FQDN.

Perhaps the right thing is to specify the protocol by which this name 
is derived separately, but if so, we should say that that's the answer, 
not pretend that the problem need not be solved.