Re: rfc4941bis: Change to Valid Lifetime of temporary addresses

[Fernando Gont <[e-mail]>]

On 10/2/20 21:02, Gyan Mishra wrote:
> 
> 
> On Mon, Feb 10, 2020 at 10:52 AM Fernando Gont <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     On 10/2/20 11:58, Gyan Mishra wrote:
>      >
>      >
>      > On Mon, Feb 10, 2020 at 4:14 AM Fernando Gont
>     <[e-mail] <mailto:[e-mail]>
>      > <mailto:[e-mail] <mailto:[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.
> 
>     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.
> 
> 
> 
>      > 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.
> 
>     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.

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