Re: rfc4941bis: Change to Valid Lifetime of temporary addresses (take two)
David Farmer <farmer@umn.edu> Tue, 11 February 2020 21:46 UTC
Return-Path: <farmer@umn.edu>
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 2A41A12081E for <ipv6@ietfa.amsl.com>; Tue, 11 Feb 2020 13:46:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=umn.edu
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 eD59PRZcSgWG for <ipv6@ietfa.amsl.com>; Tue, 11 Feb 2020 13:46:45 -0800 (PST)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA4E120018 for <6man@ietf.org>; Tue, 11 Feb 2020 13:46:45 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 48HGZD6W7Qz9vbb1 for <6man@ietf.org>; Tue, 11 Feb 2020 21:46:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHeu4XrDLUYh for <6man@ietf.org>; Tue, 11 Feb 2020 15:46:44 -0600 (CST)
Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 48HGZD4SCPz9vbb0 for <6man@ietf.org>; Tue, 11 Feb 2020 15:46:44 -0600 (CST)
Received: by mail-qt1-f199.google.com with SMTP id r9so7633171qtc.4 for <6man@ietf.org>; Tue, 11 Feb 2020 13:46:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3BuoqeVzwuJNhntF30qI3ljBXsKYSgRoRbSgh/n//RQ=; b=ChtGZWLPBa3ilrjYRb8jZ8cpMcqMDlUjLrdJdFvA+cm34QplIj8rXFjT5jxWGZBgXL Wj1hcFztfeP6LS8wuCe/cQtTQdiT5E3GRSDGVGGKRqBWa1FmXG58oBGBvxXGL5tPB6Tv R5hmGuRbSICAts3vZEELHGoYNORhReWD5usLy/31KwS5w7INBkVId+mevQdgwL+QpynL ar47EKqX8/qoMQa+vej9cpfvDYeJEhf94r/rSyIhssDAKVwS0JIUh510dnuAU1tGskRA X4Ygizc/laBQCWctkAntyPSy+5iw7xBpMKS+Y9YHW5iOpyqax22mm4up0ce4PUD2q3ec pDww==
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=3BuoqeVzwuJNhntF30qI3ljBXsKYSgRoRbSgh/n//RQ=; b=anVjfs7d9chg9Q/GDJd7o/msHOyXzFLf2a/BxQq0YekYNaElUyg227Xw3slgMK8JDu /VtAjRfqn2i9l+44Y3rnBeiTaoqgQDqW85GQ3zZpmdWcw2Bk1Db9TfS+uBGbXOs4179Q np6zyi/w8u9KSOqBYl4qurC8+/hVit+O0kqg6pdUvZ9xdmGWGpOU8Tzj2kEBk1YRGGsH VHXjMmFGX1BS84XmyT/wfYlTvJaZZ5ApOHarqcqc9ZdnZV1Rwn3s3j/4EPTAaZ2Bg3xr xStay9jR1QsV86UA+U3UZR0C52WaBQYfFnUHohRyy2FCj7NossIRi/bLoQQS0LtZDE6T 6dKw==
X-Gm-Message-State: APjAAAUieQvSZlyKa011SqyQSbo1P0mwrqwrYK58Qi1eGk2q1xue8bip tP68uPsIyWM+habVR0PIRDXDHUqQwA9kbuMRRBIV0TfjxaIugdZ3Zcc/HqbDyZII+qlNHr4gpq7 6ec6LkXQzZC3AHhxmFpdJCmlM
X-Received: by 2002:ac8:6718:: with SMTP id e24mr17177983qtp.188.1581457603607; Tue, 11 Feb 2020 13:46:43 -0800 (PST)
X-Google-Smtp-Source: APXvYqx7C7YKZe1EwHihmjoTyTxVxOiV/WK2C5FEVce1rWA4Jthd2Iufd3XnFHQyuumvMdgtI8U6A5fSUcDlHUOlrIU=
X-Received: by 2002:ac8:6718:: with SMTP id e24mr17177947qtp.188.1581457603098; Tue, 11 Feb 2020 13:46:43 -0800 (PST)
MIME-Version: 1.0
References: <9cb65947-f634-e250-bfdc-134cfa2c91e9@si6networks.com> <eae18699-6141-e18c-783e-1ecab18733e5@si6networks.com>
In-Reply-To: <eae18699-6141-e18c-783e-1ecab18733e5@si6networks.com>
From: David Farmer <farmer@umn.edu>
Date: Tue, 11 Feb 2020 15:46:27 -0600
Message-ID: <CAN-Dau1cijVwDSovogevghp03X1_i7vUHstgtq91ekmM0RV0hA@mail.gmail.com>
Subject: Re: rfc4941bis: Change to Valid Lifetime of temporary addresses (take two)
To: Fernando Gont <fgont@si6networks.com>
Cc: "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a9108c059e53ca1f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/F1evdkAN91t9WKvQsjLeDXjCKgI>
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: Tue, 11 Feb 2020 21:46:48 -0000
I'm not that concerned with 7 addresses in most cases. However, I'd prefer to reduce the typical number of deprecated (still valid but not preferred) addresses to make room for additional active addresses. As I see it, with a 1-week valid time and a 1-day preferred time, you will have 1 actively used (the preferred) address, 1 marginally used (the most previous preferred) address, and 5 mostly, if not completely, unused (deprecated) addresses. I feel the value provided by those 5 mostly unused addresses, is very low and really only supports long-lived (multiple days) flows. The use of long-lived flows tends to reduce the privacy advantages of temporary addresses anyway. Further, the multiplicative effect of a large number of nodes on a network is significantly reduced, by eliminating these 5 mostly unused addresses. Thanks On Mon, Feb 10, 2020 at 10:29 AM Fernando Gont <fgont@si6networks.com> wrote: > Folks, > > This is simply a reminder/request for input regarding this proposed change. > > My understanding is that folks proposing this came from "if folks are > concerned, we could do this". > > I would like to get more input comments on the topic from other > participants. > > The change certainly would be fine. That said, in the context of > RFC7934, I'm curious if we could really be concerned about nodes using 7 > concurrent addresses (in the worst case scenario). FWIW, such number of > ongoing active addresses would only be hit if all of the unpreferred > addresses are in use by ongoing long-lived connections. Again, the > change would be fine, but I'd like input regarding whether it's really > warranted. > > Thoughts? > > Thanks! > > Cheers, > Fernando > > > > > On 30/1/20 19:27, Fernando Gont wrote: > > Folks, > > > > It has been suggested by Lorenzo Colitti, David Farmer, and others, to > > change the default Valid Lifetime of temporary addresses. > > > > Namely, to change it from the current (RFC4941) "one week", to "two > > days". This indirectly limits the maximum number of temporary addresses > > employed by hosts. (2, compared to the current 11 (as per RFC4941)). > > > > This requires these changes: > > > > * Section 3.5: > > > > OLD: > > Because the precise frequency at which it is appropriate to generate > > new addresses varies from one environment to another, implementations > > SHOULD provide end users with the ability to change the frequency at > > which addresses are regenerated. The default value is given in > > TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time > > at which to invalidate a temporary address depends on how > > applications are used by end users. Thus, the suggested default > > value of one week (TEMP_VALID_LIFETIME) may not be appropriate in all > > environments. Implementations SHOULD provide end users with the > > ability to override both of these default values. > > > > NEW: > > Because the precise frequency at which it is appropriate to generate > > new addresses varies from one environment to another, implementations > > SHOULD provide end users with the ability to change the frequency at > > which addresses are regenerated. The default value is given in > > TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time > > at which to invalidate a temporary address depends on how > > applications are used by end users. Thus, the suggested default > > value of two days (TEMP_VALID_LIFETIME) may not be appropriate in all > > environments. Implementations SHOULD provide end users with the > > ability to override both of these default values. > > > > > > * Section 5: > > > > OLD: > > TEMP_VALID_LIFETIME -- Default value: 1 week. Users should be able > > to override the default value. > > > > NEW: > > TEMP_VALID_LIFETIME -- Default value: two days. Users should be able > > to override the default value. > > > > > > Comments? Objections? > > > > Thanks! > > > > Cheers, > > > -- > 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 > -------------------------------------------------------------------- > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
- rfc4941bis: Change to Valid Lifetime of temporary… Fernando Gont
- Re: rfc4941bis: Change to Valid Lifetime of tempo… Gyan Mishra
- Re: rfc4941bis: Change to Valid Lifetime of tempo… Fernando Gont
- Re: rfc4941bis: Change to Valid Lifetime of tempo… Gyan Mishra
- rfc4941bis: Change to Valid Lifetime of temporary… Fernando Gont
- Re: rfc4941bis: Change to Valid Lifetime of tempo… Fernando Gont
- Re: rfc4941bis: Change to Valid Lifetime of tempo… Gyan Mishra
- Re: rfc4941bis: Change to Valid Lifetime of tempo… Fernando Gont
- Re: rfc4941bis: Change to Valid Lifetime of tempo… David Farmer
- Re: rfc4941bis: Change to Valid Lifetime of tempo… Lorenzo Colitti
- Re: rfc4941bis: Change to Valid Lifetime of tempo… Fernando Gont
- Re: rfc4941bis: Change to Valid Lifetime of tempo… Curtis, Bruce
- Re: rfc4941bis: Change to Valid Lifetime of tempo… Fernando Gont
- Re: rfc4941bis: Change to Valid Lifetime of tempo… Fernando Gont
- Re: rfc4941bis: Change to Valid Lifetime of tempo… Gyan Mishra