Salut and Suspend/Resume issues (MDNS and LLMNR multicast)

[John Gilmore]

I dropped a note to Bernard Aboba at Microsoft (a friend of a friend),
coauthor of that RFC, who brought some clarity to the situation.  His
note is appended.  What precedes it is my interpretation, and my
question to him.  Unfortunately, it appears to me to be an ugly situation.

> RFC 4795 does not cover mdns.

It's a subset, which was the best they could push through the IETF:

  https://datatracker.ietf.org/idtracker/draft-ietf-dnsext-mdns/

Turns out this appears to be Apple and Microsoft building a protocol
that isn't an IETF standard -- it's just in every Mac and many Windows
machines.  IETF documented it as Informational, with IESG commenters
noting, "A solution to this problem is useful. IETF should manage to
provide a standards track approach to it. I do not believe that moving
this forward gets us closer to having that or helps the longer term
goals of having the IETF produce interoperable standards."  And "this
is a result of a sub-optimal process. However, I think that it is
better to publish the document in order to document the protocol. I
agree with Ted that some sort of note would be appropriate, perhaps
along the lines that 'the working group was not able to reach full
consensus'."  Bill Fenner said, "The development of this document is
something for the IETF to be ashamed of."

I was unable to find any protocol description for the alleged power-
saving Sleep Proxy service that was in early drafts.  It appears in
multicastdns-04 and in the current multicastdns draft.  It has
disappeared from the LLMNR drafts and RFC 4795.  But a web search did
turn up US patents 7,246,225 and 7,107,442 issued Sept 12, 2006 and
July 17, 2007, to MulticastDNS Internet-Draft author Stuart Cheshire,
assignee Apple.  Both entitled "Method and apparatus for implementing
a sleep proxy for services on a network".  Neither one mentions MDNS
or LLMNR (though Rendezvous is briefly mentioned).  Not only did Apple
patent the concept of answering for a sleeping device ("printer"),
they also bizarrely patent the concept of having instructions in a
computer memory device that could, if ever executed, answer for a
sleeping device!

I have a copy of draft-cheshire-dnsext-multicastdns-04.txt, dated 14th
February 2004 and submitted to an IETF working group (dnsext).  It
mentions the Sleep Proxy and refers readers to an unsubmitted separate
protocol description.  This obligated Mr. Cheshire to disclose his patents
and patent applications to the IETF Secretariat, according to Best
Current Practice 79 (RFC 3979) -- which he did not do:

  https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=4795
  https://datatracker.ietf.org/ipr/search/?option=wg_search&wg_search=dnsext
  https://datatracker.ietf.org/ipr/search/?option=patent_search&patent_search=Apple

No IETF IPR submissions by Mr. Cheshire have appeared at all, though
Apple did make other IETF IPR submissions about other Zeroconf
patents.

Looks like the IETF has been foxed again, hosting a protocol that
awakens every computer on the LAN for every DNS query, designed
by a guy and company who secretly patented the concept of doing it
without burning up your battery.  He failed to notify the IETF of the
pending or issued patents.  And did you notice that Apple and Microsoft
have cross-licensed their entire patent portfolio to each other, but
not to the rest of us?

  http://www.microsoft.com/presspass/press/1997/Aug97/MSMACpr.mspx

  "We are thrilled at the prospect of working more closely with
  Microsoft on applications and Internet software" said Jobs. "We are
  confident that this is the beginning of a much closer relationship
  between the two companies, which will greatly benefit our common
  customers."

	 John


From: John Gilmore [gnu at toad.com]
Sent: Thursday, February 21, 2008 4:16 AM
To: Bernard Aboba; gnu at toad.com
Subject: MDNS and power management

Hi Bernard,

Is it true that MDNS (RFC 4795) requires every host on an adhoc
network to listen to (and ignore) every DNS query that every other
host produces?

I would've expected that any serious protocol would have learned the
lesson that ARP taught IPv6 NDP: Hash the request into a multicast
address that will partition the set of listeners, so that only those
who actually have a high probability of responding will even see your
packet.  In the absence of this, every battery-powered device on the
local link would have to wake out of low power mode, look at every DNS
packet, and then go back to sleep.

Is MDNS in use in any products?  IETF lists it as Informational, not
standards-track.

Thanks...

        John


From: Bernard Aboba <bernard_aboba at hotmail.com>
To: <gnu at toad.com>, <dthaler at microsoft.com>
Subject: Re: MDNS and power management
Date: Thu, 21 Feb 2008 09:15:26 -0800

Some comments:

a. LLMNR (RFC 4795) is largely a subset of the MDNS protocol included in Bonjour. 
At this point both protocols are supported within Apple's MDNS responder, but they
behave slightly differently with respect to use of multicast.  In LLMNR only queries
are multicast; in MDNS both queries and responses can be multicast. 

b.  Hashing was included in early versions of the LLMNR specification.  However,
several concerns came up  (see http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue%206
for a summary of the discussion):

  1. Handling of PTR RR queries.  In IPv6, would the responder need to listen on multiple
multicast groups for PTR RR queries (e.g. one group for each address on an interface).
To address this, the WG discussed having multiple multicast groups for A/AAAA queries, 
and a single group for other queries (e.g. PTR RR queries). 

2. Multiple names.  LLMNR (like MDNS) can handle both "local" names as well
as FQDN queries.  This could imply listening on multiple multicast groups. 
For example, a host might use the names "example", "example.local" and
"example.example.com".  While it might only query for single label or
".local" names, it might be expected to answer for all of them. 

Given these concerns, the WG decided to stick with a single multicast group. 

c. Power management.  Early on, MDNS had the concept of a "sleep proxy"
which would respond on behalf of a sleeping host.  This concept has now
been extended to ARP, DHCP and other multicast/broadcast protocols.  So
while an awake host might need to listen to all queries (or in the case of
MDNS, all responses), this would not necessarily prevent it from sleeping.

d. Usage.  LLMNR shipped in Windows Vista, and both LLMNR/MDNS 
are supported in Apple MacOSX MDNS responder.  MDNS is supported 
in the Avahi daemon that ships with Linux; LLMNR support will be coming soon
if it isn't already there.  Since MDNS is installed along with iTunes, 
it is now common to see MDNS traffic sent by Windows XP
and later versions of Windows.