Subject: [LLMNR] Use of IPv6 link-local multicast addresses [Potential new issue]

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

On Sat, 2003-03-08 at 02:42, Bernard Aboba wrote:
> 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/>

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