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

Stuart Cheshire <cheshire@apple.com> Wed, 18 January 2017 16:40 UTC

Return-Path: <cheshire@apple.com>
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 9278712947A for <dnssd@ietfa.amsl.com>; Wed, 18 Jan 2017 08:40:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.5
X-Spam-Level:
X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 FQ-ygY84bcNu for <dnssd@ietfa.amsl.com>; Wed, 18 Jan 2017 08:40:17 -0800 (PST)
Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 5B607129405 for <dnssd@ietf.org>; Wed, 18 Jan 2017 08:40:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1484757617; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=K4LKb4l5NDB5j07jSsNHFT9RVFqCAvz4Y2B4A99fwJI=; b=fhhtojIOo+5AALgqM1/nUroD6A7oMPchch0W9cP6fpED5qICaEwIJxuwR875Qg1e tYbqUjVWhR+pkcaYoZzwtj0PASrBJ+UNCpdJQ2p5kBEocYRqZyQHN2r5rg6u0AEU Dhapt4G8UeDEnHOb+0wW0OJIaipookCEJn+dfHyMcH6XP5nc0OZzian09iYEGlUy AGjDxTgWd6nFl7Ul3Hrxn1YDybQhwDLzoYnBm3YHJBkaegwX+OWvTAShp/Qa1tGD FSHFEw12haCG9EeUQjh2FVVaumkLoR5qpksQdlluk7SsEpxyMAMVwAvYCfYCob2Q aANg4LVsl0Ea5wEl01wxTQ==;
Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 32.BC.12229.17A9F785; Wed, 18 Jan 2017 08:40:17 -0800 (PST)
X-AuditID: 11973e12-811559a000002fc5-17-587f9a71f85d
Received: from jimbu (jimbu.apple.com [17.151.62.37]) by relay8.apple.com (Apple SCV relay) with SMTP id 27.AF.29380.07A9F785; Wed, 18 Jan 2017 08:40:17 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from [17.153.68.24] (unknown [17.153.68.24]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Sep 28 2016)) with ESMTPSA id <0OJZ00IQ9IB4TS60@jimbu.apple.com>; Wed, 18 Jan 2017 08:40:16 -0800 (PST)
Sender: cheshire@apple.com
From: Stuart Cheshire <cheshire@apple.com>
In-reply-to: <028501d2713f$32d5b3b0$98811b10$@huitema.net>
Date: Wed, 18 Jan 2017 08:40:15 -0800
Content-transfer-encoding: quoted-printable
Message-id: <3E69567A-AE2C-47C0-84C4-554A623A2968@apple.com>
References: <028501d2713f$32d5b3b0$98811b10$@huitema.net>
To: Christian Huitema <huitema@huitema.net>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUi2FCYpls4qz7CYMJ1bov3S2cxWkxunM3u wORxa8YpFo8lS34yBTBFcdmkpOZklqUW6dslcGW0vNjMVPCSr+LJ/vtMDYyvubsYOTkkBEwk vh64xdLFyMUhJLCPUeJU/25WmMSjPefYQWwhgWWMEktnxILYvAKCEj8m3wNq4OBgFlCXmDIl F6L3G6PE5pMdYPXCAlISr1Z+ZgapEQaac3gGP0iYTUBL4sXnK2wgNqeAlcT9m1/AylkEVCV2 XF0PZjMLCEksuLYFytaWePLuAivEWhuJ7w/nskCcYylxoWM6I4gtAlSzZvY9JoiTZSWenFwE 9ouEQAebxNmpW9gmMArPQnL2LISzZyFZsYCReRWjUG5iZo5uZp6JXmJBQU6qXnJ+7iZGUFhP txPawXhqldUhRgEORiUe3o6i+ggh1sSy4srcQ4zSHCxK4rwHG+sihATSE0tSs1NTC1KL4otK c1KLDzEycXBKNTDK3/WoZHF2fD5V37hUdN6taRqau6MfCp1KjXfjWWBw7bPZXpGpuv2Gp772 rXbltXlx6pDJ0tNmc3JcLCvUJidwrDkrqfCCN/roK81V54V69ffWedbHawkxGKwqX+z4zYXP tN5Qb1lT2ykfB2GXzL3fP1n/+sS+8hjXAt/AyW+0VZ7P2fmx/qUSS3FGoqEWc1FxIgDCa75+ TAIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUiON1OVbdwVn2EwcF1zBbvl85itJjcOJvd gcnj1oxTLB5LlvxkCmCK4rJJSc3JLEst0rdL4MpoebGZqeAlX8WT/feZGhhfc3cxcnJICJhI PNpzjh3CFpO4cG89G4gtJLCMUWLpjFgQm1dAUOLH5HssXYwcHMwC6hJTpuR2MXIBlXxjlNh8 sgOsV1hASuLVys/MIDXCQDMPz+AHCbMJaEm8+HwFbCSngJXE/ZtfwMpZBFQldlxdD2YzCwhJ LLi2BcrWlnjy7gIrxFobie8P57JAnGMpcaFjOiOILQJUs2b2PSaIk2UlnpxcxDKBUXAWkktn IVw6C8nUBYzMqxgFilJzEist9BILCnJS9ZLzczcxgsKzoTBtB2PTcqtDjAIcjEo8vB1F9RFC rIllxZW5hxglOJiVRHjZpgOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ817uB0oJpCeWpGanphak FsFkmTg4pRoY01dZJ25xeKoqesqxQf2i3JNn8gsvTwhjq3DX0TKx+lSW/a95y1ZpxpdnFt+P uf7b+erDp1e6ttWbHr56ZcfsT/98FrU973m/aG97xymB3Hpbo1VakkGijvfCb635+onXIkh3 5c19bueSv/5bpey/8tu3s0oW/49fvr/5WYdIyyWp7N4Sl0B/PiWW4oxEQy3mouJEAA6TRdxL AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/82xFxnf1N9VJyfyL452nyfmOA30>
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: Wed, 18 Jan 2017 16:40:18 -0000

On 17 Jan 2017, at 19:58, Christian Huitema <huitema@huitema.net> wrote:

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

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