Subject: Re: rfc4941bis: Change to Valid Lifetime of temporary addresses

From: Gyan Mishra <[email-masked]>
Date: Sun, 9 Feb 2020 23:44:06 -0500

On Thu, Jan 30, 2020 at 5:27 PM Fernando Gont <[email-masked]> 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?

   Since we are proposing change of valid lifetime from 2 to 1 why not make
the valid lifetime 1 day as well - same as the preferred.  The historical
deprecated value would not exist and now there would be 1 less address on
the host to troubleshoot.

When you increase the valid lifetime the user can see his previous stare of
the address.  Most users would not be able to understand what is meant by
preferred or deprecated address.  I am not sure what is gained from an end
user standpoint whom most likely will not be network savvy.

Also from a network standpoint the operator for enterprises as well as
service providers save the ND cache for troubleshooting to fire devices
historical data so even if the address changes every day the operator can
determine all the address the host as used during the tracking cycle before
the database rolls over which varies.  Operators have direct access to the
network elements so the ND cache monitoring is at their fingertips.  The
main thing post Snowden era that privacy advocates are concerned about is
address correlation and monitoring done by LFA.   In order for enterprise
or service provider operators to manage the network monitoring is a must as
all links or aggregation points  are tapped so all flows can be monitored.
This is built into the OPEX cost to run a network.  A side effect to that
monitoring is now LFA can obtain FISA warrant for monitoring.  The data is
already present as operators require to save the data for troubleshooting
to provide customer SLA’s.

I think for troubleshooting and MTTR that enterprises require and use a
stable random address for troubleshooting by disabling the temporary
address for the “long lived” flows where the endpoint permanently always
remains in the office connected to the corporate intranet.  So with the new
draft we will still allow disabling the temporary address if desired to
have a stable address.

For enterprise mobile and personal direct internet connection privacy
concerns of address correlation, the temporary address would be enabled by
default and kept enabled as the recommendation. So this use case would use
the temporary privacy address privacy with valid and preferred lifetime
equal set to 1 day.  There would not be any deprecated addresses.

What do you think?

Any downside to doing so?

>
>
> Thanks!
>
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [email-masked]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Feb 2020 04:55:54 -0300

On 10/2/20 01:44, Gyan Mishra wrote:
[....]
>     Comments? Objections?
> 
>    Since we are proposing change of valid lifetime from 2 to 1 why not
> make the valid lifetime 1 day as well - same as the preferred. 

That's bad. That would mean that a connection that is started T seconds
before the address becomes invalid could only have a maximum lifetime of
T seconds.

Put another way, in the worst case scenario where a new connection is
initiated with an address that is just about to become unpreferred, the
maximum lifetime of the connection is ValidLifetime - PreferredLifetime.

> When you increase the valid lifetime the user can see his previous stare
> of the address.  Most users would not be able to understand what is
> meant by preferred or deprecated address.  I am not sure what is gained
> from an end user standpoint whom most likely will not be network savvy.

I don't think anybody expects the user to understand this sort of thing.
It's folks all the way from us to app developers that should somehow
understand something. For users, things should just work.

> historical data so even if the address changes every day the operator
> can determine all the address the host as used during the tracking cycle
> before the database rolls over which varies.  Operators have direct
> access to the network elements so the ND cache monitoring is at their
> fingertips. 

That depends on many factors.

Thanks,

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 10 Feb 2020 09:58:30 -0500

> maximum lifetime of the connection is ValidLifetime - PreferredLifetime.

    Walk me through it as far as end user impact when the address becomes
unpreferred versus deprecated.

 So N = valid 1 day / preferred 1 day = 1 day

As soon as the T time expires for preferred life it would become
unpreferred but not deprecated.

What is the difference from end user standpoint and impact in connectivity
with the address becoming unpreferred versus deprecated?

With existing connections would still be able to use the deprecated
addresses at time T at the preferred expire time or would their connection
be reset and they would have to re-establish on the new preferred address?

