Re: Disabling temporary addresses by default?

[Gyan Mishra <[e-mail]>]

On Tue, Jan 28, 2020 at 12:11 PM Fernando Gont <[e-mail]>
wrote:

> On 28/1/20 13:27, Christian Huitema wrote:
> >
> > On Jan 28, 2020, at 6:59 AM, Lorenzo Colitti <lorenzo=
> [e-mail]> wrote:
> >>
> >> Instead of disabling, why not change the default of the number of
> addresses maintained? For example, instead of maintaining 1 permanent + 1
> valid + 7 deprecated, why not just default to maintaining 1 permanent + 1
> valid + 1 deprecated. That means that applications would have to
> re-establish their connections once a day instead of once every 7 days. But
> if they use privacy addresses, they already need to re-establish
> connections after 7 days. And they can always use not to use privacy
> addresses via the appropriate socket option.
> >
> > That seems plausible, but how about going one step further and for
> clients just have one temporary and one deprecated address, without any
> stable address? If the client is not running any server, that makes address
> management much simpler.
>
> rfc4041 bis already allows for that.
>
> The only thing is that if the Preferred Lifetime is 1 day, and Valid
> Lifetime is 2*Preferred Lifetime, and you only do temporary addresses,
> then your sessions (e.g. SSH) cannot span past one day, *unless* we
> recommend that invalid addresses are still okay for established
> connections.



   The main reason this topic comes has up is due to possible impact of
usage of the temporary address when it gets deprecated with long lived
session.  That’s the crux of why this topic is critical and has severe
operational impact. When the address changes for long lived connections
from the deprecated temporary address to the new preferred address, the
session would terminate and have to re-establish, which is impacts the
user.  Maybe a change to the behavior as how this works is that the long
lived flow remains active on the deprecated temporary address indefinitely
until the flow is terminated via graceful TCP close.  This would allow us
to maintain privacy extension temporary address enabled by default change
to benefit privacy advocates and also eliminate impact for enterprise users
where availability and stability is utmost importance.  The second issue is
maintaining of a multiple addresses on the end host from an operations
perspective if that can be limited.  One idea to accomplish this is that if
the privacy temporary address is enabled by default, that is if we are able
to resolve the operational impact of long lived sessions when the temporary
address changes - how can we minimize the number of active addresses per RA
slaac address.  Allow the interface stable random address to be active only
if the temporary privacy address is disabled - non default scenario.   Once
the temporary address is enabled default scenario- and preferred, it is now
used for both incoming and outgoing connections and the interface “stable”
random address is now disabled.  This will help from an operations
perspective that all flows in/out now all use the same privacy address.  We
can limit the number of temporary addresses to 2 which would only occur
during transition to the new preferred address.  In a normal state when the
address has not hit the lifetime expire timer, only a single GUI address
exists on the host plus the link local.

>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: [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
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]