Subject: Proposed resolution of Issue 6: IPv6 Multicast Groups

From: Bernard Aboba <[email-masked]>
Date: Tue, 18 Mar 2003 15:18:21 -0800 (PST)

I would like to propose that Mika's proposed change be accepted. Here's
the issue and the proposed resolution:

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] I would like to propose that Mika's suggestion
be accepted:

A single well-known multicast group for IPv6 queries other than A/AAAA.

Change:

"LLMNR queries are sent to and received on port TBD using a LINKLOCAL
address as specified in "Administratively Scoped IP Multicast" [RFC2365]
for IPv4 and the "solicited name" LINKLOCAL multicast addresses for
IPv6, and using a unicast address as described in Section 2.3. The LLMNR
LINKLOCAL address to be used for IPv4 is 224.0.0.251. LINKLOCAL
addresses are used to prevent propagation of LLMNR traffic across
routers, potentially flooding the network."

To:

"LLMNR queries are sent to and received on port TBD using a LINKLOCAL
address as specified in "Administratively Scoped IP Multicast" [RFC2365]
for IPv4. The LLMNR LINKLOCAL address to be used for IPv4 is 224.0.0.251.
For IPv6, the "solicited name" LINKLOCAL multicast addresses are used
for A/AAAA queries, and a separate multicast address TBD for all other
queries. In addition, LLMNR queries can be sent to a unicast address
as described in Section 2.3. LINKLOCAL addresses are used to prevent
propagation of LLMNR traffic across routers, potentially flooding the
network."

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