[v6ops] privacy point re. unsolicited NA / router neighbor cache

David Lamparter <equinox@diac24.net> Mon, 22 July 2019 21:37 UTC

Return-Path: <equinox@diac24.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E541200B6 for <v6ops@ietfa.amsl.com>; Mon, 22 Jul 2019 14:37:33 -0700 (PDT)
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_HELO_NONE=0.001, 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 GWdbRKdtsAyA for <v6ops@ietfa.amsl.com>; Mon, 22 Jul 2019 14:37:31 -0700 (PDT)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 C575112001B for <v6ops@ietf.org>; Mon, 22 Jul 2019 14:37:30 -0700 (PDT)
Received: from equinox by eidolon.nox.tf with local (Exim 4.92) (envelope-from <equinox@diac24.net>) id 1hpfzr-0003L6-2U for v6ops@ietf.org; Mon, 22 Jul 2019 23:37:28 +0200
Date: Mon, 22 Jul 2019 23:37:27 +0200
From: David Lamparter <equinox@diac24.net>
To: IPv6 Operations <v6ops@ietf.org>
Message-ID: <20190722213727.GI34551@eidolon.nox.tf>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/0dmCqtdrCpA87D5kN2yvNUnkHRo>
Subject: [v6ops] privacy point re. unsolicited NA / router neighbor cache
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2019 21:37:33 -0000

Hi all,


to clarify and document the point I made on the mic a few minutes ago:

I'm generating a privacy address.  I do DAD for it, and I send it to,
say, ff02::1:ffc6:3a4b.  On shitty networks, this will be a broadcast,
so everyone knows the address I'm using and can associate the MAC.  But
on non-shitty networks, it doesn't go anywhere because no one is
interested in that particular group.

I really don't want to suggest advertising privacy addrs to ff02::1.
Yes, the privacy might already be broken due to nonexistent multicast
filtering, but it's not broken by design.  Broadcasting it to ff02::1
breaks it by design.

ff02::2 has the problem Lorenzo mentioned with battery lifetimes.  It
might be broken in practice, but would work in theory, if you had proper
multicast filtering everywhere.  That might not even be the device's
wifi chip firmware, it could also be in APs.  I feel some strong deja vu
here from 802.11 multicast discussions.

The third option is for the router to pick up all DAD groups.  It
certainly won't report /ALL/ DAD groups in MLD, so this would break if
you have MLD-snooping switches... unless you configure multicast routing
properly with "all multicast on router ports".

Is there another choice? How about ff02::16 (All MLDv2-capable routers)?


-David