Proposed Resolution to LLMNR Issue 90: Multiple Replies

[Bernard Aboba <aboba@internaut.com>]

The text of LLMNR Issue 90 is enclosed below.  LLMNR Issues are tracked on
the LLMNR Issues page:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

The proposed resolution is as follows:

In Section 2.2, delete:

"The sender MUST anticipate receiving multiple replies to the same
LLMNR query, in the event that several LLMNR enabled computers
receive the query and respond with valid answers. When multiple
valid answers are received, they may first be concatenated, and then
treated in the same manner that multiple RRs received from the same
DNS server would."

In Section 2.7, change:

" Because an LLMNR sender cannot know in advance if a query sent using
multicast will receive no response, one response, or more than one
response, the sender SHOULD wait for LLMNR_TIMEOUT in order to
collect all possible responses, rather than considering the multicast
query answered after the first response is received. A unicast query
sender considers the query answered after the first response is
received, so that it only waits for LLMNR_TIMEOUT if no response has
been received."

To:

"An LLMNR sender cannot know in advance if a query sent using
multicast will receive no response, one response, or more than one
response. However, an LLMNR sender can consider a multicast query
answered after the first response is received if that response has
the 'C' bit clear.

However, if the first response has the 'C' bit set, then the sender
SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses.
When multiple valid answers are received, they may first be concatenated,
and then treated in the same manner that multiple RRs received from the
same DNS server would. A unicast query sender considers the query answered
after the first response is received, so that it only waits for
LLMNR_TIMEOUT if no response has been received.

Since it is possible for a response with the 'C' bit clear to be followed
by a response with the 'C' bit set, an LLMNR sender SHOULD be prepared to
process additional responses for the purposes of conflict detection and
LLMNR_TIMEOUT estimation, even after it has considered a query answered."

---------------------------------------------------------------------------
Issue 90: Multiple Replies
Submitter: Stuart Cheshire
Submitter email address: cheshire@apple.com
Date first submitted: May 25, 2005
Reference:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html
Document: LLMNR-40
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

   The sender MUST anticipate receiving multiple replies to the same
   LLMNR query, in the event that several LLMNR enabled computers
   receive the query and respond with valid answers.  When multiple
   valid answers are received, they may first be concatenated, and then
   treated in the same manner that multiple RRs received from the same
   DNS server would.

This means that, even when a query is successfully answered in (say) just
10ms, the sender has to wait for the full LLMNR timeout before returning
results to the caller, in case there are other responses coming?

[BA] If a response is received with the 'C' bit clear, then the
responder has indicated that it believes that the name is unique.
In this case the sender can return an answer to the caller without
having to wait for additional responses. However, if the response
has the 'C' bit set, or if no response is received, then it should
wait for LLMNR_TIMEOUT.


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