If existing connections get reset with 2 day valid lifetime at time T, then
if seems no different then unpreferred which would get reset as well.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Feb 2020 07:22:51 -0300

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Feb 2020 12:36:24 -0300

On 10/2/20 11:58, Gyan Mishra wrote:
> 
> 
> On Mon, Feb 10, 2020 at 4:14 AM Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Walk me through it as far as end user impact when the address
> becomes unpreferred versus deprecated.
> 

unpreferred == deprecated

> What is the difference from end user standpoint and impact in
> connectivity with the address becoming unpreferred versus deprecated?

Both are the same.

> addresses at time T at the preferred expire time or would their
> connection be reset and they would have to re-establish on the new
> preferred address?  
> 
> If existing connections get reset with 2 day valid lifetime at time T,
> then if seems no different then unpreferred which would get reset as well.

Please see RFC4861/RFC4862.

Thanks,

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 10 Feb 2020 19:02:32 -0500

> Please see RFC4861/RFC4862.

Found it

So now I understand what is bad about valid = 1 day which I surmised but
was not sure.  So the bad is the connection would reset immediately and the
address would become invalid once the valid expire time is reached being
the same as the preferred lifetime.  Very bad for any IPv6 user.

My concern is for long lived connections that may exist for enterprise
mission critical applications.  So given the scenario of valid = 2 days and
preferred = 1 day as proposed - once the preferred lifetime expires the
address is deprecated- for en existing long lived connection would continue
to use the deprecated address until the valid lifetime is reached at 2 days
-  at which time the address would become invalid.

The current RFC 4291 valid =7 preferred=1 in that same scenario for a long
lived connection the flow could continue to use the deprecated address
until the valid lifetime expires which is 7 days at which time it would
become invalid and the connection would reset and have to re-establish on
the new preferred address.  The major downside as we have discussed is
limiting the number of addresses on the host which a valid lifetime change
to 2 drastically drops the multiple prefixes from 7 down to 2.  From an
operations perspective even though the 7 day valid lifetime extends life of
long lived but in those cases if we have flows that last that long the
operators can chose to disable the temporary address as a workaround.
Having less addresses is a better choice from an operations perspective
then being able maintain very long lived connections.

https://tools.ietf.org/html/rfc4862#section-5.2

5.5.4 <https://tools.ietf.org/html/rfc4862#section-5.5.4>.  Address
Lifetime Expiry

   A preferred address becomes deprecated when its preferred lifetime
   expires.  A deprecated address SHOULD continue to be used as a source
   address in existing communications, but SHOULD NOT be used to
   initiate new communications if an alternate (non-deprecated) address
   of sufficient scope can easily be used instead.

Note that the feasibility of initiating new communication using a
   non-deprecated address may be an application-specific decision, as
   only the application may have knowledge about whether the (now)
   deprecated address was (or still is) in use by the application.  For

example, if an application explicitly specifies that the protocol
   stack use a deprecated address as a source address, the protocol
   stack must accept that; the application might request it because that
   IP address is used in higher-level communication and there might be a
   requirement that the multiple connections in such a grouping use the
   same pair of IP addresses.

   IP and higher layers (e.g., TCP, UDP) MUST continue to accept and
   process datagrams destined to a deprecated address as normal since a
   deprecated address is still a valid address for the interface.  In
   the case of TCP, this means TCP SYN segments sent to a deprecated
   address are responded to using the deprecated address as a source
   address in the corresponding SYN-ACK (if the connection would
   otherwise be allowed).

   An implementation MAY prevent any new communication from using a
   deprecated address, but system management MUST have the ability to
   disable such a facility, and the facility MUST be disabled by
   default.

