Subject: Proposed Resolution to LLMNR Issue 81: Conflicts from Healing of a Partition

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

The text of LLMNR Issue 81 is enclosed below.

The proposed resolution is as follows:

In Section 2.1.1 add the following paragraph:

"C    Conflict.  When set within a request, the 'C'onflict bit indicates
     that a sender has received multiple LLMNR responses to this query
     with the 'T' bit clear.  In an LLMNR response, the 'C' bit is clear
     if the responder considers the name in the query to be UNIQUE;
     otherwise the 'C' bit is set.  LLMNR senders do not retransmit
     queries with the 'C' bit set.  When receiving an LLMNR query with
     the 'C' bit set, an LLMNR responder MUST NOT respond, but will
     attempt to verify the conflict, as described in Section 4.2."

Change Section 4.1 and 4.2 to the following:

"4.1. Uniqueness Verification

Before responding with the 'T' bit clear to a query for a UNIQUE
name, a responder MUST verify that there is no other host within the
scope of LLMNR query propagation using the same name on that
interface.

 Prior to verifying uniqueness of a name, a responder MUST set the 'T'
bit in responses to queries for that name. Once a responder has
verified the uniqueness of a name, if it receives an LLMNR query for
that name with the 'C' bit clear, it MUST respond, with the 'T' and
'C' bits clear.

Uniqueness verification is carried out when the host:

- starts up or is rebooted
- wakes from sleep (if the network interface was inactive
during sleep)
- is configured to respond to LLMNR queries on an interface
enabled for transmission and reception of IP traffic
- is configured to respond to LLMNR queries using additional
UNIQUE resource records
- verifies the acquisition of a new IP address and configuration
on an interface

To verify uniqueness of a name, a responder MUST send an LLMNR query
for the name with the 'C' bit clear over all protocols on which it
responds to LLMNR queries (IPv4 and/or IPv6). Any query type will
do, including 'ANY'.

If no response is received, the sender retransmits the query, as
specified in Section 2.7. If a response is received with the 'T' bit
clear, the responder MUST NOT use the name in response to LLMNR
queries received over any protocol (IPv4 or IPv6). If a response is
received with the 'T' bit set, the responder MUST check if the source
IP address in the response, interpreted as an unsigned integer, is
less than the source IP address in the query. If so, the responder
MUST NOT use the name in response to LLMNR queries received over any
protocol (IPv4 or IPv6). For the purpose of uniqueness verification,
the contents of the answer section in a response is irrelevant.

Periodically carrying out uniqueness verification in an attempt to
detect name conflicts is not necessary, wastes network bandwidth, and
may actually be detrimental. For example, if network links are
joined only briefly, and are separated again before any new
communication is initiated, temporary conflicts are benign and no
forced reconfiguration is required. LLMNR responders SHOULD NOT
periodically attempt uniqueness verification.

4.2. Conflict Detection and Defense

Hosts on disjoint network links may configure the same name for use
with LLMNR. If these separate network links are later joined or
bridged together, then there may be multiple hosts which are now on
the same link, trying to use the same name.

In order to enable ongoing detection of name conflicts, when an LLMNR
sender receives multiple LLMNR responses to a query, the sender
behaves as follows:

[1] Responses with the 'T' bit set MUST be silently discarded.

[2] If multiple responses remain, the sender MUST check if the 'C' bit
is clear in any of the remaining responses. If so, a potential
conflict has been detected; the sender SHOULD send another query
for the same name, type and class, this time with the 'C' bit set.
The potentially conflicting resource records are included in the
additional section.

Responders receiving a query with the 'C' bit set behave as follows:

[3] Queries with the 'C' bit set are considered advisory and responders
MUST verify the existence of a conflict before acting on it. A
responder receiving a query with the 'C' bit set MUST NOT respond.

[4] A responder receiving a query for a non-UNIQUE name with the 'C'
bit set silently discards the query. A responder receiving a query
for a UNIQUE name with the 'C' bit set MUST send its own query for
the same name, type and class, with the 'C' bit clear. If a
response is received with the 'T' bit clear, then a conflict has
been detected.

An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
log them. Upon detecting a conflict, an LLMNR responder MUST
immediately stop using the name in response to LLMNR queries received
over any supported protocol, if the source IP address in the
response, interpreted as an unsigned integer, is less than the source
IP address in the uniqueness verification query.

After stopping the use of a name, the responder MAY elect to
configure a new name. However, since name reconfiguration may be
disruptive, this is not required, and a responder may have been
configured to respond to multiple names so that alternative names may
already be available."

Delete DEFEND_INTERVAL from Section 7.

----------------------------------------------------------------------------------
Issue 81: Conflicts from Healing of a Network Partition
Submitter: Thomas Narten
Submitter email address: [email-masked]
Date first submitted: October 8, 2004
Reference:
Document: LLMNR-38
Comment type: T
Priority: S
Section:  4
Rationale/Explanation of issue:

When a previously partitioned network heals, revealing one or more
name conflicts, LLMNR does not detect these conflicts
since uniqueness verification is not done periodically and responses are
sent via unicast, not multicast.

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