# Ephemeral Node Identifiers for Enhanced Flow Privacy
## 3 Method and Implementation
### Implementation in IPv6  
Support for eNIDs was built as an extension of the existing support for ILNP in FreeBSD14 [17]. Compared to NIDs, eNIDs require new mechanisms to generate NID values, allocate them to sockets, and expire them once used. In all other respects, eNIDs function like regular ILNP NID values. That is, with respect to the discussion in Section 2.2, only the lower 64-bits of the IPv6 address (used for the IID in IPv6) need to be generated dynamically for each flow. Ephemeral NID values are generated randomly using the same method as for IPv6 TA-SLAAC [6]. As with TA-SLAAC, eNIDs are generated before use so that IPv6 Duplicate Address Detection (DAD) [25; 26] can be completed before the NID is required. In order to facilitate the initiation of multiple communication flows in short succession, a pool of available eNIDs can be maintained. The necessary size of this pool depends on both the expected workload of the node, and various other tunable parameters such as maximum retransmissions for DAD, so this can be configured by a user via the sysctl API [27]. ILNP already tracks which NIDs are in use in order to facilitate dynamic updates of location information. eNIDs further utilise this information to track which NID values have been allocated to a socket, so should not be reused, and which are associated with closed sockets, so should be discarded. IPv6 does not have a convenient way of checking if IID value are in use by an active transport flow, which causes performance issues for use of TA-SLAAC. The state management for eNID values for ILNP are summarised in Figure 3 and Table 2.  
From an application's perspective, using eNIDs is no different to using a single, static NID under ILNP, or using a single static IID for IPv6--the application only needs the NID/IID value to remain stable for the duration of a transport layer flow. The use of ILNP is also transparent, with IPv6 applications able to use ILNP's enhanced functionality just by running on an ILNP-aware operating system. So, no changes to existing applications or socket APIs were necessary. Figure 2: Expected behaviour of \(P_{f}\) against different attackers as \(f\) increases. \(P_{f}\) is shown on a log scale. If the attacker clusters all flows into a single group associated with the same identity, \(P_{f}\) will approach zero, as shown in red. When the attacker is able to cluster some—but not all—flows, \(P_{f}\) jumps up whenever \(c\) increases (i.e., a new cluster is created) then gradually decreases as more flows are included in that cluster, as shown by the various blue traces. If the attacker is forced to create a unique cluster for each flow, as shown in green, \(P_{f}\) will be constant at 1. (Lines connecting points are a visual aid. )As with IPv6, the operating system eventually frees all socket structures, either when the flow terminates correctly, or when an error in the parent application process causes it to be killed. The expiring of an eNID value is tied to this mechanism, ensuring that the eNID value is not removed while still in use, but is removed as soon as possible. This also allows the node to immediately stop responding to Neighbour Solicitations for that eNID, reducing the costs to the local network when compared with TA-SLAAC. For simplicity, compatibility, and ease of implementation, generation of eNID values can use the same methods as used for generating IID values for TA-SLAAC. The TA-SLAAC specification [6] gives guidelines that are used for generating IID values in two different ways:  
* simple generation of pseudo-random values with randomness requirements and properties as already agreed by the wider Internet community [28];
* generation of probalistically unique pseudo-random values based on functions that take various input parameters, so that existing IID generation functions (such as those used for SO-SLAAC [10]) can be re-used;  
Our implementation used the first mechanism to generate eNID values. However, the management of eNID values differs from the TA-SLAAC specification with respect to: