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

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.

On Mon, Feb 10, 2020 at 8:35 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
> --------------------------------------------------------------------
>