Re: Disabling temporary addresses by default?
Gyan Mishra <hayabusagsm@gmail.com> Sat, 01 February 2020 21:24 UTC
Return-Path: <hayabusagsm@gmail.com>
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 2DCB31200FE for <ipv6@ietfa.amsl.com>; Sat, 1 Feb 2020 13:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2lhAO2no4-dg for <ipv6@ietfa.amsl.com>; Sat, 1 Feb 2020 13:24:21 -0800 (PST)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 8B47212008F for <ipv6@ietf.org>; Sat, 1 Feb 2020 13:24:21 -0800 (PST)
Received: by mail-io1-xd36.google.com with SMTP id z193so12374046iof.1 for <ipv6@ietf.org>; Sat, 01 Feb 2020 13:24:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I4U1KRTx19zKlaQLnDj3WCu2jwYtWH71EhJER55ptkM=; b=T29sfVseJXfaQqOEeKiwkv2GY5rgrC5+gwicE9dwFZWOTTYjly033p81fzojXdctLP FrYeD/kl5sTsZFxXl+S3dYHJ/j/dWBd6xANooyHbEXEWHgbFDceeWnZNKMLAt4mY3Tjh Syjue2d3hIcyyYQ9EaAidsYoZOt63oW189QcZKO3sUWIt2L/VfcaSPx2atod+TnjwYG2 Rx1iFKYlsI0SXUqJy2xv+TBMZh4/v6G+Z6ngBjODqAuHDWxbK0v/00Ucjbn+2CRgG0e4 yp4gbvltGIsZhh18MesjHl1Yvt7phsX8Zd0ODkgzWKPoQg4WnQoG5dqCfp2izJIfyvxR x6sQ==
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; bh=I4U1KRTx19zKlaQLnDj3WCu2jwYtWH71EhJER55ptkM=; b=IyQSV5cuV38ZwzV7PvJuQOwe3k49nPzZseW//Ijif6eoW3EEiWQlv6GBuCnJquh90j pmjGj2ibp4aG47Ae4EpVY6ynxObSLuaO8rrGV0SGzXyGgNISNfUceQSI/JEPD0r0mchm xiXfU+mCnLlLUd1nDVrxXlziwWGCjQ3+Lo3y2NTpfEVFiCNTvqbvVwWGRBYvXVser1XI JBI3VzrcKokDF+VvOfcov2cV0bDGHBF6xsy3gr2pQL1tL6vCfjDD1eLFgxrCSrM86P9C dqoexXYP+ZRcX0bJ1JlP1DBt8z1iDYPtOXsV1mm9TziOR63+Q62RN416lPJKuOdA0CpG DKpQ==
X-Gm-Message-State: APjAAAXukj3cxCdzCj5JcWPcCYJBaHsB39m5nXfY1Uwr7MX3HRIIqohd KmKiAF4YANmhdq1vgvXRthBJuhDy8fRNRu6MGKI=
X-Google-Smtp-Source: APXvYqwn8l7UHeFJ3mh59p2bGJA1VIvL3fpDiedXoj/zTTzLvbKtx0ZLQEEntHFZBdcLMizW0T5x/M6ktySVToa4YGc=
X-Received: by 2002:a6b:4e13:: with SMTP id c19mr12907371iob.58.1580592260810; Sat, 01 Feb 2020 13:24:20 -0800 (PST)
MIME-Version: 1.0
References: <CAKD1Yr11_SSUkCBuQ3-h+eRg0LPZQdhe+h7f0YZy9TiyRWj6mw@mail.gmail.com> <751D59E0-F60B-4FE1-840F-3FEAB82F618F@huitema.net> <c058863d-9e29-3ddb-a020-0ebadef26ad4@si6networks.com> <CABNhwV0KsKN7LQY2D-BJkCtvB40oZCT65EmOCr0oE56c9g7-aQ@mail.gmail.com> <CAKD1Yr05GqFr1r018qHZev8SB6Gd=zm_45TtuShQH_5PVkXpKw@mail.gmail.com>
In-Reply-To: <CAKD1Yr05GqFr1r018qHZev8SB6Gd=zm_45TtuShQH_5PVkXpKw@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 01 Feb 2020 16:24:09 -0500
Message-ID: <CABNhwV2=TPU+CQ1zBu58DmRD7i3=tBsdZvuOxuaS_jQLZ-ebBw@mail.gmail.com>
Subject: Re: Disabling temporary addresses by default?
To: Lorenzo Colitti <lorenzo@google.com>
Cc: 6man WG <ipv6@ietf.org>, Christian Huitema <huitema@huitema.net>, Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary="0000000000003d8fde059d8a502b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TTcBWlQNOUQ-nISAds6mn4cPUaQ>
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, 01 Feb 2020 21:24:24 -0000
On Wed, Jan 29, 2020 at 6:13 AM Lorenzo Colitti <lorenzo@google.com> wrote: > On Wed, Jan 29, 2020 at 2:46 AM Gyan Mishra <hayabusagsm@gmail.com> wrote: > >> The main reason this topic comes has up is due to possible impact of >> usage of the temporary address when it gets deprecated with long lived >> session. That’s the crux of why this topic is critical and has severe >> operational impact. When the address changes for long lived connections >> from the deprecated temporary address to the new preferred address, the >> session would terminate and have to re-establish, which is impacts the user. >> > > If there is a permanent address as well, then an application that is not > able to deal with session resets (like SSH) can use > the IPV6_PREFER_SRC_PUBLIC socket options to use the permanent address > instead. > See section 5. A lot more needs to be done as far as API development - https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-04#section-5 > >> This would allow us to maintain privacy extension temporary address >> enabled by default change to benefit privacy advocates and also eliminate >> impact for enterprise users where availability and stability is utmost >> importance. >> > > But don't enterprises care about not leaking the habits of their > employees? If I was on an enterprise security team, I would be pretty > concerned about the levels of leakage and cross-site tracking that are > enabled by never changing the IPv6 addresses of a host. This doesn't happen > in IPv4 because we use NAT, but it will definitely happen in IPv6. > From an enterprise IT perspective network access is all monitored at the application layer with content filtering blocking URI access. So the anonymity or privacy concerns for an individual at home connected to the internet at home is an IETF objective to maintain per RFC 7258 pervasive monitoring. That same objective does not exist for enterprise IT hosts. In most if not all cases, the endpoint host is owned by the company and has monitoring software loaded to maintain IT security, and ensue security patches levels are up to date on endpoints, as well as web content filtering and restricted access to install or remove software. For BAU IPv4 connections on a corporate intranet the IPv4 address is stable and not changing. With IPv4 Nat is only used for “hide Nat” to hide internal space and use of web proxy. For internal communications within a corporate intranet Nat is used when address overlap exists. Even with IPv6 6to6 Nat and is employed within the DMZ for “hide Nat” to eliminate attack vector from any external entity extranet or internet. As well as 6to6 web proxy for internet web access. From an IT operations perspective, as far as IPv6, limiting the number of addresses on the endpoint for MTTR ( mean time to recovery) for availability is the primary objective for an enterprise. Stable random IPv6 address works best to meet the objective of an enterprise. > -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com
- 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