Subject: Minutes of the 4/16/03 LLMNR Conference Call

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Apr 2003 09:46:07 -0700 (PDT)

During the 4/16/03 conference call, discussion focused on Issues 6, 21 and
30.

On Issue 6 (IPv6 Multicast Groups) it was decided to go with a single IPv6
multicast group. It was noted that with multiple multicast groups, it was
necessary to correctly canonicalize names prior to computing the hash or
the wrong group would be chosen to send the query. This was thought likely
to cause interoperability problems.

In addition it was pointed out that since the proposal was to have only a
single IPv6 multicast group for all non-A/AAAA queries, that responder
would have to listen on this group. That meant that senders looking to
simplify their implementations could send all queries to that group. As a
result, in practice most traffic might go to a single group anyway.

As a result, it was resolved to change the text to use only a single IPv6
multicast group.

On Issue 21, it was argued that the text in Section 3 should be changed
from:

"[4] A sender SHOULD only send LLMNR queries for PTR RRs
    that represent addresses reachable through the link
    over which LLMNR is used."

To:

"[4] A sender SHOULD only send LLMNR queries for PTR RRs
    that represent addresses reachable on the link
    over which LLMNR is used."

Since this appears to reflect the original discussion on the issues, it
was recommended that this proposed change be made.

On Issue 30 (Why is Dynamic Update Needed?), it was decided to replace the
use of dynamic update with use of a regular LLMNR query. The major
advantage of dynamic update was thought to be that responses to dynamic
update requests would be more likely to fit within a single UDP packet,
while responses to an LLMNR query might have the TC bit set. This was not
thought to be a sufficient advantage to be worth the extra complexity and
potential interoperability issues resulting from dynamic update. Also,
there was concern that implementations of dynamic update might attempt to
do inappropriate things, such as to use TSIG security or attempt to update
hosts on which conflicts were detected.

The proposed text changes to carry out these proposed resolutions are
available on the LLMNR issues web site at:

http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

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