Re: A common problem with SLAAC in "renumbering" scenarios

[Ole Troan <[e-mail]>]

> On 17 Feb 2019, at 21:05, Manfredi (US), Albert E <[e-mail]> wrote:
> 
> From: Tom Herbert <[e-mail]> 
> 
>> That technique is easily defeated by "always connected" applications. After an address change, the application logs into the server and the server logs identity, address, and a timestamp. Then it's just a matter of applying the server logs to infer identities in unrelated traffic 
>> 
>> Increasing frequency of address change might make it a little harder to track users, but I think it's mostly a false sense of security in reality. If a user really cares about privacy they want single use untrackable addresses.
> 
> Agreed, Tom. But that only strengthens the point that going to great lengths to make IPv6 prefixes stable, when we've spent so much time doing the opposite with respect to the IID, seems self-contradictory. It seems more productive to fix whatever breaks, when the prefix changes. For instance, Fernando's points about SLAAC timers. That should be the main focus of the IETF, IMO. Ensuring permanent prefixes should be the odd exception, done with more or less extraordinary measures.

Lifetimes become quite useless, when the promise made with them is broken. They only serve then for garbage collection. 

If your model of networking is dynamically changing addresses, then don’t you need a rendezvous point for all inbound communication anyway? Guess then you will not have much benefit from a 128 bit address space either. 

Ole



> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------