Subject: Re: LLMNR Issue 39: Name conflict detection algorithm

From: Joshua Graessley <[email-masked]>
Date: Mon, 12 May 2003 14:20:02 -0700

On Monday, May 12, 2003, at 12:46 US/Pacific, Bernard Aboba wrote:

> Submitter: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: May 12, 2003
> Reference: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue 
> 39
> Document: LLMNR-18
> Comment type: T
> Priority: S
> Section: 4
> Rationale/Explanation of issue:
>
> It isn't clear to me that the name conflict detection mechanism
> defined in Section 4 makes sense. Here is what it says:
>
> "The name conflict detection mechanism doesn't prevent name
> conflicts when previously partitioned segments are connected by a
> bridge. In such a situation, name conflicts are detected when a sender
> receives more than one response to its LLMNR multicast query.
> In this case, the sender sends the first response that it received to 
> all
> responders that responded to this query except the first one, using UDP
> unicast. A host that receives a query response containing a UNIQUE 
> resource record that it
> owns, even if it didn't send such a query, MUST verify that no other
> host within the LLMNR scope is authoritative for the same name, using
> the mechanism described above. Based on the result, the host detects
> whether there is a name conflict and acts accordingly."
>
> I don't like the idea of sending unsolicited UDP responses. The
> goal here is to enable hosts involved in a conflict to become
> aware of it more quickly.
>
> A potential alternative is to mandate that hosts send an LLMNR query
> for their own name at some convenient interval (every 30 seconds?)

It seems another alternative might be to send all responses using 
multicast instead of unicast. This would give hosts a chance to detect 
conflicts much quicker. The same trick is used with IPv4LL and ARP. The 
ARP responses are broadcast to facilitate in quicker discovery of 
conflicts. The multicast responses could be used to populate a local 
LLMNR cache on all hosts possibly reducing the number of queries that 
must be sent.

-josh

--
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: 13 May 2003 00:50:02 +0300

On Mon, 2003-05-12 at 22:46, Bernard Aboba wrote:
> Reference: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue 39
> Document: LLMNR-18
> Comment type: T
> Priority: S
> Section: 4
> In this case, the sender sends the first response that it received to all
> unicast.

We no longer need to do this, since responses are now sent to a single
multicast group. All responders will hear the responses from all other
responders.

>  A host that receives a query response containing a UNIQUE resource record that it

A conflict won't matter until someone queries a name. Once that happens,
conflict detection occurs pretty much immediately, since all responders
hear the responses from all other responders.

> for their own name at some convenient interval (every 30 seconds?)

That would be wasteful.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 13 May 2003 00:54:28 +0300

> multicast group. All responders will hear the responses from all other

Oops, looks like I jumped ahead of things, responses are currently sent
using unicast. But as Joshua also suggested, we could just use
multicast.

	MikaL

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 12 May 2003 15:07:50 -0700 (PDT)

> multicast group. All responders will hear the responses from all other

It is *requests* that are sent to a single multicast group, not
responses -- which are sent unicast. So all responders will *not* hear the
responses.

> hear the responses from all other responders.

That isn't the way the protocol works.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 12 May 2003 15:16:30 -0700 (PDT)

> > for their own name at some convenient interval (every 30 seconds?)

Wouldn't it also be wasteful to send all responses to the same
multicast group?