Re: RFC4941bis: consequences of many addresses for the network

Fernando Gont <fgont@si6networks.com> Fri, 24 January 2020 16:37 UTC

Return-Path: <fgont@si6networks.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 C968C1209F5 for <ipv6@ietfa.amsl.com>; Fri, 24 Jan 2020 08:37:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Vk-OpOR4TGP7 for <ipv6@ietfa.amsl.com>; Fri, 24 Jan 2020 08:37:09 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3467B1209E7 for <ipv6@ietf.org>; Fri, 24 Jan 2020 08:37:09 -0800 (PST)
Received: from [192.168.100.103] (unknown [186.183.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 396C782C03; Fri, 24 Jan 2020 17:37:02 +0100 (CET)
Subject: Re: RFC4941bis: consequences of many addresses for the network
To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, ipv6@ietf.org
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <e936078e-01f9-0254-a8d0-4095455154ac@si6networks.com> <D85412DF-4B03-4790-9E39-968D50ECF86B@employees.org> <m1iuwJV-0000MAC@stereo.hq.phicoh.net> <B341FF1B-C559-4D54-B117-A58EB6A3C955@employees.org> <dfe3a236-4e61-d2be-929c-869a81994879@si6networks.com> <m1iuxwI-0000M3C@stereo.hq.phicoh.net>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <d8108aa1-f325-0eff-ae2e-f325363a9121@si6networks.com>
Date: Fri, 24 Jan 2020 13:36:27 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <m1iuxwI-0000M3C@stereo.hq.phicoh.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8MnBOreeIqociPH-S6uW2OoZSyQ>
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 16:37:14 -0000

On 24/1/20 09:19, Philip Homburg wrote:
>> However, when it comes to rfc4941bis, I don't think there's much more to
>> do than simply including a small paragraph noting that an implementation
>> should be aware about regenerating addresses too quickly,
> 
> If people feel strongly about the risk of generating temporary addresses
> too quickly, why not have a TEMP_MIN_PREFERRED_LIFETIME and have some
> text that a node SHOULD NOT generate temporary addresses more often
> than one address (per prefix) per TEMP_MIN_PREFERRED_LIFETIME.

I guess the issue here is which value to pick for it; i.e., something 
that gives enough leeway for folks that want to tweak this parameter, 
but now too low to alow folks to cause damage.

If anything, I'd probably employ the limit enforced on BSDs and Linux (I 
don't remember the specific value, but could check). It's mostly there 
to prevent insane settings, but still allows hosts to generate addresses 
quite frequently.

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492