# Ephemeral Node Identifiers for Enhanced Flow Privacy
## 2 Background
### Defence of Identity Privacy  
These attacks exploit the IID of an IPv6 endpoint to compromise identity privacy. They key to disrupting this attack is therefore found in the management of IID values. Existing mechanisms to generate and manage IID values do not always have privacy as an objective, but can have, or are perceived to have, privacy benefits.  
Typically, an IID is generated using Stateless Address Auto-Configuration (SLAAC) [8], the default mechanism for the original IPv6 specification. While the Dynamic Host Configuration Protocol (DHCP) can be used with IPv6 [9], SLAAC is the recommended approach, and the starting point for most privacy-focused innovations. It provides dynamic address management with zero administrative overhead, but was not designed for privacy--SLAAC IIDs are fixed, being derived from hardware values, such as the 48-bit values found on network interface hardware. IIDs generated in this fashion can therefore be used to correlate all flows to a particular device _for the lifetime of that device_ and _across different networks globally_.  
Figure 1: The IPv6 address format is shown (top), which has an interface identifier (IID). The ILNP Identifier-Locator Vector (I-LV) format has the same structure as an IPv6 address. An ILNP Locator has the same syntax and semantics an an IPv6 routing prefix, so ILNP packets are routed and forwarded in the same way as IPv6 packets—they look like IPv6 packets ‘on the wire’. The ILNP Node Identifier (NID) has the same syntax as an IPv6 IID, but has different semantics, as it identifies a _node_ instead of an _interface_.  
Semantically Opaque SLAAC (SO-SLAAC) modifies SLAAC's IID generation method to remove the trackable semantics [10]. IIDs are instead generated by a hash of various values, including a software-defined secret key, and an identifier for the local network. This results in an IID that is stable for a particular node on a particular network, but will change if the machine is moved to another location, or if the secret key is changed.  
While stable IIDs are convenient for some administrative purposes, stronger privacy guarantees can be achieved with Temporary Address Extensions for SLAAC (TA-SLAAC a.k.a. _temporary addresses_) [6]. When using TA-SLAAC, IIDs are generated as pseudo-random values with no semantics, and are periodically expired and replaced. TA-SLAAC uses two parameters, TEMP_PREFERRED_LIFETIME and TEMP_VALID_LIFETIME, to control, respectively, the time that a generated IID is usable by a node, and the time for which it is still considered valid even after it is no longer available for use by a node, e.g., if it is used in long-lived flows. So, a single IID value is used for all outbound communication during the configured period (24 h by default) before becoming deprecated, but is maintained beyond this period to avoid disrupting ongoing communications.  
Periodically cycling through IID values means an attacker cannot correlate flows using a new IID with flows using a previous value. This places a _temporal_ limit on tracking, but does not stop an attacker tracking devices _literally_, by spotting simultaneous flows using the same IID within the timeframe before that IID is expired.  
Although desirable for privacy, TA-SLAAC IID values face an operational challenge: they cannot be expired efficiently, as the operating system is not aware of which IIDs might still be in use. As a result, deprecated IID values must be maintained for an extended period (several days) to avoid disrupting long-lived flows. This is an additional overhead for the local network, as it requires each node to maintain a larger pool of addresses, resulting in more Neighbour Discovery Protocol (NDP) traffic and larger NDP tables. Efforts to reduce these costs are an area of ongoing research [6].