Subject: LLMNR Issue 44: Reuse of Rendezvous IPv4 Multicast Address

From: Bernard Aboba <[email-masked]>
Date: Thu, 11 Sep 2003 13:21:44 -0700 (PDT)

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.

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