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

[Fernando Gont <[e-mail]>]

On 15/2/19 06:40, JORDI PALET MARTINEZ wrote:
> /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.

Of course, nobody would mandate dynamic prefixes everywhere -- in the
same way we don't mandate web servers to run over RFC4941.

That said, where privacy matters, using stable prefixes makes tracking
extremely trivial.

It is not the goal of this thread or our document to mandate any
specific way to build a network. However, you can't just rule out
dynamic prefixes.

And it would be a terrible poor engineering choice (and unapplicable, at
the end of the day) to based network robustness on the assumption that
prefixes do not change. Because for many networks, they do. The cat is
out of the bag already.

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492