Subject: Re: DNSEXT WGLC Summary: LLMNR

From: Joshua Graessley <[email-masked]>
Date: Wed, 22 Oct 2003 13:58:02 -0700

On Oct 22, 2003, at 9:04 AM, Bernard Aboba wrote:

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

Part of that history is that the IPv4LL working group got this idea 
from IPv6 Neighbor Discovery. IPv6 Neighbor Discovery uses TTL 255. It 
is not encumbered with the need to interoperate with legacy clients. 
You said:

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

Mac OS X is not the only thing shipping with mDNS support. In addition, 
there is no problem with communicating with other hosts using TCP/IP 
whether or not an IPv4LL address is used. The check is not actually 
performed for IPv4LL traffic. I'm not sure why you keep bringing up 
IPv4LL.

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

The interoperability problem lies in implementations of IPv4LL that 
check for TTL 255. This has nothing to do with LLMNR or mDNS. LLMNR and 
mDNS can be used wether the hosts have IPv4LL addresses or any other 
address (IPv4 or IPv6).

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

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. They can't use LLMNR. 
Originally, it was proposed that people use unqualified names. As noted 
in Issue 45, there is no such thing as an unqualified name, so 
resolving unqualified names using LLMNR made no sense and was stripped 
out of the document. This is my major gripe with this document as it 
stands. My first email didn't even mention the TTL issue.

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

When have I mentioned service discovery. None of the three examples I 
listed in the first email were related to service discovery. Masataka 
Ohta pointed out a solution to one of the three scenarios in his 
response. The other two have no solution with LLMNR. LLMNR doesn't 
solve name resolution in ad-hoc networks because there is no way that a 
host can know what name to use. LLMNR also fails in situations such as 
home networks were private addresses are used with a NAT. It would be 
convenient to use name resolution to look up the name of other hosts on 
the private network. There is no suggestion on what sorts of names a 
host on these networks should use to avoid conflicting with names in 
DNS.

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

I don't know why you keep going back to IPv4LL, that is irrelevant to 
LLMNR, except with respect to how such addresses should be handled when 
responding to an LLMNR query.

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

I'm in complete agreement. I don't really know what this has to do with 
the usefulness of LLMNR or how it compares to mDNS.

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

LLMNR has nothing to do with TCP/IP interoperability. I don't know why 
you keep confusing the two issues. These are two separate issues. 
IPv4LL has nothing to do with this discussion.

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

Isn't this an issue for the zeroconf working group to tackle with the 
IPv4LL draft?

-josh

---

From: masataka ohta <[email-masked]>
Date: Thu, 23 Oct 2003 07:42:44 +0900

Joshua;

> response. The other two have no solution with LLMNR. LLMNR doesn't solve 
> name resolution in ad-hoc networks because there is no way that a host 
> can know what name to use.

What's wrong with a globally unique domain name configured at
factory?

> LLMNR also fails in situations such as home 
> networks were private addresses are used with a NAT. It would be 
> the private network.

Can I assume that the only DHCP and the only DNS servers of the
home network is collocated on the NAT box?

Then, a host can tell its domain name to the box through DHCP
and the DNS server of the box can synthesis appropriate mapping.

That is, we don't need multicast.

						Masataka Ohta

--
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 15:56:29 -0700

On Oct 22, 2003, at 3:42 PM, masataka ohta wrote:

>> solve name resolution in ad-hoc networks because there is no way that 
>> a host can know what name to use.
>

I think the point of having a name is that it's easier to remember than 
an address. This is especially important when using IPv6LL addresses in 
an ad-hoc environment. Having to remember the name 
pbg4-b9-47-4c.names.apple.com would not be very useful. Being able to 
use a name like "joshs-powerbook" or "joshs-powerbook.llmnr." would 
make life simpler. Of course, this relies on good conflict detection, 
but a lot of that was stripped out of the document, assuming more that 
those who control the DNS name space will be responsible for handing 
out the names that are used with LLMNR.

>> LLMNR also fails in situations such as home networks were private 
>> addresses are used with a NAT. It would be convenient to use name 
>> resolution to look up the name of other hosts on the private network.
>

There are no NAT boxes, to the best of my knowledge, that do this 
today. If an implementation of LLMNR existed, and it was made to be 
useful in these scenarios, one could simply install LLMNR on the 
devices on the network without having to upgrade the NAT box.

Even if NAT boxes did this, what domain name would the host tell the 
box it has?

-josh

---

From: masataka ohta <[email-masked]>
Date: Fri, 24 Oct 2003 08:56:27 +0900

Josh;

> pbg4-b9-47-4c.names.apple.com would not be very useful.

No, it is not, though your example is only as bad as raw IPv4
addresses. Wise vendors will use names more friendly to users.

> Being able to 
> use a name like "joshs-powerbook" or "joshs-powerbook.llmnr." would make 
> life simpler. Of course, this relies on good conflict detection,

What can you do if there is a conflict on "joshs-camera"? Note
that cameras have no keyboard.

Note also that a vendor can configure a camera of a registere
user as:

	"camera0.josh-12.apple.com"

> There are no NAT boxes, to the best of my knowledge, that do this today.

Tell NAT box vendors to do so, then.

That NAT boxes do or do not do something is not a valid reasoning
to affect protocol development over the Internet.
 
> Even if NAT boxes did this, what domain name would the host tell the box 
> it has?

See above.

							Masataka Ohta

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 23 Oct 2003 21:10:21 -0700 (PDT)

>This is only true if the computer performing the lookup doesn't have a
>list of search domains or there is no tedlemon.<search domain(s) here>.
>Example: User has DSL and NAT. Their ISP has told them to use the search
>domain example.net and use "mail" as the mail server name. This is a
>really stupid way to set things up, but it is fairly common. There exists
>a tedlemon.example.net. Ted Lemon visits, and hooks up his laptop. He's
>using the name "tedlemon". He tells Joe to connect to his web server
>(http://tedlemon/). Joe types it in, hits return. Joe gets a connection
>error because tedlemon.example.net resolved and isn't running a web
>server. Joe can not use a name to access Ted Lemon's computer.

Nope.  LLMNR was explicitly designed to work in this scenario. Section 3
says:

"By default, LLMNR requests SHOULD be sent only when no manual or
automatic DNS configuration has been performed, when DNS servers do not respond, or
when they respond to a query with RCODE=3 (Authoritative Name Error) or
RCODE=0, and an empty answer section."

Also:

"[1] If a DNS query does not receive a response, prior to falling
    back to LLMNR, the query SHOULD be retransmitted at least
    once.

So the LLMNR sender would try "tedlemon.example.net" and would get back
and error and then it would fall back to an LLMNR query for "tedlemon"
eventually.

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 23 Oct 2003 23:24:09 -0700

> and error and then it would fall back to an LLMNR query for "tedlemon"

In the case stated above, there is DNS configured and there is a 
tedlemon.example.net. LLMNR would never be used. DNS would receive a 
response and never fall back to LLMNR.

-josh

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Oct 2003 00:49:37 -0500

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

> and error and then it would fall back to an LLMNR query for "tedlemon"

Only if there is no tedlemon.example.net.   If there is one, it will 
get the wrong answer.   This is because there is no way to say "I mean 
LLMNR."   I can't say "ping tedlemon.llmnr" - all I can do is say "ping 
tedlemon", which is ambiguous.