Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Mar 2004 17:17:11 -0800 (PST)

> Ok, although I would rather suggest:

> 1) Nodes should very that the source address of queries belong to an
> authorized range;

I'm not sure how to define an "authorized range".  A host may not know all
the prefixes present on a given link.

> 2) Use TTL=1 with TCP.

This makes sense.

> 3) No TTL requirements for UDP requests and responses, but recommend
> setting to 255 for compatibility with Rendezvous.

This only works if UDP unicast requests are prohibited. Otherwise, LLMNR
would send unicast PTR RR queries off the local link, which is not
acceptable.

An alternative would be to have no TTL requirements for multicast UDP
request and unicast UDP responses, but setting to 255 for compatibility
with Rendezvous.  But requiring either TTL=1 for UDP unicast queries or
get rid of unicast UDP queries entirely.

--
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: Mika Liljeberg <[email-masked]>
Date: Wed, 17 Mar 2004 08:07:22 +0200

> would send unicast PTR RR queries off the local link, which is not

Well, section 2.4 already says: "Unicast LLMNR queries SHOULD be sent
using TCP.  Senders MUST support sending TCP queries, and responders
MUST support listening for TCP queries."

> get rid of unicast UDP queries entirely.

Using different TTLs for different messages is awkward from the
implementation standpoint. It would be simplest just to require that all
requests and responses must be sent to the local link. E.g. use the
SO_DONTROUTE socket option.

	MikaL

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 17 Mar 2004 10:19:12 -0800

> the prefixes present on a given link.

The current solution of using TCP with a TTL of 1 makes the "authorized 
range" pretty simple to understand. Addresses in the authorized range 
are those that the host knows about. This highlights a problem with the 
current LLMNR draft. If there are two subnets overlaid on a local 
network and the hosts are unaware of the opposite subnet, LLMNR will 
make it impossible to resolve names of some devices on the same link 
just because they exist on a different subnet.

-josh

---

From: Mika Liljeberg <[email-masked]>
Date: Wed, 17 Mar 2004 21:20:56 +0200

Josh,

> just because they exist on a different subnet.

As far as I can see, that is only a problem with PTR queries, which
often fail anyway. And I'd wager overlaid subnets are not a very common
configuration. Do you think this is something we need to worry about?

	MikaL

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 17 Mar 2004 15:25:29 -0500

At 13:19 2004-03-17, Joshua Graessley wrote:

>range" pretty simple to understand. Addresses in the authorized range are 
>those that the host knows about. This highlights a problem with the 
>current LLMNR draft. If there are two subnets overlaid on a local network 
>and the hosts are unaware of the opposite subnet, LLMNR will make it 
>impossible to resolve names of some devices on the same link just because 
>they exist on a different subnet.

Good point,
so what TLL <= N works for you ?

N = 5 sounds good to me.
         Olafur

---

From: Paul Vixie <[email-masked]>
Date: Wed, 17 Mar 2004 21:22:10 +0000

> > ...  If there are two subnets overlaid on a local network and the
> > hosts are unaware of the opposite subnet, LLMNR will make it
> > impossible to resolve names of some devices on the same link just
> > because they exist on a different subnet.

that sounds like the right thing, since if they're on different subnets
then they will not be able to communicate even though those subnets are
in the same broadcast domain.

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 17 Mar 2004 14:13:00 -0800

My friends has a problem with his cable modem provider. He has paid 
extra to get extra addresses. The addresses are handed out using DHCP. 
The addresses are not always on the same subnet. I see no reason why 
LLMNR shouldn't work for him.

I may soon have a similar situation at home. I've got sDSL for a small 
server I run. I'm thinking about getting a cable modem connection so I 
can get stuff quicker. When I have that setup at home, I'll have two or 
more subnets running on the local network. All of the devices can 
communicate using their IPv4 addresses (albeit inefficiently). LLMNR 
should work in this situation but due to the TTL stuff it may not work.

