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

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
===============================================