Subject: Proposed Resolution of LLMNR Issue 44: Reuse of Rendezvous IPV4 Multicast Address

From: Bernard Aboba <[email-masked]>
Date: Sat, 13 Sep 2003 04:09:08 -0700 (PDT)

The text of LLMNR Issue 44 is enclosed below.  The proposed resolution is
as follows:

Change "224.0.0.251" throughout the document to TBD.
---------------------------------------------------------
Issue 44: Reuse of Rendezvous IPv4 multicast address
 Submitter name: Stuart Cheshire
 Submitter email address: [email-masked]
 Date first submitted: August 24, 2003
 Reference:
 Document: LLMNR-22
 Comment type: T
 Priority: S
 Section: Various
 Rationale/Explanation of issue:

This is a busy time at Apple, working towards our next OS release,
 but I managed to make time to read draft-ietf-dnsext-mdns-22.txt.

 >The IPv4 link-scope multicast address a given responder listens
 >to, and to which a sender sends queries, is 224.0.0.251.

 If your intention is to make LLMNR interoperable with Rendezvous, I fully
 support that, and would be willing to do the necessary work. For example,
 Rendezvous does not currently support TCP queries, but we would be
 willing to add that support, and things like it, if the WG wanted to
 pursue that direction.

 Otherwise, if the intention is not to make LLMNR interoperable with
 Rendezvous, then it should not use the same multicast address. Using the
 same multicast address, and then using a different UDP port number so as
 to demultiplex the traffic in the kernel, would be the height of folly.
 The whole point of multicast (as opposed to good old-fashioned broadcast)
 is that it lets the Ethernet hardware (and/or the Ethernet switch) reduce
 the interrupt burden on the host CPU (and/or reduce the traffic on that
 link). Using the UDP port number as the filtering mechanism means that
 you pay all the cost of delivering a packet to a host that doesn't want
 it, only to have the packet discarded in the kernel because no one is
 listening on that port. The whole point of multicast is to prevent that
 waste.

[BA] Before we can decide on this, it's important to understand what
 changes would be required to achieve interoperability, and whether
 that interoperability would extend beyond the wire (e.g. to the
 content of the RRs) so that it would be meaningful -- rather than just
 a mechanism for Rendezvous to claim compliance with the LLMNR
 Proposed Standard without yielding the ability to interoperate
 with other LLMNR implementations in meaningful scenarios.

Assuming that LLMNR and Rendezvous can't interoperate, it seems fair to
 request assignment of a distinct IPv4 link-scope multicast address.

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