I think there is a simple solution for IPv6. Always use the IPv6 
link-local addresses. The only solution that would work 100% of the 
time for IPv4 would be to use the same link-local multicast to send the 
response.

-josh

---

From: Paul Vixie <[email-masked]>
Date: Wed, 17 Mar 2004 23:23:34 +0000

> My friends has a problem with his cable modem provider. He has paid extra
> to get extra addresses. The addresses are handed out using DHCP. The
> addresses are not always on the same subnet. I see no reason why LLMNR
> shouldn't work for him.

i guess if your router is sitting on both subnets and you're willing to
go through a router to talk to other hosts in the same broadcast domain,
you're right there's no reason LLMNR wouldn't work.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Mar 2004 15:21:31 -0600

[ Moderators note: Post by non-subscriber.  With the massive amount of
   spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. ]

On Mar 17, 2004, at 12:19 PM, Joshua Graessley wrote:
> If there are two subnets overlaid on a local network and the hosts are 
> unaware of the opposite subnet, LLMNR will make it impossible to 
> resolve names of some devices on the same link just because they exist 
> on a different subnet.

I guess I don't understand why this is a problem.   A host that you 
can't talk to without going through a router isn't "local."   Why would 
we expect this to work?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Mar 2004 17:02:06 -0600

> LLMNR shouldn't work for him.

It shouldn't work for him because his network is misconfigured.    It's 
not the job of the IETF to arrange for it to be the case that any 
random configuration error still results in desired behavior, for any 
arbitrary value of "desired."

If you want this to work, you need to go check out the IPv4ll protocol 
and make sure that it does the right thing in this case.   And your 
friend needs to use IPv4ll.  Rendezvous works correctly in this case, 
doesn't it?

---

From: Andras Salamon <[email-masked]>
Date: Thu, 18 Mar 2004 18:14:36 +0200

On Wed, Mar 17, 2004 at 03:21:31PM -0600, Ted Lemon wrote:
> A host that you 
> can't talk to without going through a router isn't "local."

Why not?  Which part of the Internet-Draft does this violate?

From ...-29.txt:

    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.

The network overlay scenario is clearly "on link" according to the
above definition.

-- Andras Salamon                   [email-masked]

---

From: Andras Salamon <[email-masked]>
Date: Thu, 18 Mar 2004 16:54:57 +0200

> arbitrary value of "desired."

Exactly how is overlaying two IP network ranges onto one L2 infrastructure
misconfigured?

---

From: Andras Salamon <[email-masked]>
Date: Thu, 18 Mar 2004 17:32:58 +0200

> LLMNR shouldn't work for him.

This hits at the crux of what "Link-Local" means in the acronym LLMNR.

The above scenario (if indeed regarded as acceptable practice) will be
regarded by most people as "local".  During the original drafting of
the document, did the authors have a specific definition of "link-local"
in mind?  As I recall, the original spec came out of Stuart Cheshire's
work on replacing AppleTalk's naming service; this became Rendezvous and
branched off into LLMNR.  If this is the case, then the "local" definition
was pretty broad, and would probably cover the overlaid network scenario.

Also, in the above scenario, forcing TTL=1 will cause the router to
drop the packet before it is forwarded back onto the "other" part of
the local network.  Making TTL=5 (or any other number greater than 1
but less than the worst-case diameter of the Internet) seems to be an
ugly solution, and also gets away from the "link-local" part of LLMNR --
why not just call it "restricted scope MNR" then?  Or why not just drop
the TTL restriction altogether and just allow general MNR?

I repeat -- TTL checks are a kludge, and do not capture the idea of
"local" networks.  There are local networks for which TTL must be
greater than 1 to capture locality (eg. multiple IP ranges overlaid on
the same L2 medium as above), and there are distinctly non-local networks
(eg. LANs bridged through long thin pipes) for which any multicast can
cause great harm -- even with TTL=1.

In a message to this forum from Bernard Aboba in October 2003:

    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.

