Subject: Re: Proposed Resolution to Issue 78: UNIQUEness Probing

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 Mar 2005 18:58:28 -0800 (PST)

Here is a proposed resolution incorporating the changes suggested by
Markku Savela.  A new version incorporating these changes is available
here:
http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-39.txt

In Section 2.1.1 change the initial text to the following:

"                                  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  | C|TC| Z| Z| Z| Z| Z|   RCODE   |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    QDCOUNT                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    ANCOUNT                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    NSCOUNT                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    ARCOUNT                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:

ID   A 16 bit identifier assigned by the program that generates any kind
     of query.  This identifier is copied from the query to the response
     and can be used by the sender to match responses to outstanding
     queries. The ID field in a query SHOULD be set to a pseudo-random
     value.  For advice on generation of pseudo-random values, please
     consult [RFC1750].

QR   Query/Response.  A one bit field, which if set indicates that the
     message is an LLMNR response; if clear then the message is an LLMNR
     query.

OPCODE
     A four bit field that specifies the kind of query in this message.
     This value is set by the originator of a query and copied into the
     response.  This specification defines the behavior of standard
     queries and responses (opcode value of zero).  Future
     specifications may define the use of other opcodes with LLMNR.
     LLMNR senders and responders MUST support standard queries (opcode
     value of zero).  LLMNR queries with unsupported OPCODE values MUST
     be silently discarded by responders.

C    Conflict.  When set within a request, indicates that a sender has
     received multiple LLMNR responses to this query.  When set within
     an LLMNR response, it indicates that a responder considers none the
     resource record(s) in the answer section to be  UNIQUE; if one or
     more of the resource records in the response is UNIQUE, then the
     'C' bit is clear.  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."

Change Section 4, 4.1 and 4.2 to the following:

"4.  Conflict resolution

   The uniqueness of a resource record depends on the nature of the name
   in the query and type of the query.  For example it is expected that:

      - multiple hosts may respond to a query for an SRV type record
      - 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)
      - only a single host may respond to a query for an A or AAAA
        type record for a name.

   By default, a responder SHOULD be configured to behave as though all
   RRs are UNIQUE on each interface on which LLMNR is enabled (by
   default, the 'C' bit is clear in responses).

   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, 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.

   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 for each UNIQUE resource record, using all protocols
   that it supports for use with LLMNR (IPv4 and/or IPv6).  If no
   response is received, the sender retransmits the query, as specified
   in Section 2.7.  If a response is received with the answer section
   containing a resource record that is considered UNIQUE, the responder
   MUST NOT use the UNIQUE resource record in response to LLMNR queries
   received over any protocol.

   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.  Triggering a reconfiguration in
   this case would not serve any useful purpose.  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.  When multiple responders
   attempt to verify uniqueness simultaneously (such as during recovery
   from a power failure) they may erroneously conclude that no conflict
   exists since a responder cannot respond to a query for a resource
   record without first having verified its uniqueness.

   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 and one or more of the
   resource records included in the Answer section are UNIQUE, 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 UNIQUE resource record(s) in
   response to LLMNR queries received over IPv4 or IPv6, 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 UNIQUE resource record, 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/>