Re: rfc4941bis: Change to Valid Lifetime of temporary addresses

[Gyan Mishra <[e-mail]>]

On Mon, Feb 10, 2020 at 4:14 AM Fernando Gont <[e-mail]> wrote:

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

    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.

>
>
>
> > 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.
>
>
> > 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.
>
> That depends on many factors.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]