I've probably taken the above slightly out of context, but perhaps we
should go back to the original multicast slant of LLMNR and drop UDP
unicast, as suggested by Bernard in another message.  For multicast,
the TTL is irrelevant unless we are trying to compensate for potential
router bugs.  On the other hand, for TCP queries, the TTL should not be
restricted.  Then, interoperability with an existing protocol seems to
be a worthwhile goal, as long as it is not bought at a terrible price.
(Why was UDP unicast functionality introduced, anyway?)

At the end of the day, I just want to see some finality with LLMNR,
whatever it is!  Either it is going to be useless and Rendezvous will
win out in the marketplace, or it will be useful and over time it may
grow to take over from Rendezvous.  But right now LLMNR is by definition
useless, since it hasn't been finalised.

---

From: bill <[email-masked]>
Date: Thu, 18 Mar 2004 08:50:54 -0800 (PST)

> This hits at the crux of what "Link-Local" means in the acronym LLMNR.

	link-local is an unfortunate terminological choice.
	it might be useful to consider "single broadcast domain",
	which pretty much eliminates the overlay scenario. 

>  As I recall, the original spec came out of Stuart Cheshire's

	Hum... there were a series of efforts that hit confluence and
	then diverged...  the TBDS research, what became Rendezvous and 
	what might become LLMNR... all are varients that use DNS or DNSlike 
	stuff.

> -- Andras Salamon                   [email-masked]

--bill

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Mar 2004 12:36:42 -0600

> Exactly how is overlaying two IP network ranges onto one L2 

It is misconfigured in the sense that it does not do what the customer 
expects.   The customer expects that the two devices he or she has 
connected to the network will be able to communicate with each other 
without relying on the service provider.   This is unfortunately not 
true - they will not be able to communicate other than over the service 
provider's link, unless they implement Rendezvous (I do not believe 
that the current IPv4ll draft, for example, will allow them to 
communicate independent of the ISP).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Mar 2004 12:47:39 -0600

On Mar 18, 2004, at 9:32 AM, Andras Salamon wrote:
> During the original drafting of
> in mind?

Yes.   However, the current document bears only a passing resemblance 
to what the authors had in mind.   The original intention was that the 
two devices we're discussing would both have IPv4ll addresses, and that 
MDNS, as it was then called, would uses these addresses, not the 
globally-routable addresses.   Both the IPv4ll spec and the MDNS spec 
have been changed dramatically since then.   IPv4ll no longer works the 
way it did, and LLMNR doesn't either.

At this point, I have to say that it is my sincere hope that neither 
IPv4ll nor LLMNR make it to standard as they are currently constituted. 
  But if they do make it to standard, my next hope is that they do not 
fail to interoperate with Rendezvous.   If they do not interoperate 
reliably with Rendezvous, then the only purpose they will serve is to 
make sure that no reliable mechanism exists whereby two arbitrary hosts 
can automatically communicate with each other on the local link in the 
event that the DHCP server is not configured to enable this 
communication - by having two incompatible mechanisms that do roughly 
the same thing, we eliminate the possibility of dependable 
interoperability.

I sympathize deeply with your motivation to make LLMNR work correctly 
in the scenario we're talking about in the absence of any competing 
protocol, but that is not the domain in which we are operating.

---

From: Andras Salamon <[email-masked]>
Date: Fri, 19 Mar 2004 10:16:42 +0200

On Thu, Mar 18, 2004 at 12:34:32PM -0600, Ted Lemon wrote:
> On Mar 18, 2004, at 10:14 AM, Andras Salamon wrote:
> Sure, and you could argue that the definition you've quoted is correct 
> and that mine is wrong.

I'm not especially interested in arguing about whose definition is
right or wrong.  However, the current LLMNR Internet-Draft defines its
scope to include the scenario of address ranges overlaid onto the same
L2 infrastructure (maybe I'm wrong here, but no-one has yet objected).
Hence, either we need to change the wording of the I-D, or we need to
accept the wording and its consequences.