IPv6 privacy extensions are defined in RFC 4941. From that I understand that the temporary interface identifier is not only chosen anew when the temporary lifetimes expire, but also when the link changes. RFC 4941 says:
3.3. Generating Temporary Addresses
[...] 3. When a new public address is created as described in [ADDRCONF], the node SHOULD also create a new temporary address.
and
3.5. Regeneration of Randomized Interface Identifiers
[...] Finally, when an interface connects to a new link, a new randomized interface identifier SHOULD be generated immediately together with a new set of temporary addresses.
It says "should", but in essence "should" = "must" unless you have a good reason for not obeying.
Now, playing with the THC IPv6 Toolkit, and in particular with fake_router26, I would expect that if you reset the interface and announce a different prefix, then this is - more or less - a new link. However, neither Windows 7 nor Linux seem to budge, both keep their existing temporary interface identifier.
Am I missing something, or do I have to arrange the experiment differently? Keeping the same interface identifier across various prefixes renders privacy extensions pretty useless...
net.ipv6.conf.enp2s1.use_tempaddr = 2. – countermode Aug 06 '14 at 09:39ip(Linux) andipconfig(Windows). ~ Update for Windows: Deactivating the link entirely and then activating seems to help. – countermode Aug 06 '14 at 09:41