Other subtle cases should also be noted about source address
   selection.  For example, the above description does not clarify which
   address should be used between a deprecated, smaller-scope address
   and a non-deprecated, sufficient scope address.  The details of the
   address selection including this case are described in [RFC3484
<https://tools.ietf.org/html/rfc3484>] and
   are beyond the scope of this document.

   An address (and its association with an interface) becomes invalid
   when its valid lifetime expires.  An invalid address MUST NOT be used
   as a source address in outgoing communications and MUST NOT be
   recognized as a destination on a receiving interface.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Feb 2020 01:31:51 -0300

On 10/2/20 21:02, Gyan Mishra wrote:
> 
> 
> On Mon, Feb 10, 2020 at 10:52 AM Fernando Gont <[email-masked] 
>      > On Mon, Feb 10, 2020 at 4:14 AM Fernando Gont
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     >     Comments? Objections?
>      >     >
>      >     >    Since we are proposing change of valid lifetime from 2
>     to 1 why not
>      >     > make the valid lifetime 1 day as well - same as the preferred.
>      >
> was not sure.  So the bad is the connection would reset immediately and 
> the address would become invalid once the valid expire time is reached 
> being the same as the preferred lifetime.  Very bad for any IPv6 user.
> 
> mission critical applications.  So given the scenario of valid = 2 days 
> and preferred = 1 day as proposed - once the preferred lifetime expires 
> the address is deprecated- for en existing long lived connection would 
> continue to use the deprecated address until the valid lifetime is 
> reached at 2 days -  at which time the address would become invalid.
> 
> The current RFC 4291 valid =7 preferred=1 in that same scenario for a 
> long lived connection the flow could continue to use the deprecated 
> address until the valid lifetime expires which is 7 days at which time 
> it would become invalid and the connection would reset and have to 
> re-establish on the new preferred address.  The major downside as we 
> have discussed is limiting the number of addresses on the host which a 
> valid lifetime change to 2 drastically drops the multiple prefixes from 
> 7 down to 2.  From an operations perspective even though the 7 day valid 
> lifetime extends life of long lived but in those cases if we have flows 
> that last that long the operators can chose to disable the temporary 
> address as a workaround.  Having less addresses is a better choice from 
> an operations perspective then being able maintain very long lived 
> connections.

Not sure what you mean. Are you arguing that it's better to reduce the 
valid preferred/valid lifetime, or leave them as in RFC4941?

Thanks,

---

From: David Farmer <[email-masked]>
Date: Tue, 11 Feb 2020 15:46:27 -0600

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

-- 
===============================================
David Farmer               Email:[email-masked]
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
===============================================

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Feb 2020 13:58:52 -0800

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.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 15 Feb 2020 15:06:02 -0300

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 <[email-masked] 
>     e-mail: [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Curtis, Bruce" <[email-masked]>
Date: Thu, 20 Feb 2020 17:25:51 +0000

On Feb 15, 2020, at 12:06 PM, Fernando Gont <[email-masked]<mailto:[email-masked]>> 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.

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 <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
   Folks,
   This is simply a reminder/request for input regarding this proposed
   change.
    >    to override the default value.
   --     Fernando Gont
   SI6 Networks
   e-mail: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
   --------------------------------------------------------------------
   IETF IPv6 working group mailing list
   [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
   --------------------------------------------------------------------

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

Bruce Curtis
Network Engineer  /  Information Technology
NORTH DAKOTA STATE UNIVERSITY
phone: 701.231.8527
[email-masked]<mailto:[email-masked]>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Feb 2020 14:33:09 -0300

Hello, Bruce,

On 20/2/20 14:25, Curtis, Bruce wrote:
>> 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.
> 
> 
>   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.

Thanks a lot for this analysis!

This, together with other arguments made on the list seem to favor 
reducing both the Valid and Preferred Lifetimes.

I will send a stand-alone email to the list just to double-check once 
more before applying the change.

Thanks a lot!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Feb 2020 15:27:31 -0300

Folks,

As discussed before, and also based on recent feedback, I'll be applying 
the following change to the next rev of the document.

This change changes the Preferred Lifetime and Valid Lifetime of 
temporary addresses to 1 day and two days, respectively, thus reducing 
the number of concurrent addresses.

If you have any objections, please speak up.

Thanks!

Cheers,
Fernando

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 21 Feb 2020 15:13:11 -0500

+1  In agreement with the change.

Gyan

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347