Subject: LLMNR Issues List

From: Bernard Aboba <[email-masked]>
Date: Fri, 7 Mar 2003 16:42:08 -0800 (PST)

In order to better track LLMNR issues, and ready the LLMNR draft for
DNSEXT WG last call, we have created an LLMNR issues list:

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

The LLMNR editors would like to encourage participants in the DNSEXT WG
who have not yet read the LLMNR draft to do so ASAP, and email your issues
in the format described on the Issues list, to [email-masked],
with a CC: to [email-masked].

The latest LLMNR draft is available at:

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-13.txt

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

---

From: Mika Liljeberg <[email-masked]>
Date: 08 Mar 2003 13:24:55 +0200

Reading the draft I get the understanding that, in order to respond to
reverse queries for IPv6 addresses, the host has to configure the
following sixteen multicast addresses on each of its interfaces:

FF02:0:0:0:0:2:MD5("0") .. FF02:0:0:0:0:2:MD5("F")

In addition, a host may have multiple aliases (especially if it is
multihomed), so the number of multicast groups that need to be
configured per inteface could be close to twenty. This is clearly a
waste of multicast filters.

It is unlikely (correct me if I'm wrong) that a NIC will support this
many multicast filters in hardware, which means that the NIC will have
to be configured to receive all multicasts and the filtering must be
done in software. That pretty much defeats the purpose of having the
hash based solicited name multicast addresses in the first place.

It would seem much better to just have a single well-known IPv6
link-local multicast address for reverse lookups. The alternative would
seem to be to not support PTR queries at all for IPv6 addresses.

I leave it to the discretion of the editors to decide whether this
should be formulated as an issue.

	MikaL

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 08 Mar 2003 14:52:56 -0500

> many multicast filters in hardware.

I just took a look at drivers for a few commonly used fast ethernet
chipsets, and found the following limits:

	- 80 literal multicast addresses
	- 64-entry hash.
	- 128-entry hash.
	- 256-entry hash.
	- 512-entry hash.

The "N-entry hash" variety maintain a N-bit vector, and run the
recieved multicast address through a hash function with N possible
outputs; if the corresponding bit in the vector is set, the packet is
received, so you get more graceful degradation as the number of groups
increases at the cost of slightly more false positives received.

One 802.11 card I looked at has a lower limits (16 literal addresses).
Another 802.11 card seems to have no multicast filtering at all!
(though that may be an inadequate driver rather than a deficiency in
the hardware/firmware).

							- Bill

---

From: Mika Liljeberg <[email-masked]>
Date: 08 Mar 2003 23:37:27 +0200

> increases at the cost of slightly more false positives received.

That's a pretty neat approach. The longer bit vectors sound good enough,
although I still can't say that I like the idea of having to listen to
16 different multicast groups just for doing PTR queries. [It would be
possible to optimize this, of course, but that would force the LLMNR
responder to actively monitor all changes in interface configuration.]

> (though that may be an inadequate driver rather than a deficiency in

Needless to say, 802.11 and other wireless interfaces would be a major
use case for LLMNR.

	MikaL

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 10 Mar 2003 06:52:35 +0859 ()

Mika;

> seem to be to not support PTR queries at all for IPv6 addresses.

It is enough to have a few (link local or global) anycast addresses
for any DNS lookups.

							Masataka Ohta

---

From: Mika Liljeberg <[email-masked]>
Date: 11 Mar 2003 19:39:34 +0200

Section 5 states:

Every responder that responds to a LLMNR query and/or dynamic update
request AND includes a UNIQUE record in the response:

   1. MUST verify that there is no other host within the scope of the
      LLMNR query propagation that can return a resource record
      for the same name, type and class.
   2. MUST NOT include a UNIQUE resource record in the
      response without having verified its uniqueness.

How does a responder know whether a particular RR that it owns is UNIQUE
or not? Looks like this attribute has to be manually configured for
every RR on every authoritative responder. Is this interpretation
correct?

I suppose an implementation can simply choose to not support cluster
names and just assert that every RR it owns is UNIQUE.

	MikaL