Re: Address privacy (was: Re: RFC4941bis: consequences of many addresses for the network)

Warren Kumari <warren@kumari.net> Sat, 25 January 2020 23:36 UTC

Return-Path: <warren@kumari.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC126120077 for <ipv6@ietfa.amsl.com>; Sat, 25 Jan 2020 15:36:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 Y09kEyz7VWDw for <ipv6@ietfa.amsl.com>; Sat, 25 Jan 2020 15:36:09 -0800 (PST)
Received: from mail-qv1-xf44.google.com (mail-qv1-xf44.google.com [IPv6:2607:f8b0:4864:20::f44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A5E12001E for <ipv6@ietf.org>; Sat, 25 Jan 2020 15:36:09 -0800 (PST)
Received: by mail-qv1-xf44.google.com with SMTP id x1so2799418qvr.8 for <ipv6@ietf.org>; Sat, 25 Jan 2020 15:36:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XBu4rBsyHMa1KPeLoKPDJMnL0dWjEA/KnkCxLm2xe5c=; b=bUBnIy4iVDmzeDGSE7/YORzzHEZUlJgXCtRa80GOZJOXhkH5Hk3O/DHn/xlaVGxuNS 9U3b1ku2TQmhfXF056XiKjOZbaPHb7G02EvzdsGnaBL4204JR7qNNKgdQZUOesu8Opsa GpPgDOFOdBcvacsAWYX6cilEwdp0QKYt3dDl3x7JJyrGpYnltaSKjBfsDPi+DBnsSGl2 upCVQze87/FcKEdkrG8MSqclETrI6MdezYqsVQVZS2QLGzd+bI5Skk7RkMAyu0jv6eaH flrlCoYz5PbjvC7z4+XLc1cSOIIbJ6ILpH6/sm2UUDLZrkYqkgtDR6bAnQy1NkPo6QVA F6Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XBu4rBsyHMa1KPeLoKPDJMnL0dWjEA/KnkCxLm2xe5c=; b=njhcHczR897VWntdmR0ZazCC21aCB6FH+JYTyg30GgPTAAo/ilKGcICWuAa0+7DHz+ F3QMogQB+xNBh+nDLjcVNd3OEhqrKM+Locn86u/pLmiD4SjACpM/Y5aJOH7JYpDWiFko caP25LQRBOrbZkAkqt+z11C44Ny2VWZX19OF5mK0m32bpviEeE+tWDbSwRyIyuII5Oox C94q/LqPCIEQyPTxkfonLebraHHPsa6VtG5yIow7qfBoWNSJIGPwVhH7EDnL12ifrxZZ Y8P4xsdNVQfbSs/yf9lE6oUKT6pOu/1IHQ5tNEWJoMTCbJEm7x6pWyenIJBLVRZcBNaS rS6A==
X-Gm-Message-State: APjAAAUcofrF7OWYI2pDb3sNnxUghoX/l15ryHiAbDM3dtf5DhWEXGff Pg3sUwY6fnNHhKhGiDkLlyS8snr39fGbIIlQJxKgew==
X-Google-Smtp-Source: APXvYqyxkRLSPRXHFfC5r9UPc4bONKcaWIQ8y8nsVpk0E+CSGpD+NFMs+4WOTSxBV0MUrJ6A0oQAV8NEuafB+PtdNgQ=
X-Received: by 2002:a05:6214:10cb:: with SMTP id r11mr10037423qvs.59.1579995368532; Sat, 25 Jan 2020 15:36:08 -0800 (PST)
MIME-Version: 1.0
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <MN2PR11MB3565330989D411525D30B90DD80F0@MN2PR11MB3565.namprd11.prod.outlook.com> <80207E17-AE8E-4D19-B516-D2E6AB70721E@employees.org> <8D5610EA-49D3-483E-BB7A-67D67BC89346@jisc.ac.uk> <DE7B0688-230F-4A5C-8E24-9EAED9FD9FEB@puck.nether.net> <CAO42Z2zXwVnzemRqyqy78czpHjZm0nhkCJgVrx=-fmt+C6MnSA@mail.gmail.com> <1962.1579823388@localhost> <f83ab037-9125-bb74-dbac-68850aeb1020@huitema.net> <CBB23ABE-A7A3-4208-873C-E47EE063E34B@fugue.com> <844AEA04-4196-46C1-9546-9A8EF70F4891@puck.nether.net>
In-Reply-To: <844AEA04-4196-46C1-9546-9A8EF70F4891@puck.nether.net>
From: Warren Kumari <warren@kumari.net>
Date: Sat, 25 Jan 2020 18:35:32 -0500
Message-ID: <CAHw9_iLpmu9RYKpcJWZpDvHz-WqHccOtUF=u_s-aSVciP+2QZA@mail.gmail.com>
Subject: Re: Address privacy (was: Re: RFC4941bis: consequences of many addresses for the network)
To: Jared Mauch <jared@puck.nether.net>
Cc: Ted Lemon <mellon@fugue.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Christian Huitema <huitema@huitema.net>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gbJ6KHfdCupNGWb8KP8drmKca7E>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jan 2020 23:36:12 -0000

On Sat, Jan 25, 2020 at 7:51 AM Jared Mauch <jared@puck.nether.net> wrote:
>
>
>
> > On Jan 25, 2020, at 7:45 AM, Ted Lemon <mellon@fugue.com> wrote:
> >
> > I really like this way of thinking about the “anonymity set.”   I’ve been a bit obsessed with this problem for a while; I think that flat routing of a bazillion addresses is probably not an ideal solution, however, because in order to get real anonymity, you have to not reuse addresses, and so now you’re looking at a Carl Sagan worth of addresses (billions and billions) in the routing table.
>
> Not in the routing table.  You won’t have billions of routes in the RIB or FIB in the DFZ in my lifetime.
>
> Now what ND does to the local network is quite problematic but also has been discussed at length and we’ve seen that impact on wireless networks at IETF meetings.  The amount of broadcast/multicast background noise gets raised to much higher levels as a result and has practical operational considerations.
>
> One of the things the group may want to work on is finding the right thresholds and providing some operational guidance as a result.
>
> We did a similar experiment at a NANOG meeting with providing the venue network via the hotel and by having IPv6 on it caused the radio noise floor to raise significantly due to the broadcast(multicast) traffic it harmed the throughput of the network greatly.

... see the ietf-hotel network in Singapore as another example of
having to disable V6 because of the broadcast load.
https://datatracker.ietf.org/doc/draft-ietf-mboned-ieee802-mcast-problems/
talks about the interaction of broadcast/multicast on 802.11
networks...

W


>
> Operators need the network to function and will disable things until it does.
>
> - Jared
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf