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

["Curtis, Bruce" <[e-mail]>]

On Feb 15, 2020, at 12:06 PM, Fernando Gont <[e-mail]<mailto:[e-mail]>> wrote:

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.


There are at least one scenario where unpreferred (but valid) addresses can use network resources.

 In at least one vendor’s implementation of IP Source Guard closet switches keep track of active IP addresses by periodically sending Neighbor Solicitation packets.   So even though there might not be any active connections using an IPv6 address the closet switch will still have info about that IPv6 address (which port it is on and which MAC address is associated with that IPv6 address).  The IP Source Guard feature from this vendor does also include the capability of setting a limit on the number of IPv6 addresses per port.

In at least one vendor’s wireless solution the wireless controller tracks IPv6 Neighbor status in a cache and uses that cache to act as a proxy and reply to Neighbor Solicitation requests with a unicast packet (and dropping the multicast Neighbor Solicitation request so no wireless clients see the Neighbor Solicitation request).  But this particular wireless controller also limits each client to 8 IPv6 addresses. "When the ninth IPv6 address is encountered, the controller removes the oldest stale entry and accommodates the latest one.”   Although unpreferred (but valid) addresses might not use resources in this vendors implementation it is possible that other vendors might implement IPv6 Neighbor Solicitation suppression and proxy in a way that would result in unpreferred (but valid) IPv6 numbers using resources.

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 <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
   PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
   --------------------------------------------------------------------
   IETF IPv6 working group mailing list
   [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
   Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
   --------------------------------------------------------------------


--
Fernando Gont
SI6 Networks
e-mail: [e-mail]<mailto:[e-mail]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Bruce Curtis
Network Engineer  /  Information Technology
NORTH DAKOTA STATE UNIVERSITY
phone: [phone]
[e-mail]<mailto:[e-mail]>