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

"Christian Huitema" <huitema@huitema.net> Thu, 19 January 2017 01:14 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A03812946A for <dnssd@ietfa.amsl.com>; Wed, 18 Jan 2017 17:14:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.757
X-Spam-Level:
X-Spam-Status: No, score=-3.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8UIGLf2fWFd for <dnssd@ietfa.amsl.com>; Wed, 18 Jan 2017 17:14:09 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D57F129442 for <dnssd@ietf.org>; Wed, 18 Jan 2017 17:14:09 -0800 (PST)
Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1cU1Ik-0005cE-Ki for dnssd@ietf.org; Thu, 19 Jan 2017 02:14:07 +0100
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1cU1Ie-0007I4-O8 for dnssd@ietf.org; Wed, 18 Jan 2017 20:14:04 -0500
Received: (qmail 27620 invoked from network); 19 Jan 2017 01:13:58 -0000
Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <cheshire@apple.com>; 19 Jan 2017 01:13:58 -0000
From: "Christian Huitema" <huitema@huitema.net>
To: "'Stuart Cheshire'" <cheshire@apple.com>
References: <028501d2713f$32d5b3b0$98811b10$@huitema.net> <3E69567A-AE2C-47C0-84C4-554A623A2968@apple.com>
In-Reply-To: <3E69567A-AE2C-47C0-84C4-554A623A2968@apple.com>
Date: Wed, 18 Jan 2017 17:13:55 -0800
Message-ID: <04ce01d271f1$4f75c160$ee614420$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFqMHg/gd45SvujgbB2lnNS3KwtFAGHbTAQogNAkWA=
Content-Language: en-us
X-Originating-IP: 168.144.250.177
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.08)
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoQVNyV981Hd/9NT5ag7ZvxRcOb18WfxGyg6Om6u4YYm0t13n3chCaF1Fk/ 9PeN8gY5hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQxQRCdMNhge1Unb77YyuZq72jwfLcQRDEj+9cHzYRUqWRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/edseI+0iffshWIcU02XSgP6DwZpjxPTx I2S/vwoydU2Z0wfN9VTx9JdR4F4pphrEJ0EukYkH0+QwgTkvGReJqYh2OsKXXkoVR3vRgp+PhUTh 7upESYb585WZ0BSQoLJUJuEtgNryKqCFJ5h/4J1GJb9VSjPFKmMG+slTmUsw/+D7NlKfHadlY9VB h5JyIzzQ/I1dpLTifeoHWo0A7trCgivvMbIIty1BrdRX3euPU+v6hYCF0D67O+iDK8Lnv/b7w0RO kq5v3Md12tbcPxjzQdpjXhV8g5C9ZVdQH0yPWSY=
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/E6X1aC_FgruYZrNLv1LIhJaECJU>
Cc: dnssd@ietf.org
Subject: Re: [dnssd] When does MDNS/DNS-SD use IPv6?
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2017 01:14:11 -0000

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

> On 17 Jan 2017, at 19:58, Christian Huitema <huitema@huitema.net> 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