Re: Address privacy
Tom Herbert <tom@herbertland.com> Sun, 26 January 2020 21:35 UTC
Return-Path: <tom@herbertland.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 D6524120098 for <ipv6@ietfa.amsl.com>; Sun, 26 Jan 2020 13:35:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 O3m6PcOwszWo for <ipv6@ietfa.amsl.com>; Sun, 26 Jan 2020 13:35:28 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 F3A9E120043 for <ipv6@ietf.org>; Sun, 26 Jan 2020 13:35:27 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id dc19so8784996edb.10 for <ipv6@ietf.org>; Sun, 26 Jan 2020 13:35:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=caeZNIXffqnLSOKZdl6w9tJ74PjAtyqid68D0V/aJ6I=; b=HolYjNYXUsPVcWwSsM4srViWWQgS1r3plDgA+LPaE5JYban73KRHx6IVVAR+6llolk AnpyxmwncYjuvpelxULv7qey7dF4bMhLYr5/5dH7pG/njAhmkotO+oljEMG36/57w3XM RJeltgqI015BikQagRzgKXvu1Uw5Opfj3IzQ4P8dGZ8nCatEEoVvlsHvZRTHFE1zF+Jn lQj0XxjtMJ+ndu6TOkjpLIKeI+qJr8AIylPufZnLKP6M+dD9wOrgU1fCcsefbO73Hb+3 4yO9VDFAWcZZ5+tadpGcE3CbmykNJN80RS+vtQrTO1O+/J0joybL40/JRk1nmvutoEKA Tvew==
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=caeZNIXffqnLSOKZdl6w9tJ74PjAtyqid68D0V/aJ6I=; b=MejI06Jfm+2sytTYpPfeWcC3kZ2tGBUeKWux1jzT+PABZg3j6+0cyrbgAOf0lujM3v fqKj61Ktn27xpA95hVu2n7NmG+3ko6pxON31aM3dGwq3+k/JFs2so+iLpK2IwbXhWfFF tNUQpCKx0aTCBtsuvECkr/hBRdZrwG5DdRkfrHZ8i2GrPfJgxB7yi3bnwVf5RYR2yzMm yx4/0IswBbCREl2SaVX+kTgoSn6kG9PpWCd3S7hj/sYiOLI0tSVBGMDFbJQJXhm0MuZE xcdtRGEpCmXOI9Jei8aH+rM/FHIDj8fcjF79hbmCUlA3U+39zKppy3UJsnMpZEN9kgoB CSMw==
X-Gm-Message-State: APjAAAVxAQt7Am6cSbkh5ryKuUZWEAic4fAHwCw8jo9WiCz5JvubRerw uYMp0V0EQcZAw+asa5HoNn6kpZrOVlRjNqnjyk9ZXpD6Tn8=
X-Google-Smtp-Source: APXvYqwZHD1iHScf8wV1l1AhIvvwH1YBd1dHuLx0yVZLUvP+rhKcWx02v+H4JYyYvsYDfZiQbquXdaAcYOF0eN1QzYQ=
X-Received: by 2002:a50:fb08:: with SMTP id d8mr10817723edq.79.1580074526326; Sun, 26 Jan 2020 13:35:26 -0800 (PST)
MIME-Version: 1.0
References: <CALx6S36802oDaEgojAPq2c6hM_s1BayidXPh1Sc6RZmZa9UHpQ@mail.gmail.com> <89CDA9FE-6C41-4A5E-B6CD-ECC367DFDABA@employees.org> <1220b074-c7f5-bbc8-2991-a9af66caf8b7@gmail.com>
In-Reply-To: <1220b074-c7f5-bbc8-2991-a9af66caf8b7@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 26 Jan 2020 13:35:15 -0800
Message-ID: <CALx6S35oHgGDxa6014HB8UCYct0V9hcPFWqhiRM2kCgaPMtyqQ@mail.gmail.com>
Subject: Re: Address privacy
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/LiA9LCGv8WPNBVrKoXN9b1cnnk0>
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: Sun, 26 Jan 2020 21:35:31 -0000
On Sun, Jan 26, 2020 at 12:53 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > > On 27-Jan-20 09:20, Ole Troan wrote: > > The obvious answer is to put the source address in the encrypted payload. It does not have to be in the core header. > > There’s a paper on it somewhere, although I am not sure if that’s where the idea originated. > > Google "SNA: Sourceless Network Architecture" and "IPv6 source addresses considered harmful" > There's also the possibility of putting location information into a modifiable HBH option (part of draft-herbert-fast-04). Something like: - End host sends packet with HBH option for location - First hop in network writes its location into the HBH option. The location information identifies the hop (e.g. base station in a mobile network) and is only interpretable in the local network (encrypted for instance). - Packet is routed to destination with HBH option in tact. - At the destination, the HBH option is reflected on return packets for a flow. End host doesn't do anything else than just reflect. - At the ingress node to the network, the location information is decoded. Given this, the ingress forwards the packet to the locator node by address translation of encapsulation. - At the locator node, i.e. first network hop upstream of destination node, the encapsulation or translation is undone and packet is forwarded to the final destination. I think this method was first proposed to ensure consistent routing to the same backend in L4 load balancing. Obvious downsides are the we need EH to work in the network and there are changes needed in the hosts. Tom > Brian > > > > > Cheers > > Ole > > > >> On 26 Jan 2020, at 21:16, Tom Herbert <tom@herbertland.com> wrote: > >> > >> On Sun, Jan 26, 2020 at 11:59 AM Joel M. Halpern <jmh@joelhalpern.com> wrote: > >>> > >>> Tom, your description is somewhat misleading. > >>> > >>> On the one hand, LISP replies on per-flow state only in the mapping > >>> entity. Not at arbitrary places in the network. > >>> > >>> Secondly, if hosts work in terms of identifiers, and the network works > >>> in temrs of locators, someone has to map them. You can cache (including > >>> caching the whole thing), you can ask the host to hold the cache itself. > >>> There are other tradeoffs you can make, moving things around. But you > >>> can't just magically make the problem disappear. > >> > >> Joel, > >> > >> It comes down to how many addresses need to be mapped. It's intuitive > >> that a higher frequency of address rotation yields more privacy. But > >> higher frequency of address rotation means more active addresses in > >> the network. This degenerates to the greatest frequency of change > >> which would be to give each flow it's own unique address, and this is > >> also the one case of temporary addresses where we can quantify the > >> privacy characteristics. > >> > >> However, giving each flow its own address quickly becomes a scaling > >> and management problem-- we're talking several billions of active > >> addresses in some provider networks. Hence, I believe we need mapping > >> functions that are more N:1 than 1:1 (the latter doesn't scale). > >> Similar, the ability of the network to delegate and map bundles of > >> uncorrelated addresses to devices would be useful. > >> > >> Tom > >> > >>> > >>> Yours, > >>> Joel > >>> > >>>> On 1/26/2020 2:51 PM, Tom Herbert wrote: > >>>> On Sun, Jan 26, 2020 at 9:42 AM Michael Richardson > >>>> <mcr+ietf@sandelman.ca> wrote: > >>>>> > >>>>> > >>>>> Tom Herbert <tom@herbertland.com> wrote: > >>>>>>> Except that instead of doing it at layer 4, you do it with IPsec, and extrude > >>>>>>> that /128 to your machine. This is already a thing :-) > >>>>>>> > >>>>>>>> Another solution I’ve considered is to have a giant anonymity mesh, > >>>>>>>> with every ISP’s user participating, and forward flows through this > >>>>>>>> mesh, treating each customer as an anonymity server. I think this is > >>>>>>> > >>>>>>> This is also a thing called Tor. > >>>>>>> > >>>>>> Michael, > >>>>> > >>>>>> Doesn't that require that the users must explicitly configure when > >>>>>> they want privacy? I think a general solution should be transparent to > >>>>> > >>>>> Yes, I agree, it requires explicit configuration. > >>>>> I agree that this is not a good thing. > >>>>> > >>>>>> the user and "just works" to ensure their privacy. That in fact is one > >>>>>> of the arguments for NAT. If there is a significantly large enough > >>>>>> pool of users behind a NAT device, then the obfuscation is transparent > >>>>>> to the use and seems to be pretty good privacy (good enough that law > >>>>>> enforcement is concerned about NAT). I suppose a similar effect could > >>>>>> be achieved with a transparent proxy. > >>>>> > >>>>> Yes, and I think that more and more LEA will grow ever concerned about this > >>>>> situation, and it *is* pushing IPv6 adoption. So, how can we find a happy medium? > >>>>> > >>>>>> You might want to take a look at draft-herbert-ipv6-prefix-address-privacy-00. > >>>>> > >>>>> An interesting read. I'm not sure where it goes. > >>>>> > >>>>> I would like Locator/Identifier separation. > >>>>> I wanted SHIM6. LISP would work, I think. > >>>>> Then privacy needs don't need to screw up efficient routing at the edge. > >>>>> > >>>> Hi Michael, > >>>> > >>>> The problem of LISP is that it potentially includes a cache in the > >>>> operator network that can be driven by downstream untrusted users-- > >>>> hence there is possibility of DOS attack on the cache (this is the > >>>> primary reason why LISP hasn't been accepted into Linux). > >>>> > >>>> What we really want is Identifier/Locator routing that neither > >>>> requires per flow state to be maintained in the network nor relies on > >>>> caches to get reasonable performance. > >>>> draft-herbert-ipv6-prefix-address-privacy suggests crypto functions to > >>>> map identifiers to locators at the edge. > >>>> > >>>> Tom > >>>> > >>>> > >>>>> > >>>>> -- > >>>>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works > >>>>> -= IPv6 IoT consulting =- > >>>>> > >>>>> > >>>>> > >>>>> -------------------------------------------------------------------- > >>>>> 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 > >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > 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 > --------------------------------------------------------------------
- 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