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
- RFC4941bis: consequences of many addresses for th… otroan
- RE: RFC4941bis: consequences of many addresses fo… Pascal Thubert (pthubert)
- Re: RFC4941bis: consequences of many addresses fo… Naveen Kottapalli
- Re: RFC4941bis: consequences of many addresses fo… otroan
- Re: RFC4941bis: consequences of many addresses fo… Tim Chown
- Re: RFC4941bis: consequences of many addresses fo… Jared Mauch
- Re: RFC4941bis: consequences of many addresses fo… JORDI PALET MARTINEZ
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: RFC4941bis: consequences of many addresses fo… Alexandre Petrescu
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: RFC4941bis: consequences of many addresses fo… otroan
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: RFC4941bis: consequences of many addresses fo… JORDI PALET MARTINEZ
- Re: RFC4941bis: consequences of many addresses fo… Alexandre Petrescu
- Re: RFC4941bis: consequences of many addresses fo… Alexandre Petrescu
- Re: RFC4941bis: consequences of many addresses fo… Bob Hinden
- Re: RFC4941bis: consequences of many addresses fo… Pascal Thubert (pthubert)
- Re: RFC4941bis: consequences of many addresses fo… Warren Kumari
- Re: RFC4941bis: consequences of many addresses fo… Mark Smith
- Re: RFC4941bis: consequences of many addresses fo… David Farmer
- Re: RFC4941bis: consequences of many addresses fo… Michael Richardson
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: RFC4941bis: consequences of many addresses fo… Gyan Mishra
- Re: RFC4941bis: consequences of many addresses fo… Philip Homburg
- Re: RFC4941bis: consequences of many addresses fo… otroan
- Re: RFC4941bis: consequences of many addresses fo… Tim Chown
- Re: RFC4941bis: consequences of many addresses fo… Mark Smith
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: RFC4941bis: consequences of many addresses fo… Philip Homburg
- Re: RFC4941bis: consequences of many addresses fo… Gyan Mishra
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: RFC4941bis: consequences of many addresses fo… Michael Richardson
- Re: RFC4941bis: consequences of many addresses fo… Michael Richardson
- Re: RFC4941bis: consequences of many addresses fo… Michael Richardson
- Re: RFC4941bis: consequences of many addresses fo… Michael Richardson
- IPv6 address usage (was: Re: RFC4941bis: conseque… Fernando Gont
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: IPv6 address usage (was: Re: RFC4941bis: cons… Michael Richardson
- Re: RFC4941bis: consequences of many addresses fo… Pascal Thubert (pthubert)
- Re: RFC4941bis: consequences of many addresses fo… Gyan Mishra
- Re: RFC4941bis: consequences of many addresses fo… Brian E Carpenter
- Re: RFC4941bis: consequences of many addresses fo… Mark Smith
- Re: RFC4941bis: consequences of many addresses fo… Gyan Mishra
- Re: RFC4941bis: consequences of many addresses fo… Gyan Mishra
- Re: RFC4941bis: consequences of many addresses fo… Brian E Carpenter
- Re: RFC4941bis: consequences of many addresses fo… Gyan Mishra
- Address privacy (was: Re: RFC4941bis: consequence… Christian Huitema
- Re: Address privacy (was: Re: RFC4941bis: consequ… Ted Lemon
- Re: Address privacy (was: Re: RFC4941bis: consequ… Jared Mauch
- Re: Address privacy (was: Re: RFC4941bis: consequ… Michael Richardson
- Re: Address privacy (was: Re: RFC4941bis: consequ… Ted Lemon
- Re: Address privacy (was: Re: RFC4941bis: consequ… Tom Herbert
- Re: Address privacy (was: Re: RFC4941bis: consequ… Ca By
- Re: RFC4941bis: consequences of many addresses fo… Gyan Mishra
- Re: RFC4941bis: consequences of many addresses fo… Gyan Mishra
- Re: Address privacy (was: Re: RFC4941bis: consequ… Tom Herbert
- Re: Address privacy (was: Re: RFC4941bis: consequ… Warren Kumari
- Re: Address privacy (was: Re: RFC4941bis: consequ… Jared Mauch
- Re: Address privacy (was: Re: RFC4941bis: consequ… Gyan Mishra
- Re: Address privacy (was: Re: RFC4941bis: consequ… Gyan Mishra
- Re: Address privacy (was: Re: RFC4941bis: consequ… Christian Huitema
- Re: Address privacy (was: Re: RFC4941bis: consequ… Ole Troan
- Re: Address privacy (was: Re: RFC4941bis: consequ… Jared Mauch
- Re: Address privacy (was: Re: RFC4941bis: consequ… Gyan Mishra
- SLAAC vs DHCPv6 (Re: RFC4941bis: consequences of … Jared Mauch
- Re: Address privacy (was: Re: RFC4941bis: consequ… Gyan Mishra
- Re: SLAAC vs DHCPv6 (Re: RFC4941bis: consequences… Gyan Mishra
- Re: Address privacy (was: Re: RFC4941bis: consequ… Ted Lemon
- Re: Address privacy (was: Re: RFC4941bis: consequ… Jared Mauch
- Re: Address privacy (was: Re: RFC4941bis: consequ… Michael Richardson
- Re: Address privacy (was: Re: RFC4941bis: consequ… Tom Herbert
- Re: Address privacy Joel M. Halpern
- Re: Address privacy Tom Herbert
- Re: Address privacy Ole Troan
- Re: SLAAC vs DHCPv6 (Re: RFC4941bis: consequences… Simon Hobson
- Re: SLAAC vs DHCPv6 (Re: RFC4941bis: consequences… Brian E Carpenter
- Re: Address privacy Brian E Carpenter
- Re: Address privacy Tom Herbert
- Re: Address privacy Nick Hilliard
- RE: Address privacy (was: Re: RFC4941bis: consequ… Manfredi (US), Albert E
- Re: Address privacy Brian E Carpenter
- Re: Address privacy Jared Mauch
- Re: Address privacy Gyan Mishra
- Re: Address privacy Gyan Mishra
- RE: Address privacy Manfredi (US), Albert E
- RE: Address privacy Pascal Thubert (pthubert)
- Re: Address privacy Alexandre Petrescu
- Re: SLAAC vs DHCPv6 (Re: RFC4941bis: consequences… Alexandre Petrescu
- Re: SLAAC vs DHCPv6 (II) Nick Hilliard
- RE: SLAAC vs DHCPv6 (II) Pascal Thubert (pthubert)
- Re: SLAAC vs DHCPv6 (II) otroan
- Disabling temporary addresses by default? Lorenzo Colitti
- Re: Disabling temporary addresses by default? Ted Lemon
- Re: Disabling temporary addresses by default? Richard Patterson
- Re: Disabling temporary addresses by default? Lorenzo Colitti
- Re: Disabling temporary addresses by default? Ted Lemon
- Re: SLAAC vs DHCPv6 (II) Fernando Gont
- Re: Address privacy Fernando Gont
- Re: Address privacy Gyan Mishra
- Re: Disabling temporary addresses by default? Christian Huitema
- Re: Address privacy Fernando Gont
- Re: Disabling temporary addresses by default? Ted Lemon
- Re: Address privacy Nick Hilliard
- Re: Disabling temporary addresses by default? Nick Hilliard
- Re: Address privacy Gyan Mishra
- Re: SLAAC vs DHCPv6 (II) Fernando Gont
- Re: Address privacy Tom Herbert
- Re: SLAAC vs DHCPv6 (II) Michael Richardson
- Re: Disabling temporary addresses by default? Fernando Gont
- Re: SLAAC vs DHCPv6 (II) Fernando Gont
- Re: Address privacy Fernando Gont
- Re: Disabling temporary addresses by default? Fred Baker
- Re: Disabling temporary addresses by default? Gyan Mishra
- Re: Disabling temporary addresses by default? Gyan Mishra
- Re: Disabling temporary addresses by default? Mark Smith
- Re: Disabling temporary addresses by default? Ted Lemon
- Re: Disabling temporary addresses by default? Fernando Gont
- Re: Disabling temporary addresses by default? Ole Troan
- Re: Address privacy Tom Herbert
- Re: Address privacy otroan
- Re: Address privacy Ca By
- Re: Address privacy Mark Smith
- Re: Address privacy Tom Herbert
- Re: Disabling temporary addresses by default? Gyan Mishra
- Re: Disabling temporary addresses by default? Bob Hinden
- Re: Address privacy Fernando Gont
- Re: Address privacy Fernando Gont
- Re: Address privacy Fernando Gont
- Re: Disabling temporary addresses by default? Fernando Gont
- Re: Address privacy Tom Herbert
- Re: Address privacy Fernando Gont
- Re: Address privacy (was: Re: RFC4941bis: consequ… Fernando Gont
- Re: SLAAC vs DHCPv6 (Re: RFC4941bis: consequences… Brian E Carpenter
- Re: Address privacy Ted Lemon
- Re: Address privacy Fernando Gont
- Re: Address privacy (was: Re: RFC4941bis: consequ… Fernando Gont
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: Address privacy Fernando Gont
- Re: SLAAC vs DHCPv6 (Re: RFC4941bis: consequences… Fernando Gont
- Re: Address privacy Brian E Carpenter
- Re: Address privacy Fernando Gont
- Re: IPv6 address usage Fernando Gont
- Re: Address privacy Fernando Gont
- Re: Address privacy (was: Re: RFC4941bis: consequ… Fernando Gont
- Re: SLAAC vs DHCPv6 (II) (was:Re: RFC4941bis: con… Ted Lemon
- Re: Address privacy Ted Lemon
- Re: RFC4941bis: consequences of many addresses fo… Fernando Gont
- Re: Address privacy Pascal Thubert (pthubert)
- Re: SLAAC vs DHCPv6 (II) Lorenzo Colitti
- Re: Address privacy Fernando Gont
- Re: SLAAC vs DHCPv6 (II) Fernando Gont
- Re: SLAAC vs DHCPv6 (Re: RFC4941bis: consequences… Fernando Gont
- Re: SLAAC vs DHCPv6 (II) Fernando Gont
- Re: Address privacy Brian E Carpenter
- Re: Address privacy Fernando Gont
- Re: Address privacy (was: Re: RFC4941bis: consequ… Fernando Gont
- SLAAC vs DHCPv6 (II) (was:Re: RFC4941bis: consequ… Fernando Gont
- Re: Address privacy Tom Herbert
- Re: Address privacy Tom Herbert
- Re: Address privacy Ted Lemon
- Re: Address privacy Fernando Gont
- Re: Address privacy Tom Herbert
- Re: Address privacy Sander Steffann
- Re: Address privacy Tom Herbert
- Re: Address privacy Ted Lemon
- Re: Address privacy Tom Herbert
- Re: Address privacy Mark Smith
- Re: Address privacy Tom Herbert
- Re: Address privacy Ted Lemon
- Re: Disabling temporary addresses by default? Christian Huitema
- Re: Disabling temporary addresses by default? Carsten Bormann
- Re: Disabling temporary addresses by default? otroan
- Re: Disabling temporary addresses by default? Tim Chown
- Re: Disabling temporary addresses by default? Lorenzo Colitti
- Re: Disabling temporary addresses by default? Lorenzo Colitti
- Re: Disabling temporary addresses by default? Nick Hilliard
- Re: Disabling temporary addresses by default? otroan
- Re: Disabling temporary addresses by default? Jared Mauch
- Re: Disabling temporary addresses by default? Nick Hilliard
- Re: Disabling temporary addresses by default? Lorenzo Colitti
- Re: Disabling temporary addresses by default? otroan
- Re: Disabling temporary addresses by default? otroan
- Re: Disabling temporary addresses by default? Lorenzo Colitti
- RE: Disabling temporary addresses by default? Pascal Thubert (pthubert)
- Re: Disabling temporary addresses by default? Nick Hilliard
- Re: Address privacy Gyan Mishra
- Re: Disabling temporary addresses by default? Lorenzo Colitti
- Re: Disabling temporary addresses by default? Tom Herbert
- Re: Disabling temporary addresses by default? Christopher Morrow
- Re: Disabling temporary addresses by default? David Farmer
- Re: Disabling temporary addresses by default? Tom Herbert
- Re: Disabling temporary addresses by default? Michael Richardson
- Re: Disabling temporary addresses by default? Michael Richardson
- Re: Disabling temporary addresses by default? Gyan Mishra
- Re: Disabling temporary addresses by default? Erik Kline
- Re: Address privacy Michael Richardson
- Re: SLAAC vs DHCPv6 (II) Michael Richardson
- Re: Disabling temporary addresses by default? Michael Richardson
- Re: Address privacy Michael Richardson
- Re: Address privacy Ted Lemon
- Re: SLAAC vs DHCPv6 (II) Fernando Gont
- Better APIs (was: Re: Address privacy) Fernando Gont
- Re: Address privacy Michael Richardson
- Re: Address privacy Ted Lemon
- Re: Disabling temporary addresses by default? Michael Richardson
- Re: Disabling temporary addresses by default? Michael Richardson
- Re: Disabling temporary addresses by default? Michael Richardson
- Re: Address privacy Fernando Gont
- Re: Address privacy Fernando Gont
- Re: Disabling temporary addresses by default? Fernando Gont
- Re: Address privacy David Farmer
- Re: Disabling temporary addresses by default? Fernando Gont
- Re: Disabling temporary addresses by default? Fernando Gont
- Re: Address privacy Fernando Gont
- Re: Address privacy Fernando Gont
- Re: Disabling temporary addresses by default? Fernando Gont
- Re: Address privacy Michael Richardson
- Re: Better APIs (was: Re: Address privacy) Michael Richardson
- Re: Better APIs Brian E Carpenter
- Re: Better APIs (was: Re: Address privacy) Tommy Pauly
- Re: Disabling temporary addresses by default? Gyan Mishra
- Re: Better APIs (was: Re: Address privacy) Erik Kline
- Re: Disabling temporary addresses by default? Jared Mauch
- Re: Disabling temporary addresses by default? Mark Smith
- Re: Disabling temporary addresses by default? Gyan Mishra
- Re: Disabling temporary addresses by default? Jared Mauch
- Re: Disabling temporary addresses by default? Jared Mauch
- Re: Disabling temporary addresses by default? Gyan Mishra
- Re: Disabling temporary addresses by default? Jared Mauch
- Re: Disabling temporary addresses by default? Michael Richardson
- Re: Disabling temporary addresses by default? Lorenzo Colitti
- Re: Disabling temporary addresses by default? Lorenzo Colitti
- Re: Disabling temporary addresses by default? Erik Kline
- Re: Better APIs (was: Re: Address privacy) Fernando Gont