Re: [dnssd] Provisional agenda for IETF98

Ted Lemon <> Mon, 20 March 2017 12:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D607131442 for <>; Mon, 20 Mar 2017 05:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z-Po3iG506sZ for <>; Mon, 20 Mar 2017 05:18:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC8F9130A97 for <>; Mon, 20 Mar 2017 05:18:12 -0700 (PDT)
Received: by with SMTP id 1so107878224qkl.3 for <>; Mon, 20 Mar 2017 05:18:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Kl+QgIpspgTtlKFZnN2FBTL6Iz0AuFR3whbaPDTvY7g=; b=rc1QRqc3RBQj/12B+1oszHzHHkFoG079FOYHut4tv2EkMtcYuq2AZnoO4zPA7YfQEH 1wI3V5KMoomLeV91uWwjDuHcpu4n4eeMxxRlrF6Ry7taCBWtZqu+lyZvjCaClZvZkkyj KUZxF10k0Wd1UsZvWK2jLZzkvQjboa/Zc/41eaSgGKrOsJ4f2Zuo3iplG4nUVqP0yhl5 L+cV8bmfznk3VtkA7PmkyZiVR28MYr06GDscSxOUhtLLQrtEVtwzYf0k/sF2f74SAo1M Pu01zSAgu4HB6ZODJX/dHhgxnCHWQ2gwbqdoKL2VIvZnjj2alf/SOwgkzUybZnWbMjmJ /kHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Kl+QgIpspgTtlKFZnN2FBTL6Iz0AuFR3whbaPDTvY7g=; b=ObwFdgeW/XyDUgSg6wlzTywtae8HCkFk4AwU0iIVyqhySZF9F15cz1LBOlRIHP80Qn nE76YqIzmZjXt6yCZKfbdmjyl60DUQ54qDla//o1kHNSTyYPqasYYXbGXT1Nl63TS4am AmonCp8UPBANS6ezuijkcuE69MGM2RdhwKUbIrvhzFQOS2xh2NmsHQIimIdXEc0pkmTn fYtkudR8bmFWy8u8eWRiWQgcEzX9AgZUM9Z8ebXAG7aQ/3kGQjwTVCzNBFJwHGXfeLmR 3OfpiX5l2+kBo3J2+T6dnBGj/kvzBpfvLTAj6NYODTMqDm4a/b/ifQwZy859n3swVoBu tK+Q==
X-Gm-Message-State: AFeK/H39CYJVCWpl2iWlLhnZzYcq8fcB9uwBSeRfA0Kev4ZETkYsad1/Hg6tLrklSJKvSA==
X-Received: by with SMTP id s6mr26886416qkf.231.1490012291904; Mon, 20 Mar 2017 05:18:11 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id h16sm10711008qta.34.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 05:18:10 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ted Lemon <>
In-Reply-To: <>
Date: Mon, 20 Mar 2017 08:18:09 -0400
Cc: Stuart Cheshire <>, Tim Chown <>, "" <>, Ralph Droms <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Markus Stenberg <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Subject: Re: [dnssd] Provisional agenda for IETF98
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Mar 2017 12:18:17 -0000

It might be useful to collect some operational data on this.   My experience is that "duplicate" devices are always the same device appearing either sequentially or simultaneously on two different links.   Defending the name therefore has the effect of causing the device to constantly rename itself, so that it never has a stable name.   This really sucks from a usability perspective.   Having the service simply mark duplicate names, rather than defending them, seems more likely to work.   This is what we suggest in the simple homenet naming architecture draft.

> On Mar 20, 2017, at 4:07 AM, Markus Stenberg <> wrote:
> On 19 Mar 2017, at 22.26, Stuart Cheshire <> wrote:
>> 8. Zone Stitching — when clients can interrogate multiple links (e.g., via a Discovery Broker) it would be convenient if we did not have names duplicated on the different underlying links. I confess that I still don’t have a single blindingly-obvious answer to this, so I welcome discussion and suggestions. I suspect the solution might build on the Discovery Proxy. When two links are configured to not allow duplicated names, the two Discovery Proxies in question would establish a bidirectional TCP connection. When one Discovery Proxy sees a device ask (using Multicast DNS) “Is this name in use?” the Discovery Proxy would ask its peer (over the TCP connection) “Is this name already in use on your link?” and if the answer is “Yes”, then the Discovery Proxy tells the local device (using Multicast DNS) “Name already in use; pick another.”
> I have thought quite a bit about this over the years (less recently, as I am mostly working on non-IETF stuff).
> I am not very fond of discovery proxies talking with each other; you wind up with O(N^2) connections given N links. 
> Instead, I would probably do this as function of discovery broker; either
> a) it provides rewritten information to its clients (somewhat fishy, as if mdns info contains computer-42, and there is another computer-42, you would wind up with e.g. computer-42-2 for one of them)
> b) discovery broker <> discovery proxy action is actually bidirectional, and DB can tell DP to force client to rename.
> Either design is relatively simple given devices that do not move. 
> However, in presence of moving devices, I am somewhat uncertain on what is the correct way; as device moves, it gets new IP address, so how to correlate that is actually I can think of few obvious heuristics but given recent work in IPv6 address pseudorandomization per link, they seem error prone and therefore not advisable. Therefore I am currently leaning towards design
> c) DB just shows (DNS-SD) services, even if they are duplicate (omitting extra ones?), and they point to host names on various links that may not be unique. In other words, just omit conflict resolution across links.
> or even
> d) DB just shows (DNS-SD services) for each link; based on cursory reading of RFC 6763, nothing prevents PTR => site on
> I am not quite sure if d) is valid, but at any rate, I am really leery of options a and b currently due to how they interact (or actually do not interact _well_) with moving hosts.
> Cheers,
> -Markus
> _______________________________________________
> dnssd mailing list