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

From: Mika Liljeberg <[email-masked]>
Date: Wed, 17 Mar 2004 08:07:22 +0200

On Wed, 2004-03-17 at 03:17, Bernard Aboba wrote:
> > 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.

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

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

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

--
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, 17 Mar 2004 10:19:12 -0800

On Mar 16, 2004, at 5:17 PM, Bernard Aboba wrote:

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

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

---

From: Mika Liljeberg <[email-masked]>
Date: Wed, 17 Mar 2004 08:07:22 +0200

MikaL

---

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

-josh

---

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

Josh,

	MikaL

---

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

Good point,

N = 5 sounds good to me.
         Olafur

---

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

---

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

---

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