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

/64 for every device is perfectly possible and I think it is wise, following RFC8273, so VMs inside a device can have their own addresses.

I see a scenario where (and I don't care if it is a residential or enterprise), a single persistent (unless the user explicitly wants it non-persistent) /48 is provided to the CE.

Then the CE can organize the /48 in different subnets. For example, devices (sensors that just report data), will get persistent or non-persistent /64s. Actuators (you need to talk to them, so you may want to have persistent addresses in the DNS), will get persistent /64. End-user devices (tablets, laptops, etc.), will have persistent or non-persistent /64s and finally, of course, if you have servers, you want to have the with persistent /64s.

I know everything could be non-persistent using dynamic DNS, but this is expensive, is extra services, and it is slow. I don't think it make sense for stable services.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <ipv6-bounces@ietf.org> en nombre de Jan Zorz - Go6 <jan@go6.si>
Fecha: viernes, 15 de febrero de 2019, 10:30
Para: Christian Huitema <huitema@huitema.net>, <ipv6@ietf.org>
Asunto: Re: A common problem with SLAAC in "renumbering" scenarios

    On 15/02/2019 08:57, Christian Huitema wrote:
    > 
    > On 2/14/2019 1:19 PM, Jan Zorz - Go6 wrote:
    >>
    >> To augment what many already have said here - it's a tie between IP
    >> address and household address and name/surname that should not be
    >> public, the address itself is mostly harmless and it doesn't matter if
    >> it's static or dynamic. Tracing gets done on L7 and above anyway ;)
    > 
    > 
    > In the current state of the web, if a user gets a new address, the
    > various web surveillance mechanisms will associate it with the previous
    > user identity and context after maybe a dozen web queries or two. That
    > gets better if the user has a strong defensive posture, blocks web
    > trackers, etc. But it just takes one cookie, or one login, or some other
    > inference, and poof, the surveillance databases know that new_address_X
    > is the same user as old_address_Y.
    > 
    > The case of the household is even worse. It takes only one cookie,
    > login, etc, and the surveillance databases will learn that new_prefix_P
    > is the same household as old_prefix_Q. Even you run Ghostery or Privacy
    > Badger or the latest release of Firefox, you won't escape if you share a
    > prefix with someone in your household who doesn't. Or with one of those
    > surveillance devices that masquerade as thermostats or light switches or
    > voice assistants.

    Exactly.

    > 
    > So that's pretty bleak. If you want defense, you probably want to
    > allocate different /64 prefixes to different devices, and change them
    > really often. You may not need to change them for every devices -- no
    > point providing privacy to the surveillance thermostat. But for your
    > laptop, your tablet or your phone, they to change before the
    > surveillance advertisers see you access a dozen web pages or two.

    /64 for each device is fine. What I'm questioning is if we really need 
    to make underlying to be something that was never meant to be if L7 and 
    above is broken? I think L7 and above needs to be fixed first and then 
    changing of addresses in transport layer can have any effect. Until then 
    - let's transport packets in a way that doesn't break often and make 
    user grumpy.

    To put "lipstick on a pig" is a rhetorical expression, but quite useful 
    in our case :) :) :)

    Cheers, Jan

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.