LLMNR Issue 78: UNIQUEness probing

[Bernard Aboba <aboba@internaut.com>]

Issue 78: UNIQUEness Probing
Submitter: Thomas Narten
Submitter email address: narten@us.ibm.com
Date first submitted: October 8, 2004
Reference:
Document: LLMNR-36
Comment type: T
Priority: S
Section:  4
Rationale/Explanation of issue:

"To verify uniqueness, a responder MUST send an LLMNR query for
each UNIQUE resource record. If no response is received after a
suitable number of attempts (see Section 2.7), the responder can
use the UNIQUE resource record in response to LLMNR queries. If
a response is received, the responder MUST NOT use the UNIQUE
resource record in response to LLMNR queries."

It sounds like two nodes attempting to use the same name at
the same time will end up both deciding that the name is not in
use. Ooops.

Could we:

- use the source address of queries to distinguish between queries
sent out for a "tentative" name vs. a query from someone else?

- could we (if we see other simultaneous queries) say "danger,
conflict may be present", and do some sort of random wait before
trying again, so that two nodes doing the same thing will wait
different times, with one presumably then able to grab the name?

Will this all be too complicated and take too long? I dunno. But the
algorithm as specified now seems like it wil fail with high
probability (e.g, recovery after powerfail scenario).


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>