Re: RFC4941bis: consequences of many addresses for the network
Tim Chown <Tim.Chown@jisc.ac.uk> Thu, 23 January 2020 13:33 UTC
Return-Path: <tim.chown@jisc.ac.uk>
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 D858C12009C for <ipv6@ietfa.amsl.com>; Thu, 23 Jan 2020 05:33:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (1024-bit key) header.d=jisc.ac.uk
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 mYh5zlf3NQUU for <ipv6@ietfa.amsl.com>; Thu, 23 Jan 2020 05:33:22 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02DB31200B9 for <ipv6@ietf.org>; Thu, 23 Jan 2020 05:33:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1579786399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=auU1yXNWMj37Mwr2Dsxi8zGPNx2FCEOK6D3bAnXZWHo=; b=COvY1VXwEjjgnDQ8kvrMNWPNWPiKYFS1I/CLyX803VgwzGBNp8d5oHPE4wWZ0ej2tqhGXR KsVXK0g6x9c4s4Q/RKyRZAIGrX8zaYTx57qj2UDvXrklVfjFFhFvaBJMAMZszRSOc6OF2G J6uFinBBTCpQN07kUpWjjp/zVIpVBJE=
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp2050.outbound.protection.outlook.com [104.47.2.50]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-126-W0DH5vfNMu2pd3bPxqUaCQ-1; Thu, 23 Jan 2020 13:33:01 +0000
Received: from AM5PR0701MB2849.eurprd07.prod.outlook.com (10.168.153.149) by AM5PR0701MB2979.eurprd07.prod.outlook.com (10.168.156.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.13; Thu, 23 Jan 2020 13:32:59 +0000
Received: from AM5PR0701MB2849.eurprd07.prod.outlook.com ([fe80::1446:7407:4077:14a4]) by AM5PR0701MB2849.eurprd07.prod.outlook.com ([fe80::1446:7407:4077:14a4%9]) with mapi id 15.20.2665.017; Thu, 23 Jan 2020 13:32:59 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: "otroan@employees.org" <otroan@employees.org>
CC: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, 6man WG <ipv6@ietf.org>
Subject: Re: RFC4941bis: consequences of many addresses for the network
Thread-Topic: RFC4941bis: consequences of many addresses for the network
Thread-Index: AQHV0cuAf+cCl/1lXUyJflIGA5fqsKf4C5QAgAAepwCAABVvgA==
Date: Thu, 23 Jan 2020 13:32:59 +0000
Message-ID: <8D5610EA-49D3-483E-BB7A-67D67BC89346@jisc.ac.uk>
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <MN2PR11MB3565330989D411525D30B90DD80F0@MN2PR11MB3565.namprd11.prod.outlook.com> <80207E17-AE8E-4D19-B516-D2E6AB70721E@employees.org>
In-Reply-To: <80207E17-AE8E-4D19-B516-D2E6AB70721E@employees.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.40.2.2.4)
x-originating-ip: [194.82.140.195]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4e0d41d4-e5ac-4f41-9440-08d7a008c381
x-ms-traffictypediagnostic: AM5PR0701MB2979:
x-microsoft-antispam-prvs: <AM5PR0701MB2979C64A00CE37476BA8FEBCD60F0@AM5PR0701MB2979.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 029174C036
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39850400004)(346002)(396003)(376002)(189003)(199004)(36756003)(86362001)(71200400001)(186003)(786003)(316002)(54906003)(4326008)(6512007)(5660300002)(2616005)(2906002)(81156014)(8936002)(6486002)(53546011)(6506007)(8676002)(81166006)(6916009)(966005)(91956017)(66476007)(76116006)(478600001)(26005)(66946007)(66556008)(64756008)(33656002)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2979; H:AM5PR0701MB2849.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Hf7zXnaUKAi+lDiHx2uMNxjx8d0tAeRVfwx9V+SmTWRYM30Nrj8pNtf6PXV49A8qus+zduefQBzME8Mq2NIJiAbcy1vtzTxawbqqyDtt8Yfp3GMIycHhDn7TCy4LOU3tY5KMAu4MzRwmdr9bFXVZ5g/ElXKWktukFsHMYB/bjQGjBYte2iBXjS0bsecHwLfg2ligd7XwXr2Y3dkhobmUq41ph1iFBuFQB1hlxUYC6SmAsTh/w41hHG7bzjKX3QxuXtCr6JdsOn7VphusXih0ecS5Dq2RSf7Ds2lRm4Bqx+dvYsShRBC6A1uRwmS8Z0sqD6zr3Wx8YViL9zjsSnxR/wCYx0uQDXc6LwmYLeqdqsLHst3DlbU9BQwHAd7Is7Z101wCyUuJmC9KBDdaJ2ghL+F5rFTG5S3f3CnyYYW1NsrZCannckSKicLkAsfGE2u3px0bnPSAW7CCJteb0cfo/WIKI63WliV9gIrAYTo+WwY=
x-ms-exchange-antispam-messagedata: tzrcKzAI0AU3isz7y1RhpIYVWF/fggUELL+hV/cX34w8GqtwnPPCINmIqVwnOoWdTmwXp1IQNEiXtW4TFSViNLWeb5vePOaEbKWMnBLetsdDMfQ7LyBb4Lhhj0tPp0A5KxC62WXJciLsL+AFUn9wnQ==
x-ms-exchange-transport-forked: True
Content-ID: <60FDCADCF757C44BA4480424F4A75074@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 4e0d41d4-e5ac-4f41-9440-08d7a008c381
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2020 13:32:59.4791 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VAllRY0OJCzjHIoswO6g3JZpbTrvHcWYUVlSk/RHtW1jjogDKwnBKg/NWn+ILcoopgdGtIKwp9dg+awhAyikNQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2979
X-MC-Unique: W0DH5vfNMu2pd3bPxqUaCQ-1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: jisc.ac.uk
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/R_oUswCZG0BHLajgYUfzu0fpZPc>
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 13:33:25 -0000
> On 23 Jan 2020, at 12:16, otroan@employees.org wrote: > > Pascal, > > All good points! > Before this diverge too far though, can we try to focus on RFC4941bis text. > Is there anything that document can say or should say to alleviate some of these issues? > Does temporary addresses add to the more general problem that SLAAC has? The problem statement section in 4941bis is all about user privacy, no mention of operational / management complexity, or other “general problems” that SLAAC has. It seems there are unstated problems here :) Tim > > Cheers, > Ole > > >> On 23 Jan 2020, at 11:26, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote: >> >> Hello Ole >> >> There are a number of cases where the address creates a state in the network: >> - in case there's routing taking place within the subnet (e.g., RPL in the an IOT LLN and RIFT or eVPN in a data center) >> - in case the network protects the address ownership since ND doesn't (SEND being what it is) and does minimal SAVI >> - in case the network tries to implement ND proxy which is mandated by IEEE std 802.11 >> - in case Jen's draft is used to proactively assign ND state in the routers >> >> In order to protect itself, the network blocks excessive amounts of addresses for a same device. It would serve this list to recognize it as a fact of life. >> >> Sadly it is very hard with IPv6 ND alone to decide which address(es) to keep and which to remove. For the temporary addresses, LRU seems to work most of the time, with a reasonable count of like 8 as suggested below. But some nodes like printers (silently) keep a permanent addresses that should survive the churn of other temporary addresses. >> >> To serve the hosts correctly, the network is missing a classical but so useful information of lifetime that allows the state associated to the address to age out if not renewed. It is also classical in many IPv6-based standards (e.g., MIPv6, NEMO and RPL) that the nodes have a chance to release a binding by indicating a lifetime of zero. The shortest path to get that is generalizing RFC 8505 to all MAC layers. *Is there any reason we do not?* >> >> Conversely the network cannot signal how many addresses per node will be served properly in parallel. It cannot recommend lifetime values for temporary addresses and quasi-permanent addresses. It cannot signal that it rebooted and that all state need to be rebuilt. We need new RA information for that. I can write the draft within a few days if the group is willing to progress the work. >> >> All the best, >> >> Pascal >> >>> -----Original Message----- >>> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of otroan@employees.org >>> Sent: jeudi 23 janvier 2020 09:59 >>> To: 6man WG <ipv6@ietf.org> >>> Subject: RFC4941bis: consequences of many addresses for the network >>> >>> 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 > -------------------------------------------------------------------- >
- 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