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 [EMAIL PROTECTED] Sent: Thursday, February 21, 2008 4:16 AM To: Bernard Aboba; [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> 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. _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
