There was an old way of generating Interface IPv6 address using SLAAC process (Stateless autoconfiguration). You simply configured that you want SLAAC autoconfiguration and the interface IPv6 was generated by squeezing “FFFE” in hex (11111111 11111110 bits) between two parts of physical MAC address of that interface.
Then, after a while, several comments came to IETF about the use of predictable Interface Identifiers in IPv6 addresses. They were pointing to the ease of correlation of host activities within the same network and across multiple networks. If Interface Identifiers are constant across networks this is negatively affecting the privacy and security of users on that network.
Security, why is this affecting security?
By using a link-layer address in the Interface Identifier which was the case in RFC2373 (Described in one of my old articles here), you can easily correlate users on the network, shrink scan search space when attacking a segment or even get to the device type and vendor ID of the machine when scanning the IPv6 addresses on the segment. Another issue was the change in IPv6 address when reconfiguring L3 EtherChannel with new member interface or when replacing faulty NIC.
This new RFC 7217 solves several issues from RFC 2373 and RFC 4291 and enable the creation of Interface Identifiers that are stable for each network interface on the subnet and change when a host moves to some other network enhancing user privacy and security. This RFC also solves the issue of temporary and randomly generated IPv6 addresses for usage with outgoing connections but still using MAC generated ones (multiple IPv6 address per interface), for incoming connections from RFC 4941 which solved user privacy but not other scan attack issues.
New SLAAC EUI-64 algorithm
So, the new way of generating IPv6 with SLAACK does it like this:
It will change the interface identifier if the autoconfiguration prefix changes (host move) and it will use the algorithm to always generate the same interface identifier if the autoconfiguration prefix does not change (host within the same subnet).
This algorithm must be something like “modulo n” (a pseudorandom function) to be sure that it is difficult or impossible to predict the network identifier of other hosts even if you know it for some other hosts in the same segment.
The algorithm specified to do all of the above will take info calculation several attributes like Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key in order to get a stable identifier across subnet.
In order of appearance:
A prefix is the ICMPv6-Router Advertisement message learned IPv6 prefix configured on Default Gateway segment border device (router, firewall).
Net_Iface is used to be sure that the identifier will not change after NIC changes or reinstalls of OS happen
Network_ID will be used to be sure that the identifier changes when we move to some other segment.
DAD_Counter will make sure that the different IPv6 addresses will be generated even if all other attributes are the same.
secret_key is the additional attribute which should be at least 128 bits pseudorandom number not known to the attacker.
As you can see, now it is not possible for me to give you a plain and simple example of SLAAC interface ID generation like the one here that shows the old way. SLAAC algorithm will now differ from vendor to vendor and mostly on how will they use the RFC 7217 to implement the pseudorandom function and pseudorandom secret_key generation algorithm.
There is another new RFC 8064 which strongly suggests using RFC 7217 in new network device OS and it is strongly against the usage stable link-layer addresses in IPv6 interface identifiers. As from this RFC it formally updates all this bunch of docs: RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121.