Subject: Proposed Resolution to Issue 78: Uniqueness Probing

From: Bernard Aboba <[email-masked]>
Date: Sun, 13 Mar 2005 06:39:36 -0800 (PST)

The text of Issue 78 is enclosed below.

The proposed resolution is as follows:

Change the beginning of Section 2.1.1 to:

"2.1.1. LLMNR header format

LLMNR queries and responses utilize the DNS header format defined in
[RFC1035] with exceptions noted below:

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     ID                        |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|  Opcode   | Z|TC| T| C| Z| Z| Z|  RCODE    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+"

Add the following paragraph:

"T   Tentative.  The 'T'entative bit is set in a response if the
     responder is authoritative for the name, but has not yet verified
     the uniqueness of the name.  A sender receiving a response with the
     'T' bit set MUST silently discard the response unless it is
     received in response to a uniqueness query.  A responder MUST
     ignore the 'T' bit in a query, if set.  When a response with the
     'T' bit set is received in response to a uniqueness query, a
     conflict has been detected and a responder MUST resolve the
     conflict.  Use of the 'T' bit is described in more detail in
     Sections 4.1 and 4.2."

------------------------------------------------------------------
Issue 78: UNIQUEness Probing
Submitter: Thomas Narten
Submitter email address: [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>