Re: Disabling temporary addresses by default?

[Gyan Mishra <[e-mail]>]

On Tue, Jan 28, 2020 at 12:46 PM Gyan Mishra <[e-mail]> wrote:

>
>
> 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.
>
>>
>> This operational impact issue with the temporary address changing for
>> long lived sessions  actually existed as well with DHCPv6 with  server
>> redundancy when state sharing did not exist and required a split scope
>> configuration.
>
>
Now with DHCPv6 failover protocol for redundancy the same scope can be used
between servers as stare sharing now works.

DHCPv6 failover protocol
https://tools.ietf.org/html/rfc8156


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

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]