Subject: Re: DNSEXT WGLC Summary: LLMNR

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.

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