Re: [dnssd] Unicast Service Discovery Autoconfiguration

Tom Pusateri <pusateri@bangj.com> Thu, 08 November 2018 21:10 UTC

Return-Path: <pusateri@bangj.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 DCFB212D7F8 for <dnssd@ietfa.amsl.com>; Thu, 8 Nov 2018 13:10:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 3jnwyhzrN8Pd for <dnssd@ietfa.amsl.com>; Thu, 8 Nov 2018 13:10:51 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F089312D4E8 for <dnssd@ietf.org>; Thu, 8 Nov 2018 13:10:50 -0800 (PST)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 9A53C2219C; Thu, 8 Nov 2018 16:10:49 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com>
Date: Thu, 08 Nov 2018 16:10:47 -0500
Cc: Stuart Cheshire <cheshire@apple.com>, dnssd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/8qL0cj47ECmfkTSBqZaPW0wOeM4>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
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, 08 Nov 2018 21:10:53 -0000

If multicast packets are dropped during IPv6 configuration, you won’t get an IPv6 address and you won’t be able to communicate via IPv6. This is easy to detect. When multicast packets are lost during busy periods on wifi and services are not reliably discovered, there’s no easy way to detect this.

On busy wifi networks, multicast just isn’t reliable.

See https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-03

Tom

> On Nov 8, 2018, at 10:35 AM, Joe Touch <touch@strayalpha.com> wrote:
> 
> Hi Stuart, et al.,
> 
> I’m confused by the text below; given IPv6 configuration relies on multicast, why is it not reasonable to assume similarly useful multicast here?
> 
> Joe
> 
>> On Nov 7, 2018, at 11:27 PM, Stuart Cheshire <cheshire@apple.com> wrote:
>> 
>> Here is a link to the new draft Ted Lemon and I wrote as a result of our work at the Hackathon here at IETF 103.
>> 
>> <https://tools.ietf.org/html/draft-sctl-dnssd-unicast-autoconfig-00>
>> 
>> Here’s a brief summary of what the document is about:
>> 
>>  Because multicast can be inefficient and unreliable, work is
>>  taking place to enable DNS-Based Service Discovery to operate
>>  with less reliance on multicast.  One current target use case
>>  for this work is Thread wireless mesh networking.
>> 
>>  Existing work describes how DNS-Based Service Discovery can
>>  be performed using unicast on such a network.  Devices on
>>  the Thread mesh offering services use Service Registration
>>  Protocol to register their services at a Service Registration
>>  Server.  Devices seeking to discover these services send
>>  unicast queries to the Service Registration Server using
>>  unicast DNS for single individual queries, and using DNS Push
>>  Notifications where ongoing change notification is required.
>> 
>>  For proof-of-concept experiments, the necessary information can
>>  be configured manually, and this has been done successfully.
>>  For deployment, we need to determine how the necessary information
>>  will be learned and configured automatically in real-world scenarios.
>> 
>> Stuart Cheshire
>> 
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd