Re: Disabling temporary addresses by default?

[Gyan Mishra <[e-mail]>]

On Tue, Jan 28, 2020 at 1:24 PM Mark Smith <[e-mail]> wrote:

>
>
> On Wed, 29 Jan 2020, 06:47 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.
>>
>
> Devices and their end-users that desire address privacy are unlikely to
> have long lived connections.
>
> Can you provide an example of a common long lived connection that would
> occur with a laptop or smartphone? I can't think of one.
>
> Even back in the early 1990s, when fixed location desktops were the main
> personal computing device, long lived client connections were rare. If you
> wanted a reliable long lived connection for something, you didn't use your
> desktop, you used the hosts/servers that were in computer rooms protected
> by UPS.
>
> Gyan> For the home or Starbucks user it would be rare to have long lived
> connections.  Maybe a weekend or all week gaming marathon.
>

   Joking aside, enterprise space is the camp that would have long lived
connections primarily for 24x7 client/server mission critical revenue
generating applications, Point of sale applications, 24x7 Call Centers to
name a few.  I am sure there are many other enterprise scenarios.  Cloud
servers  using Cloud Foundary or Openstack Neutron or any logical
virtualization network layer for server to server communications using
SLAAC.

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