Subject: LLMNR Issue 6: Multicast groups

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Mar 2003 09:42:56 -0800 (PST)

The overall question arising from this issue is whether the IPv6 multicast
group usage advocated in LLMNR-13 is viable or not. I don't have any
opinions either way. Comments solicited.

Issue 6: IPv6 Multicast Groups
Submitter: Mika Liljeberg
Submitter email address: [email-masked]
Date first submitted: March 8, 2003
Reference:
Document: LLMNR-13
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
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

Comment from Bill Sommerfeld <[email-masked]>:

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.
MikaL: 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.]

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

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

[BA] --

Based on its addresses and names, a host only
need listen on the multicast groups corresponding to these. So it
performs the hash on the name or variants of it
("foobar", "foobar.example.com"), and the
addresses ("4.137.57.204.in-addr.arpa") and listens only on those
groups.

This may be inconvenient in that there may be several variants
of the name, so that an implementation may end up listening on
most of the multicast groups anyway.
Also, the use of multiple multicast addresses means
that a legacy host cannot easily be configured to send an LLMNR
query, just be adding a multicast address to the resolver
configuration.

Overall, I'm not sure that the multicast group usage is really
defensible, but I'd like to hear other people's opinion. Note
that the "ease of configuration" issue may not be that crucial
since a host configured that way would not easily be able to
limit LLMNR queries as suggested in Section 3, nor would they
be able to handle queries over TCP as suggested in Section 2.3.

--
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: 17 Mar 2003 21:56:14 +0200

> addresses ("4.137.57.204.in-addr.arpa") and listens only on those

I'll just add that the addresses configured to an interface may change
while the LLMNR responder is running (esp. with IPv6). This means that,
either the responder has to begin by joining all multicast groups
required for all possible reverse queries, or it must constantly monitor
the configuration of every network interface while running, in order to
notice any changes in the configured addresses.

	MikaL

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Mar 2003 17:57:48 -0800 (PST)

> notice any changes in the configured addresses.

It seems like a lot of complexity for not much benefit, particularly since
the host will be joining multiple multicast groups anyway. It does make it
harder for someone to just type in a multicast group into /etc/resolv.conf
and send an LLMNR query. But since the port has been changed, that won't
work anyway.

So I'm inclined to move to use of a single multicast address for IPv6.