Re: RFC4941bis: consequences of many addresses for the network
Gyan Mishra <hayabusagsm@gmail.com> Fri, 24 January 2020 07: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 AE27912004F for <ipv6@ietfa.amsl.com>; Thu, 23 Jan 2020 23:07:29 -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 61j6LWIi4BL1 for <ipv6@ietfa.amsl.com>; Thu, 23 Jan 2020 23:07:25 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 78B66120044 for <ipv6@ietf.org>; Thu, 23 Jan 2020 23:07:24 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id b15so475988lfc.4 for <ipv6@ietf.org>; Thu, 23 Jan 2020 23:07:24 -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=riLsYtmaz+V8Z0EGKjfgq5G7pdGfzEXh+s/HmMiDAAQ=; b=WEuKu9cxBvB28OB6zh3a2LH/TA9e11ctIG/BimUvihpdxDLwV3lnlCnrn1wHMAqbaV 8z5jJSf4+4qeU6E1gYWeg4gkWdPpStpPcBGEEjACJwmXzMJnhlw8HUmPU85pNFY/WvM/ GLCpPTsfEUWY+cIbx4DKfcZFqANUVOApr5pViq9eSisKWr+O3M/BgxVOusbX9RRlLHfp r36N5CzmeXf5Y8TZy3tltgIVpYLtXqb4SnyF303lU1l8hi264c7UVvGdfzO/5Nr0UPYc lCMmXSpfyRodF6q7PuBjzmnm2/3Rw/Y9FqaBqOT2kJQPQa9aq6Q1MnEEfEUcc8tIc7Lf KBzA==
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=riLsYtmaz+V8Z0EGKjfgq5G7pdGfzEXh+s/HmMiDAAQ=; b=HDnk5UfTRTGSie+YUELgxQTX0BZLRaz+TFO+5LAtnL6/mLcKl5kjpiPDxc4J8KOjC5 ZZBqCAs68kM36xqQzH+LQYYr+3fieuTylO6zN/sZTgUFfSu7FqOfK+SGvQe1sKERkQ+g p5FqFPtF7dQu9fD1fOXahgxf76mCEJZczxY78QWE/48sZZppQ9Np44lCHTOCWvjE06kk S8ss6F5m7g+Cuy0OTophIncz3kJKBgEfthNYaLZro/SpJx0s2euGsX/3otYKXD5tBH2z tQ85As49c08xrwaDEpUEPkI8WS4n14BwSWBSoPLbR2zNI2ZjjNWLpALWSudi46UphcN6 hXDA==
X-Gm-Message-State: APjAAAUC2ZrczcbgOwCWQXlbGXxUVMKdEXNBSbmdSn/D3JDSm16vIXAe ZCGnfLlK8Clsk1oD4tnm1+70zznjRmPnE1V2J7o=
X-Google-Smtp-Source: APXvYqyPcKejSOu+Aj487EmhQdGdTi3Gk5ATDXi+JS7HS3M28m6qkOJTL5p7mhAl29FYOp0Ljhg0j5zH0MIUWOsux8k=
X-Received: by 2002:a19:750e:: with SMTP id y14mr755428lfe.86.1579849642524; Thu, 23 Jan 2020 23:07:22 -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> <d56939d6-d577-ced3-e1e7-a4713bc95cd9@si6networks.com>
In-Reply-To: <d56939d6-d577-ced3-e1e7-a4713bc95cd9@si6networks.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 24 Jan 2020 02:07:11 -0500
Message-ID: <CABNhwV2n2NHu1tLMNeq7BSBYwsOY46yob_p1NH4GEcye5r9RVA@mail.gmail.com>
Subject: Re: RFC4941bis: consequences of many addresses for the network
To: Fernando Gont <fgont@si6networks.com>
Cc: 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="000000000000bdc498059cdd68bc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/AW4sRA0P0BEi2WqwKG1EBRyiduQ>
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: Fri, 24 Jan 2020 07:07:30 -0000
On Fri, Jan 24, 2020 at 12:45 AM Fernando Gont <fgont@si6networks.com> wrote: > On 23/1/20 20:49, Michael Richardson wrote: > [....] > > > > I also have doubts about whether the rotating temporary address > mechanisms > > that 4941 provides is useful privacy when the upper-64 bits are > unchanging. > > But, I agree with you, that it is an improvement... except when it causes > > other issues. So we should consider when and where it's more effort than > > it's worth, and when it has benefit. That requires information that is > > presently not available to hosts. > > As noted by Bob, myself, and others, this is a slaac issue, and not > something specifically related to 4942bis. > > For instance, an ipv6-aware browser might e.g. decide to configure and > employ different addresses for each tab, or for different apps. And > you'll end up with way more addresses than those resulting from rfc4941. > > > > > > > > I also think that we need to recognize that we have a number of distinct > > deployment environments, and I think that we should be explicit about > them: > > 1) protected home environments > > 2) guest home environments > > 3) enteprise environments > > 4) conference/guest/coffee-shop environments > > 5) >4< at ridiculous scale > > 6) segregated L2 environments with vertically integrated operators (aka > > "LTE", Fred's ATN work, possibly RAW). > > If you expect hosts to behave nicely with your network, then you should > probably convey policy information in RAs (as we tried, to some extent, > in draft-gont-6man-managing-privacy-extensions). At the time, there was > pushback. > > If slaac doesn't convey policy, then nodes do what they assume is in > their best interest. > > And if the network doesn't really like the possible chaos resulting from > slaac, then it should probably be using dhcpv6. > > The nice thing about us doing nothing about the automatic configuration > mess, is that it typically gets worse: e.g. my CPE sets "M" and "O" in > RAs, while advertising PIOs for autoconf. So my Ubuntu conf ends up with: > * slaac stable addresses (RFC7217) > * slaac temporary addresses (rfc4941) > * one dhcpv6-leased address > > > PLease let me reiterate: the problem being discussed in this thread is a > shortcoming of slaac. > > It's certainly fine to add a note along the lines of "hey! don't > regenerate addresses too frequently (i.e., beware when overriding > default falues(, or else you might end up screwing the network". > > But other than that, 4941bis is not about addressing shortcomings of slaac. Gyan> This draft addresses the operational impacts of multiple addresses for SLAAC defined with RFC 4862. With PIO options capability the network has the ability to send the host multiple addresses to the host. Some implementations I have seen have a ULA 4193 address and a GUI address sent in the SLAAC PIO prefix list. Although I have tested this scenario in the lab, practical use of the address and which to use with the host OS default source address selection algorithm is too complicated. It would be nice if you could use the ULA for internal intranet communications and GUA for external but unfortunately it does not work that way. Their is a pecking order built with the source address selection algorithm and thus the same address ends up being used all the time for all flows. Defeats the purpose or reason to have multiple addresses if the same one always gets used. Most host Operating Systems such as Windows and MAC by default have RFC 4941 privacy extensions implemented which generate a temporary address which has default valid and preferred lifetime which are configurable by the operator. Definitely having multiple addresses on a host from an operations prospective adds tremendous complexity. Operations and user operational late of complexity is added to now determine which address is used for conversation flows. By default most operating systems both windows Mac and others follow a default address selection pecking order to determine which address. RFC 6724 defines this default address selection algorithm used in cases where multiple PIO addresses exist on the host. End result of the source address selection algorithm is the same address is used all the time. With implementations I have deployed personally from an operators and IT security perspective as a standard for host images we would disable the privacy extension temporary 4941 privacy address and also disable the random IID so end hosts IPv6 address is stable. For IT operators simplicity is key for troubleshooting and trying to determine which address is used for a conversation flow is an operations nightmare. IPv6 SLAAC address privacy makes sense and is Ok if you are connected to the internet, however on corporate owned host endpoints for endpoint security “stable” address is utmost importance. My recommended direction for operator is to disable SLAAC random IID and temp privacy address until RFC 7217 semantically opaque IID and RFC 8064 stable IID are implemented by host OS vendors which as Microsoft and Apple. Also for simplicity in troubleshooting from operations perspective, even though IPv6 with PIO options had the ability to send unlimited number of prefixes to a host I would recommend only sending a single address. Since this draft talks about all the IID generation schemes I think it should talk about operational impact of each option implemented. Maybe there should be another draft which discusses SLAAC IID options and operational impact I can kick start a draft that discussed this topic and makes a recommendation as I mentioned above. Kind regards Gyan > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- 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