Re: RFC4941bis: consequences of many addresses for the network
Warren Kumari <warren@kumari.net> Thu, 23 January 2020 18:53 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 231C9120A47 for <ipv6@ietfa.amsl.com>; Thu, 23 Jan 2020 10:53:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 apcfTd0haIrI for <ipv6@ietfa.amsl.com>; Thu, 23 Jan 2020 10:53:22 -0800 (PST)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 DC0EE120A41 for <ipv6@ietf.org>; Thu, 23 Jan 2020 10:53:07 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id c24so3319347qtp.5 for <ipv6@ietf.org>; Thu, 23 Jan 2020 10:53:07 -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=Qsf7lNhGRmU2jk5oyYJ72z9g+cqNx1PilKd+MrrSF94=; b=Ug/NZgO79jqqx+gZOsY0wmS7nlqH3IOrwcy52d8oyvam7k52XwWk3wGqSAfrd1NoLa QKSv+x4K04NyZoSfnPj+edPplcLUpKMD/T9lR4DCxH93weMnsmQn1blm34NR72rmraZq fnbtBCoqC4aDcv4+3kDJQsEEPMBe3J6OX2AsbJuao1jgZq+Bc+qqWzEo/tVo6LKuZQLB uW66sk19XkPd3FNzqiaY+I9BwWf8OpdWNJxWaroNRTmD6d1CCWXYq5+EEjrk1jenIGkr HC1fI10GfMn8lfkpW8fMLzJvAvTvNKCyFPdjQdxWGYI0XoXxhJHOB6Z1o+jH2SND+dB9 g40w==
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=Qsf7lNhGRmU2jk5oyYJ72z9g+cqNx1PilKd+MrrSF94=; b=hpMMx6MCPtZYSK2v3P5OdifNfjpXgWeCvZBUkHI9gISAan2vFyP1mYQZ/5AZOa7a6/ 3uKG1d3/Jdu4MbIDEVg9Jxs7wU3ICJ2kLh59QXLW+PEFIuP2dRPt4ICYlZTGpNTKG6n7 xbIGV3yN0T6dwKEFcL7tkOy/SV8qZlua6q9NxigVrkYmrqBN27z6ztUnGI5aSxaM67Bi f4xrjdXWNgHNJLsKc5HSbJIXG2mz19u6KF9kVUlekcWRFIJulS88qKr1bC8hWXXBQMRA mXopBJNWutWwRwKga9X5zWn/7rPcYYMTp4MpZzElJ6yhKTj9Tcf2Du52Ii4c29n1ID7b PCAA==
X-Gm-Message-State: APjAAAUNT8ocb2MzkFcRpD+LwzrMECn7zZ0onHAq7QQQyObaTVsplb/R E27HAu74EM0Dj14M4U7KtxSFjM+sRuWC6mK+juWPLA==
X-Google-Smtp-Source: APXvYqzOTPo9jkzLD3/XZfuu33EETDHntSBiWk3+hk5sF+bYtvfoaNn2okZLFvsPdBiJF8zzZmYERMlq+oFgZRYbDkw=
X-Received: by 2002:ac8:387b:: with SMTP id r56mr18023899qtb.364.1579805586720; Thu, 23 Jan 2020 10:53:06 -0800 (PST)
MIME-Version: 1.0
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <2044DC74-3529-45BF-9886-56030B5EA515@gmail.com> <059D9CB7-9677-4CD2-BCDC-2393FA072BD7@cisco.com>
In-Reply-To: <059D9CB7-9677-4CD2-BCDC-2393FA072BD7@cisco.com>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 23 Jan 2020 13:52:30 -0500
Message-ID: <CAHw9_i+LFa=u6jdtFL-AkwLpDQLqnU9kci+0DO0rogDJMULahA@mail.gmail.com>
Subject: Re: RFC4941bis: consequences of many addresses for the network
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/MtxjkoRJ9hJqNycN53OyC7iDV4A>
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: Thu, 23 Jan 2020 18:53:24 -0000
On Thu, Jan 23, 2020 at 12:52 PM Pascal Thubert (pthubert) <pthubert@cisco.com> wrote: > > Hello Bob > > The issue is not confined within the node. This impacts the routers and the whole infra (think VXLANs). Indeed -- RFC6583 - "Operational Neighbor Discovery Problems", and, much more so, RFC8273 - "Unique IPv6 Prefix per Host" seem very relevant here... Yay, "We can solve any problem by introducing an extra level of indirection" ( or aegrescit medendo :-)) W > > > Regards, > > Pascal > > > Le 23 janv. 2020 à 18:35, Bob Hinden <bob.hinden@gmail.com> a écrit : > > > > Ole, > > > > Clearly a very number of addresses is a problem for router and other devices on the link. I note looking at my local machine (MacOS 10.14.6) I have five IPv6 addresses: > > > > Link-local > > ULA (temp and secured) > > Global (temp and secured) > > > > My router advertises a Global and ULA prefix. > > > > This seems to be current practice. Is this a problem? If I had 100 local devices on my link that would be 700 addresses, 1000 devices, then 7,000 addresses. Is that excessive? Also, depends on how the nodes manage this state, completely separate entries for each address, or all the addresses tied to the same link address. > > > > For RFC4941bis, I think text that raises the issue is a good thing, but the issue isn’t created by the bis draft, it a part of SLACC. We have multiple ways of creating IPv6 addresses, they all contribute to this. > > > > I think a new document that discusses the issue and makes some recommendations would be useful. > > > > Bob > > > > > > > > > > > > > >> On Jan 23, 2020, at 12:59 AM, otroan@employees.org wrote: > >> > >> While reviewing RFC4941bis (https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis) I think I found one gap. > >> > >> A discussion of the consequences of a host having many (active) addresses on the network. > >> > >> A 4941bis implementation following the defaults, would at the maximum use 8 active addresses. > >> (Valid lifetime of one week and one new address per day.) > >> > >> Shorter regeneration intervals or other approaches like a new address per connection could lead to dramatic numbers. > >> > >> If we use Ethernet as an example, each new address requires state in the network. In the ND cache in first-hop routers, and in SAVI binding tables in bridges. Given ND's security properties these tables must be policed by the network. A host with a very liberal address regeneration policy might be viewed as performing an attack. > >> > >> There is no signal available in SLAAC apart from DAD to reject an address. If the network runs out of resources (or prohibits the additional address by policy) the address will not be served. The host has to be deal with that situation. > >> > >> SLAAC is also missing a mechanism to release an address. Which leads me to think that the address regeneration interval must not be shorter than the ND cache scavenger timeout (which in many networks is high to avoid cache churn and high level of address re-resolutions). > >> > >> I would like to hear from other network-side implementors and operators. > >> Is there an issue here? > >> > >> Best regards, > >> Ole > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > 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