Re: Address privacy
Gyan Mishra <hayabusagsm@gmail.com> Wed, 29 January 2020 20:07 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 705FA12010F for <ipv6@ietfa.amsl.com>; Wed, 29 Jan 2020 12:07:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 whbPwOQR12rP for <ipv6@ietfa.amsl.com>; Wed, 29 Jan 2020 12:07:01 -0800 (PST)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 048B312006E for <ipv6@ietf.org>; Wed, 29 Jan 2020 12:07:00 -0800 (PST)
Received: by mail-io1-xd30.google.com with SMTP id m25so1181411ioo.8 for <ipv6@ietf.org>; Wed, 29 Jan 2020 12:07:00 -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=+AelpG+AnbbV8XynOeMxXwNwpcBgyjGQNqU3eljuqSU=; b=IgtMnowkdwJxx7mzfUfu99iqAg8CX/4FAuTkxxu8dSFRrFyodXdqAbVYn3NyQqXfJ/ cj8AdhevjypH24Fi4FByvlwQAK3brxrauOxxy639/xwXi0cKM94cxEQO5OtA/OvtoLC6 BvJ71oAyV0rKBVRYOm9vZncWgWxavGvIqV4LkuO1OibP0BSDfONk0idcD4teL79nKboi aWLbLI8Y1evGZHsFaPQAGeHmxEPr+HXYLfxjKruplvd1voGsa6IY2xeyuQP+raF1GcUh r6vyLppvRpx3mFuaHptkYpgvbQeEqsbOcoXPb0RNek/JsDdw78KmD4/dwjqKbmYYaY8R H1Lg==
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=+AelpG+AnbbV8XynOeMxXwNwpcBgyjGQNqU3eljuqSU=; b=o1iksX9f1Y2kiDSvuQtUTQqfDztnbkBXPIlg6dKchFXuLWfMcqxlzth6dVmA0Naa2P Bk/7+j/GQBtCK3x6dawGBgW/hQZaaqxDOCuQOFnmxwuvezG6MhIpAgV+VanbrtVBT+Rk qNliyQY+2WYBUgHTnD+xCO2x7mKHyTpdNporUpcj2uyJYubU5+Cy3rusKVM+h9+HH8ZR jFpYcJQxDC6zfSB29ahchM9tZWakurK4k7zuGjvT9PVxjReTrTMmVdtG/opeznrn1NA5 dL3X1QfdXgNFthZ7oL+5/L2fV1nXcrYZhr0AJn/GJgD3POj+btLEr6365o7eYKtDELA5 yR1w==
X-Gm-Message-State: APjAAAVdkyld2CRcvhP+fsT+7FgwzaoZUGC3MUFWsVbGhF3gZDRzhtk+ Y992OF6Me64goutHBPlrYx7ZYZeay390wwCTgg4=
X-Google-Smtp-Source: APXvYqyEuxV1fliL4wK4hXBNQ5uAgOqM0AIMCujwNOdbKkhiQWTdlSWoZ/0FptJLvRA1dqe8JWUGGC3JUuE4mkpRKyc=
X-Received: by 2002:a5e:9609:: with SMTP id a9mr1098941ioq.78.1580328419807; Wed, 29 Jan 2020 12:06:59 -0800 (PST)
MIME-Version: 1.0
References: <b606d8b0-b83d-1926-1cea-8165a1800c20@si6networks.com> <DB9D43C2-BE65-4DC0-AE25-E62E27569E90@gmail.com> <cfa3183b-76c3-a504-aba7-673d6d904f9b@si6networks.com> <CABNhwV1JnbcKvMdR2m0mHpgSQpU061VFYkft4FWp109X3Kw77w@mail.gmail.com> <a6745584-2bdf-59f1-9011-ac986219753e@si6networks.com>
In-Reply-To: <a6745584-2bdf-59f1-9011-ac986219753e@si6networks.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 29 Jan 2020 15:06:49 -0500
Message-ID: <CABNhwV1FAWP=+H-mF19PYdmN9BpB5BLXvwmOpnGHAJAekn8H+g@mail.gmail.com>
Subject: Re: Address privacy
To: Fernando Gont <fgont@si6networks.com>
Cc: 6man WG <ipv6@ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000175b0c059d4ce2b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gXotzMbkm8_yLcJd1ximR6k6nlU>
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: Wed, 29 Jan 2020 20:07:08 -0000
On Tue, Jan 28, 2020 at 12:28 PM Fernando Gont <fgont@si6networks.com> wrote: > On 28/1/20 13:53, Gyan Mishra wrote: > [....] > > > http://download.microsoft.com/download/F/D/F/FDF4CF55-5FDE-4CFF-8539-3662BB5EB7A0/TD13Basel2-43.pptx > > > > > > Beginning with Windows Vista and Windows Server 2008, a randomized > > > method is utilized to determine the Interface ID instead of EUI-64 > > > > That's better that EUI-64, but still bad. Windows employs constant > > IIDs, > > that allow host tracking across networks. > > > > Gyan> Windows does employ the privacy extension for rolling > > temporary address which addresses anonymity by using the temporary > > address for outgoing connections and the stable random IID for > > incoming connections. > > Nodes typically have two "types" of addresses: temporary addresses and > stable addresses. > > Even if you implement RFC4941, stable addresses that embed the > underlying MAC address pose a problem, because e.g. they result in > patterns, and thus make hosts possible to address-scan. > > > Windows did two things: > 1) They implemented temporary addresses (rfc4941), such that network > activity correlation over time is mitigated. > > 2) They implemented an alternative algorithm to the traditional > generation of IIDs based on the underlying MAC address (at the time they > did it, RFC7217 didn't exist). The algorithm that they use to generate > these stable IIDs is essentially the same as in RFV4941, except that, > since the identifier is meant to be stable, they don¡t rotate *this* IID. > > > One ould expect that they will replace 2) with RFC7217 (as recommended > by RFC8054). However, the flaws in RFC4941 (which you correctly > referenced) need to be addressed with a replacement for RFC4941: that's > the rfc4941bis draft we're discussing. > > Gyan> Agreed > > > {...] > > > > > > Are you aware of this vulnerability with RFC 4941 privacy > > algorithm and > > > why OS vendors started using random numbers versus the privacy > > > algorithm, which maybe why Microsoft started doing the same - > using > > > random number. > > > > You are mixing things up. > > > > Gyan> Please read the link for RIPE below regarding the RFC 4941 > > privacy algorithm vulnerability. Both links state the vulnerability > > with the existing algorithm. > > Indeed. THat's part of the motivation for rfc4941bis, and why we chose > to replace the algorithm that generates the interface identifier (IID) > > Gyan> Good! > > > > > > > > Microsoft started using randomized IIDs because there was no > > alternative > > to MAC-based IIDs (such as RFC7217). So tey were proactive, and did > > something to mitigate address scanning attacks. > > > > Gyan> Understood. As stated above from the links below Microsoft > > and other OS vendors moved to using their own random number generator > > schema due to the RFC 4941 algorithm vulnerability for both the > > interface IID and temporary address privacy extension. > > No, that's not correct. Microsoft implemented the randomized IID > because, at the time, the only standard to generate IIDs was to embed > the MAC addresses, and that has a number of issues, as noted above. > > As noted, there are two separate problems: > * stable addresses > * temporary addresses > > > The issue with stable addresses has been addressed by RFC7217. We still > need to address the flaws in RFC4941, and that's why we're working on > rfc4941bis. > > > Gyan> Understood > > > > > > > > > Here is another article that talks about RFC 4941 privacy > algorithm > > > vulnerabilities. > > > > > > > > > https://publications.sba-research.org/publications/Ullrich2015Privacy.pdf > > > > > > Do you think we should start this algorithm vulnerability in RFC > > 4941bis > > > draft? > > > > I don't think that would be of much use for this I-D. We could add a > > note such as: > > "This document addresses a number of flaws discovered in RFC4931 > > [references], and formally obsoletes RFC4941." > > > > At the end of the day, it's always better to give copius credit than > to > > offer half baked explanations. > > > > I've just realized that the ref to Johanna's paper was lost when we > > switched from to rfc4941bis. > > > > FWIW, the ref is: > > [RAID2015] > > Ullrich, J. and E. Weippl, "Privacy is Not an Option: > > Attacking the IPv6 Privacy Extension", International > > Symposium on Recent Advances in Intrusion Detection > > (RAID), 2015, <https://www.sba-research.org/wp- > > content/uploads/publications/Ullrich2015Privacy.pdf>. > > > > > > > > Gyan> So you will get the text language updates into the current > > version of 4941bis that was dropped from Johanna’s paper. I will stand > > down on adding updates to GitHub asked by Ole as we are on the same page > > now, and you will be updating. > > WHat I'm saying is that we coulf add something like: > "This document addresses a number of flaws discovered in RFC4931 > [references], and formally obsoletes RFC4941." > > thus making it explicit why we're changing the algorithm. The reader can > always go and read the reference for further details. > > WOuld this address your concern? > Gyan> Yes that will do it. It maybe good to describe the flaw vulnerability details in the RFC 4941 algorithm. Security is always a big issue and if you explain the vulnerability that would also help vendors get on board quickly with the new version. So in the bis version you mention multiple algorithms for Random IID generation. Would you nail it down to one maybe even the RFC 7217 method as the preferred alternative. Also doing so would give vendors the option to stay with new iteration of 4941 or support RFC 7217. > > THanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -- 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