# Ephemeral Node Identifiers for Enhanced Flow Privacy
## 5 Discussion
### Use of eNIDs at the Server Side  
Our focus in this paper has been on providing client-side flow privacy--flows generated by a client cannot be correlated when eNIDs are used. However, there are possible security benefits in using eNIDs at the server-side to protect either an individual server or a set of servers providing a service. There are at least two significant challenges to assess when considering use of eNIDs at the server-side:  
1. the scalability of the use of eNIDs;
2. the need for interaction with the Domain Name System (DNS) service. For the first point, a client system using eNIDs might typically have several tens of flows concurrently in use, and so several tens of eNIDs/ILVs/IPv6 addresses. Possibly, a particularly active client could peak at have a few hundred concurrent flows, and therefore perhaps few hundred eNIDs/ILVs/IPv6 addresses. There is no definitive study on such numbers, and they depend on the client's application behaviour and user activity. However, a server system might have many hundreds, thousands, or several tens of thousands of concurrent flows, and so a matching number of eNIDs/ILVs/IPv6 addresses in use. For the second point, the norm is to use addresses that are easily discoverable by clients via the DNS by looking up a fully-qualified domain name (FQDN) for a server or service. For technical and administrative convenience, IPv6 addresses that are held in the DNS are typically _semi-permanent_, usually configured through some sort of (human-controlled) administrative process, and not _ephemeral_, automatically generated on demand. So, if eNIDs are to be used for application servers, there is likely to be need for some coordination between the application server and the DNS service--a DNS-application interaction. Coupled with the first point above, this DNS interaction could be significant, and could impact performance of the service overall, e.g., by increasing the latency when establishing connections. This creates two considerable challenges for the use of eNIDs at the server-side. So, such usage is likely to be constrained to those cases where the cost of implementation of server-side eNIDs is considered acceptable compared to the benefit that is provided. Overall, from a scalability and performance perspective, use of server-side eNIDs is likely to be restricted to smaller scenarios, such as for a small enterprise network or campus network. We do not enumerate here all potential uses cases for eNIDs at the server-side, but highlight one particular possible use case which demonstrates the potential utility of eNIDs for an individual server or a service--an address-based capability system for access control and prevention of traffic-based DoS attacks. Our use case in this discussion is based on previous studies that proposed the use of capabilities [51] for access to services, but based on the use of dynamically generated addressing information [52]. A simple scenario for the use case is shown in Figure 9.  
When Client, C, wants to contact to Server, S, it generates a name-lookup for the FQDN of S via the DNS, as normal. The server or service providing DNS name resolution for S is denoted by the DNS server, D, which has been modified to generate eNID values for S. When D sees a new client request, it generates a new eNID value, \(e\)_1_, to return in the DNS response to C. At the same time, it notifies both F and S of the value \(e\)_1_, so that they can both expect an incoming TCP connection using value \(e\)_1_ in the NID/IID portion of the destination address in the IPv6 packet header. Figure 9: A possible scenario for using eNIDs at the server for preventing DoS attacks by using eNIDs as a capability—a simplified depiction to show the main features.