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

Jared Mauch <jared@puck.nether.net> Sat, 25 January 2020 12:51 UTC

Return-Path: <jared@puck.nether.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 4A8B7120804 for <ipv6@ietfa.amsl.com>; Sat, 25 Jan 2020 04:51:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 x6vBoVbJC-_A for <ipv6@ietfa.amsl.com>; Sat, 25 Jan 2020 04:51:27 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B8C12006F for <ipv6@ietf.org>; Sat, 25 Jan 2020 04:51:27 -0800 (PST)
Received: from [10.0.0.129] (c-68-32-79-179.hsd1.mi.comcast.net [68.32.79.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id A566F54114C; Sat, 25 Jan 2020 07:51:25 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Subject: Re: Address privacy (was: Re: RFC4941bis: consequences of many addresses for the network)
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CBB23ABE-A7A3-4208-873C-E47EE063E34B@fugue.com>
Date: Sat, 25 Jan 2020 07:51:25 -0500
Cc: Christian Huitema <huitema@huitema.net>, Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <844AEA04-4196-46C1-9546-9A8EF70F4891@puck.nether.net>
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>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Phs762wxkc1sxZqv5HAVix7t_bg>
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 12:51:29 -0000


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

Operators need the network to function and will disable things until it does.

- Jared