Subject: Revised resolution to Issue 78: UNIQUEness Probing

From: Bernard Aboba <[email-masked]>
Date: Wed, 9 Mar 2005 05:43:20 -0800 (PST)

The LLMNR Issues list is available here:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

Here is a proposed resolution to Issue 78 (UNIQUEness Probing) that
addresses the issue of ongoing conflict detection and uniqueness probing
deadlocks.  Thomas suggested defining a 'T'entative bit along
the lines of what is used in Neighbor Discovery, in addition to
use of the 'C'onflict bit.  A version of the document incorporating
the changes is available for inspection here:
http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-39.txt

The proposed resolution is as follows:

In Section 2.1.1 add the following paragraphs:

"C   Conflict.  When set within a request, the 'C'onflict bit indicates
     that a sender has received multiple LLMNR responses to this query.
     In an LLMNR response, if one or more resource records in the answer
     section is UNIQUE, then the 'C' bit is clear, otherwise it is set.
     LLMNR senders do not retransmit queries with the 'C' bit set.
     Responders MUST NOT respond to LLMNR queries with the 'C' bit set,
     but may start the uniqueness verification process, as described in
     Section 4.2.

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 one or more of the resource record(s) in the
     answer section.  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 as described in Section 4.1."

Change Sections 4, 4.1 and 4.2 to the following:

"4. Conflict resolution

The uniqueness of a resource record MAY depend on the nature of the
name in the query and type of the query. For example, multiple hosts
may respond to a query for an A or AAAA type record for a cluster
name (assigned to multiple hosts in the cluster). By default, a
responder SHOULD be configured to behave as though all RRs are UNIQUE
on each interface on which LLMNR is enabled.

To detect duplicate use of a name, an administrator can use a name
resolution utility which employs LLMNR and lists both responses and
responders. This would allow an administrator to diagnose behavior
and potentially to intervene and reconfigure LLMNR responders who
should not be configured to respond to the same name.

4.1. Uniqueness Verification

Prior to including a UNIQUE resource record in a response with the
'T' bit clear, for each UNIQUE resource record in a given interface's
configuration, the host MUST verify that there is no other host
within the scope of LLMNR query propagation that can return a
resource record for the same name, type and class on that interface.

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

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, a responder MUST send an LLMNR query with the
'C' bit clear, over all protocols on which it responds to LLMNR
queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
uniqueness of a name by sending a query for the name with type='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 of 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, it MUST check if
the 'C' bit is clear in any of the responses. If so, the sender
SHOULD send another query for the same name, type and class, this
time with the 'C' bit set, with the potentially conflicting resource
records included in the additional section.

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.

If the query is for UNIQUE resource record(s), then the responder
MUST send its own query for the same name, type and class, with the
'C' bit clear. If a response is received, 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 conflicting 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.

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