Sergey Nivens - Fotolia
Editor's note: This tip is part two of a two-part series on IPv6 security and privacy. Part one examines the Internet Engineering Task Force's new set of standards in RFC 8064, or "Recommendation on Stable IPv6 Interface Identifiers," and looks at the use of RFC 7217 for the generation of stable IPv6 addresses.
The simplest way to infer that a node is employing the algorithm from RFC 7217 is by inspecting the configured IPv6 addresses: for IEEE 802.3 and IEEE 802.11 network interfaces, the traditional algorithm for generating stable addresses with stateless address auto-configuration always results in addresses that contain the 16-bit hexadecimal word 0xfffe. Thus, an IPv6 address that contains the word 0xfffe in the fourth and fifth bytes of the interface identifier can be reasonably assumed to have been generated with the traditional algorithm, while an IPv6 address that does not include that word can be assumed to have been generated with the algorithm specified in RFC 7217.
A more concrete test can be performed as follows.
First, connect the node to one IPv6 network and check the interface identifiers being employed for the global IPv6 addresses.
In this scenario, the global IPv6 address being configured is fc00:1::e17:cbfb:392d:a9dc, and the interface identifier is e17:cbfb:392d:a9dc. We can clearly see that the interface identifier does not contain the word 0xfffe.
Second, connect the same node to a different IPv6 network and check the corresponding IPv6 addresses and interface identifiers.
In this case, the IPv6 address is fc00:2::48a0:c116:8a8:ec56, and the interface identifier is 48a0:c116:8a8:ec56. This interface identifier is different from the one employed for the previous network, since this network employs a different IPv6 network prefix (the Net_Prefix parameter employed in the algorithm).
Third, connect the same network interface of the same node to the original network.
As expected, the resulting IPv6 address and interface identifier are the same as when the node was connected to this network for the first time.
Operation and management considerations
For obvious reasons, legacy systems not implementing RFC 7217 that are reinstalled with a new release of an operating system that implements RFC 7217 can result in different IPv6 addresses, as a consequence of switching from the traditional algorithm to that specified in RFC 7217.
Another consideration is that, when it comes to the traditional algorithm for generating stable interface identifiers, replacement of a network interface card typically results in IPv6 address changes, since the underlying link-layer address is embedded in the IPv6 address.
However, in the case of RFC 7217, replacement of a network interface card need not result in an address change; an implementation that employs the interface name (e.g., eth0) for the Net_Interface parameter would not unnecessarily result in IPv6 address changes upon replacement of a network interface card -- this is indeed an extra feature of the algorithm.
Finally, it should probably be obvious that stability of the configured IPv6 addresses greatly depends on the stability of the Secret_Key parameter. Most RFC 7217 implementations enable an administrator to view and manually set the Secret_Key parameter employed by the algorithm. An administrator willing to replace or reinstall an existing system, but who continues to employ the same set of IPv6 addresses, should record the Secret_Key parameter employed by the original system and manually configure this parameter with the recorded value in the freshly installed system. The specifics of configuring this parameter vary from one implementation to another, and the user should consult the corresponding manual pages.
It is expected that RFC 7217 won't be enabled as part of the normal system update process (such as apt-get update;apt-get upgrade in Ubuntu), but only enabled in release upgrades or fresh installs. However, since this is an OS-specific choice, network and system administrators should be aware that the possibility exists that this situation might happen, and thus take appropriate actions where necessary, such as updating the necessary Access Control Lists.
The recently published RFC 8064 has essentially replaced the traditional algorithm for generating stable IPv6 addresses with SLAAC with one that has improved security and privacy properties. The new algorithm is effective for mitigating both host tracking and address scans. During the process of upgrading legacy systems to new OS releases that implement this algorithm, IPv6 address changes may occur as a result of switching from the traditional algorithm for generating stable IPv6 addresses with SLAAC to the new algorithm specified in RFC 7217.
Learn how threat intelligence can be used in your company
Find out how to mitigate the threat of IPv6 neighbor discovery attacks
Check out some ways to protect your IPv6 address management