Subject: [dnssd] When does MDNS/DNS-SD use IPv6?

From: "Christian Huitema" <[email-masked]>
Date: Tue, 17 Jan 2017 19:58:57 -0800

I am writing a small implementation of MDNS and DNS-SD to test the privacy
and pairing drafts, and I am puzzled by the IPv4 vs. IPv6 issues. The MDNS
spec mentions that queries can be sent to "multicast address 224.0.0.251 or
its IPv6 equivalent FF02::FB". That's nice, but it is wonderfully
underspecified. Or maybe I am just a bit slow these days, and I just need
help... Given a query for some record type in the ".local" namespace, should
the implementation:

1) Send queries to both 224.0.0.251 and FF02::FB and merge the results?
2) Send queries only to 224.0.0.251?
3) Send queries only to FF02::FB?
4) Send to 224.0.0.251 and then try FF02::FB if no response come after a
timeout?
5) Or vice versa?
6) Perform some guesswork as to whether the local network prefers IPv4 or
IPv6?
7) Do different things if the query is for an A record versus AAAA?

Also, is there a different recommendation for one-shot queries and
continuous queries? 

And did we decide on purpose to not document that in the RFC?

-- Christian Huitema

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 18 Jan 2017 08:40:15 -0800

continuous queries? 

The Apple open source mDNSResponder implementation sends both queries in parallel.

There are no timeouts in the mDNSResponder APIs. There are no operations that fail, only operations that haven’t succeeded yet. The reason the printer doesn’t show up might be that it’s turned off — which is a situation the user can remedy. The client keeps patiently sending queries (with exponential backoff) until the device gets turned on and responds, or the user decides to cancel.

> And did we decide on purpose to not document that in the RFC?

Just an oversight, I think. Or perhaps we were optimistically looking forwards to a future world of all IPv6-only devices where the question wouldn’t apply.

Stuart Cheshire

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 18 Jan 2017 17:13:55 -0800

>> ... Given a query for some record type in the ".local" namespace, should
>> the implementation:
>> 
>> ...

OK. But if we all nodes do that and if all nodes publish their records on both IPv4 and IPv6, there is going to be a fair amount of duplicate traffic. More on potential fixes later in this message.

> There are no timeouts in the mDNSResponder APIs. There are no operations that fail, 
> only operations that haven’t succeeded yet. The reason the printer doesn’t show up 
> might be that it’s turned off — which is a situation the user can remedy. The client 
> keeps patiently sending queries (with exponential backoff) until the device gets 
> turned on and responds, or the user decides to cancel.

OK.

> Just an oversight, I think. Or perhaps we were optimistically looking forwards to a 
> future world of all IPv6-only devices where the question wouldn’t apply.

That would be nice, but it will probably not happen for another few years. In between, I was wondering if there are better ways to do things than the strict "ships in the night" approach described in the "IPv6 Considerations" of RFC. 

One easy fix for example would be the known answer suppression, in which the list of known answers would be the union of the records received on IPv4 and IPv6. There may also be a recommendation on random delays, so the messages on IPv4 and IPv6 arrive at different times.

A more complex fix could be to add a flag somewhere in the query, maybe an EDNS extension, to indicate that this is a duplicate of a particular query sent on another protocol. Dual stack hosts would then be free to only provide one set of answers. Any interest for that?

-- Christian Huitema