Re: rfc4941bis: Change to Valid Lifetime of temporary addresses (take two)

Fernando Gont <fgont@si6networks.com> Sat, 15 February 2020 18:10 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 2D5BD1200E6 for <ipv6@ietfa.amsl.com>; Sat, 15 Feb 2020 10:10:35 -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 zVFrc-fEXGnZ for <ipv6@ietfa.amsl.com>; Sat, 15 Feb 2020 10:10:33 -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 BFCF2120105 for <6man@ietf.org>; Sat, 15 Feb 2020 10:10:32 -0800 (PST)
Received: from [192.168.100.107] (unknown [186.183.49.237]) (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 A484486CAA; Sat, 15 Feb 2020 19:10:28 +0100 (CET)
Subject: Re: rfc4941bis: Change to Valid Lifetime of temporary addresses (take two)
To: Lorenzo Colitti <lorenzo@google.com>
Cc: "6man@ietf.org" <6man@ietf.org>
References: <9cb65947-f634-e250-bfdc-134cfa2c91e9@si6networks.com> <eae18699-6141-e18c-783e-1ecab18733e5@si6networks.com> <CAKD1Yr1bZwz6gO1OUR16gubYd+k5EGjO+xqargy-pM6ZVMk8dw@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <b9e49215-ac91-ccdc-a518-7282d9571e69@si6networks.com>
Date: Sat, 15 Feb 2020 15:06:02 -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: <CAKD1Yr1bZwz6gO1OUR16gubYd+k5EGjO+xqargy-pM6ZVMk8dw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/aL3J500jPdhHGXCFCm8xeTK33pk>
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: Sat, 15 Feb 2020 18:10:39 -0000

On 11/2/20 18:58, Lorenzo Colitti wrote:
> I think this change is an improvement. Keeping arond 5 addresses that 
> are not useful seems like a waste of network capacity. An application 
> that is not resistant to connection disruption, and *really* wants to 
> use long-lived sessions, should probably be using PREFER_SRC_PUBLIC anyway.

If the addresses are not used, they will not waste network resources.

The only difference between short and long valid lifetimes is whether 
ongoing ling-lived connections will be aborted or not.

e.g., with RFC4941, a host will typically have one preferred address, 
and 6 unpreferred (but valid) addresses. If there are no long-lived 
connections, the unpreferred addresses will remain configured, but will 
not be employed to send or receive packets. Unless I'm missing 
something, they wouldn't seem to be wasting network resources. OTOH, if 
there *are* ongoing long-lived connections, these addresses would be 
actively used, and require effort from the network.

Keeping a long valid lifetime means that long-lived connections (that 
last more than one day and less than a week) that currently use 
temporary addresses  would survive without problem. Whereas reducing the 
valid lifetime might mean that they are torn down. This "breakage" might 
push such applications to do the right thing and deliberately employ 
stable addresses, albeit with a transition period (when the code is 
updated) where things might break.

In most cases, a valid lifetime of two days will be enough. In other 
cases, the app knows connections are likely long lived, and should 
explicitly opt out of temp-addresses. But there are other cases where 
the nature of the app might lead to using temp addresses, but the 
connection might end up being long lived (e.g. a user downloading a 
large file via HTTP, over a very slow internet connection).

That's my reasoning for wondering if we should really reduce the valid 
lifetime, and whether it results in any savings for the network in cases 
where the addresses are not employed for ongoing connections. (when they 
are, the price the network pays is the price for keeping such 
connections alive).

Thoughts?

Thanks,
Fernando





> 
> On Mon, Feb 10, 2020 at 8:35 AM Fernando Gont <fgont@si6networks.com 
> <mailto: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 <mailto:fgont@si6networks.com>
>     PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
> 


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