Re: RFC4941bis: consequences of many addresses for the network
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 23 January 2020 17:52 UTC
Return-Path: <pthubert@cisco.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 925041209B1 for <ipv6@ietfa.amsl.com>; Thu, 23 Jan 2020 09:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LJIw92mP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jw6b2cyI
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 1fUiGGAzkHts for <ipv6@ietfa.amsl.com>; Thu, 23 Jan 2020 09:52:37 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9FC1209A2 for <ipv6@ietf.org>; Thu, 23 Jan 2020 09:52:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4620; q=dns/txt; s=iport; t=1579801957; x=1581011557; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0RHkCMXtJ2id8IBuuofyukDwC0nZUI04M2HoAuXvcSg=; b=LJIw92mPVJ+6gvtaHq2bMUdqqB4yEu/+JYbdxL5de5rrh8q8aC7F0aPk WG10PafQ29he5mm1/wkMAo8iG9T1rVNSLcla1mKcdOmLCsnYe5JA52JGM naZu0HCOCbDi7c2tgO+TjpdN85EFmYn0P+ZfBEX4ae9qX8PmsJGPRXcHL Q=;
IronPort-PHdr: 9a23:pTjXRRP14JjlzxUpxP0l6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETBoZkYMTlg0kDtSCDBjjMP73ZSEgAOxJVURu+DewNk0GUMs=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BHAADW3Cle/5xdJa1lGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYFqAgEBAQELAYFTUAVsWCAECyqEEoNGA4sOgjoliWGOLoJSA1QJAQEBDAEBGAsKAgEBhEACF4IHJDcGDgIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAgEBARAREQwBASwLAQQLAgEIGAICJgICAh8GCxUQAgQOBSKDBAGCSgMOIAECDKFnAoE5iGF1gTKCfwEBBYJEgkcNC4IMAwaBDioBhRqEM4JJGoFBP4ERJwwUgkw+gQSBF0kBAQOEcDKCLI08JIJ1nj9ECoI5h0CKS4QpG4FYmR+XQIIikAQCBAIEBQIOAQEFgWgjgVhwFTsqAYJBUBgNiAEYg1uFFIU/dIEpjBsBAQ
X-IronPort-AV: E=Sophos;i="5.70,354,1574121600"; d="scan'208";a="411898583"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jan 2020 17:52:35 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 00NHqZcK014913 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Jan 2020 17:52:35 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 11:52:34 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 12:52:32 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 23 Jan 2020 11:52:32 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DArcdsR0SQHQF1KaQXgXsaCcTFT97Numce2nlF6nQoUgdC0T8jVu3OacglYU/9mJj3LYMyRo5mcapmyfYOk/VSNuNCF8GXh4dy+JgnQDJhgfwYH7zR3sxTIS1iG3IP7cflBrIvvVMW3JxiqUHcqhka6YR77MsP6dcGm7RYBgh15L2fF6V3R7ivZsY7/9+DdpNexopOkXPHDjoAK5SCeNcFs0hmFekUjQ/qdRSwhgo4i+MhMogqNs5zL9EDIHaBTya4fcJLS91aseqGNCtbvSoP4wZcQj6r4ncbl0pVrxgut7X5BUvE0mJ2LkiCTa5wRh/3Fx9CF0A++D5py+UUWr/Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0RHkCMXtJ2id8IBuuofyukDwC0nZUI04M2HoAuXvcSg=; b=MFtrha/OCl+mobXI8ZuPSJqCdT9OIHTFlhkRkG35baCnBvERE8LdUdWuqtzoLm0TPxcCdXr6slgG8uOQ4/dR2mpuioxxUwbKVis15d3xu2vjj7IoWX7pXM1Lyvf+4+X5b1AaWX2Cfn7bDRRSWX1CGol+NZUuk6T3a5kw597RR+Q8wxnZXzdn7upcsjVra/s8dqZPaRpW6zMfJK/NxSDeT6mqIiYXOlqJsh4qR0eJzPppzN1zjD6eK6YAVn9UOzZpwHRR73tWiDng59hvTvhr/n2qtf+zgxEmJqKsXA2jVv7FNoLfA0TX63GbSSi/LFY/uSpqiRkfpK0QpGlhs56K3w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0RHkCMXtJ2id8IBuuofyukDwC0nZUI04M2HoAuXvcSg=; b=jw6b2cyIpgJIBq9LKixk/eILuOriyjXahkuN40W8uPDGicR2kx3ZLOeHFB5UndKROOoz5peOznS4AD7Oso9q+8zOtajWVbvpMTY8Qq99L5OVejxkP+g6jNCY/A40Iam3alonxS0CIRcJl2w27y8+XesvWqnNlGesVm3ZeMLSD+Y=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4399.namprd11.prod.outlook.com (52.135.36.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20; Thu, 23 Jan 2020 17:52:31 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2644.027; Thu, 23 Jan 2020 17:52:31 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Bob Hinden <bob.hinden@gmail.com>
CC: Ole Trøan <otroan@employees.org>, IPv6 List <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: AQHV0ct5x17hjGfK3kqevW8Gxhyx/qf4gxYAgAAFF98=
Date: Thu, 23 Jan 2020 17:52:31 +0000
Message-ID: <059D9CB7-9677-4CD2-BCDC-2393FA072BD7@cisco.com>
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org>, <2044DC74-3529-45BF-9886-56030B5EA515@gmail.com>
In-Reply-To: <2044DC74-3529-45BF-9886-56030B5EA515@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:d964:c04c:535:e391]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1698899d-e285-414f-e2c1-08d7a02d04f8
x-ms-traffictypediagnostic: MN2PR11MB4399:
x-microsoft-antispam-prvs: <MN2PR11MB439964F82D0DDEC1302C55A3D80F0@MN2PR11MB4399.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 029174C036
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(396003)(376002)(136003)(346002)(199004)(189003)(86362001)(8676002)(316002)(54906003)(6916009)(36756003)(71200400001)(81156014)(81166006)(8936002)(2616005)(5660300002)(66574012)(53546011)(6506007)(186003)(966005)(4326008)(6486002)(33656002)(2906002)(66446008)(64756008)(66556008)(66476007)(76116006)(6512007)(91956017)(478600001)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4399; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xHRYEQF3S6I1VcZm+LsATYCreH2zDqSUFHrA1aoVzRIxTENK+1AISGuWSdAHABmnag1trEZxE0EU4FcnHTiIcF5uEPCaS0fV3avN/W6RXjZuh0jcwo6nVF3esyyvOvtXBvvRtm4QNDwNWHIIrq4PTPR0i/tPlv0unwkYBJqaSNa6Hmf8h3+TsyngI4pPOjK2GWXxzm2v3kRDGN2wLJ8gvf2bO4zBK+UZJeNjSyHQFOV7L9zTYJv2oYiiPiATjuBSDgoSydNiSjS6loHuoLGCb3kvlaGhj1g5LW+t6r1uGUKxAKX64Hn+XFnEg6z9fqIee4P7SgRyqMRCYg6aDyJ6m7urXfnJGHCiQN0AeE6DFSuRu14QXH+/SEAbo2kGu7lVO4U2Fx37krnMkLDpj6fqVmz0MLpa/LxYcdvEkIYs7RcFJQ4Gzu0WWddr6IgTEQt9qkzG/W4XYGnSb1QnhF+g57oi4H0Shh254H5ntGAszpyiJ3YaoY0iXWAernD/Nq5VQw/SwAKLn022UBS0z2HDFQ==
x-ms-exchange-antispam-messagedata: IP8RV899I+adX4FDR6RbUavTuHaFgegn+fTiIh5vTiBVNgju/vi2CzjWmjTCmD5PppYPrBMixmtX0Aji/jBcx1iw72WfiLMH0hf3bTHkdsfe3DO0K6TWXL6msjXVEpzfniV3svWHjja+/B7jCNUSSBGQMK6jxbU1vb2Okfd5RB6Qc/9YK/aVPlIcO9MZwKUewHOO4mlgHWbHgLnvD2DzAg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1698899d-e285-414f-e2c1-08d7a02d04f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2020 17:52:31.1568 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5BtBb/i0yKbnE/FIRF4Jq8SnJ0Ft2EeWAufxSDqJkhPXJfffUk4pmdwRSFy+DgMUVAMjgryRYNrSU9m8h8OqUA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4399
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/CIHJvmMCdv_JxR8A1S2bQP5Su2s>
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 17:52:40 -0000
Hello Bob The issue is not confined within the node. This impacts the routers and the whole infra (think VXLANs). Regards, Pascal > Le 23 janv. 2020 à 18:35, Bob Hinden <bob.hinden@gmail.com> a écrit : > > Ole, > > Clearly a very number of addresses is a problem for router and other devices on the link. I note looking at my local machine (MacOS 10.14.6) I have five IPv6 addresses: > > Link-local > ULA (temp and secured) > Global (temp and secured) > > My router advertises a Global and ULA prefix. > > This seems to be current practice. Is this a problem? If I had 100 local devices on my link that would be 700 addresses, 1000 devices, then 7,000 addresses. Is that excessive? Also, depends on how the nodes manage this state, completely separate entries for each address, or all the addresses tied to the same link address. > > For RFC4941bis, I think text that raises the issue is a good thing, but the issue isn’t created by the bis draft, it a part of SLACC. We have multiple ways of creating IPv6 addresses, they all contribute to this. > > I think a new document that discusses the issue and makes some recommendations would be useful. > > Bob > > > > > > >> On Jan 23, 2020, at 12:59 AM, otroan@employees.org wrote: >> >> While reviewing RFC4941bis (https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis) I think I found one gap. >> >> A discussion of the consequences of a host having many (active) addresses on the network. >> >> A 4941bis implementation following the defaults, would at the maximum use 8 active addresses. >> (Valid lifetime of one week and one new address per day.) >> >> Shorter regeneration intervals or other approaches like a new address per connection could lead to dramatic numbers. >> >> If we use Ethernet as an example, each new address requires state in the network. In the ND cache in first-hop routers, and in SAVI binding tables in bridges. Given ND's security properties these tables must be policed by the network. A host with a very liberal address regeneration policy might be viewed as performing an attack. >> >> There is no signal available in SLAAC apart from DAD to reject an address. If the network runs out of resources (or prohibits the additional address by policy) the address will not be served. The host has to be deal with that situation. >> >> SLAAC is also missing a mechanism to release an address. Which leads me to think that the address regeneration interval must not be shorter than the ND cache scavenger timeout (which in many networks is high to avoid cache churn and high level of address re-resolutions). >> >> I would like to hear from other network-side implementors and operators. >> Is there an issue here? >> >> Best regards, >> Ole >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- 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