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

["Christian Huitema" <[e-mail]>]

On Wednesday, January 18, 2017 8:40 AM, Stuart Cheshire wrote:

> On 17 Jan 2017, at 19:58, Christian Huitema <[e-mail]> wrote:

>> ... 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?
>> ...
> 
>
> The Apple open source mDNSResponder implementation sends both queries in parallel.

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.

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

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