# Ephemeral Node Identifiers for Enhanced Flow Privacy
## 3 Method and Implementation
### Use by Existing IPv6 Applications  
For transparent use in existing IPv6 applications, the aim was to allow existing applications that use IPv6 to be able to use eNIDs without modification or recompilation. In FreeBSD, name resolution is performed by libc via the getaddrinfo function [31]. The expected programming API call pattern for a client, for example, is:  
1. make a call to getaddrinfo[31] to resolve a name to an IP address;
2. create a socket[32] for a communication endpoint;
3. and connect[33] to the address using the socket. This implementation therefore assumes that any attempt to connect to an ILNP-capable host will be immediately preceded by an attempt to resolve the name of that host. As name resolution is performed by a library and not the application itself, the function can be patched without disrupting programs that use it. Note that while our example is in C, most of the popular programming languages in use today are built on C and use the main C library, libc, (e.g., Python, Rust, Java, Javascript, Go, etc.). The process of name-resolution using getaddrinfo first checks for entries in /etc/hosts[34], so the implementation was patched to handle ILNP entries in /etc/hosts, the format for which are shown in Figure 6. Like IPv6 addresses, the textual representation of I-LV values splits the value into two-byte character groups. Unlike IPv6, no shorthand (:) is supported--all character groups must be explicitly stated, although leading zeros may be omitted, provided at least one digit is given. The '-' (minus) character is used as the separator in L64s, and the '+' (plus) character in NIDs, with the two values being separated by a '.' character. This is all to avoid ambiguity in use of IPv6 addressing vs ILNP addressing. Note that while ILNP also does have Domain Name System (DNS) records defined and supported in DNS server software [35], for our evaluation, we chose to use local modifications in /etc/hosts. This allowed the creation of a self-contained experimental Testbed, which is also more easily reproducible, and removes a variable from evaluating any protocol-level behaviour for our evaluation (no need for DNS servers and DNS communication). For the modified use of /etc/hosts, within libc, the modifications made to the processing for a name resolution are shown in Figure 7.  
Figure 6: An example /etc/hosts entry. a.ipv6.example is an IPv6 host with the normal IPv6 syntax. a.ilnp.example is an ILNP host using the new syntax. The address of a.ipv6.example and the I-LV of a.ilnp.example correspond to the same value—both names refer to the same host, but using different protocols. The different syntax in the /etc/hosts flags the use of ILNP, and so the creation of an ILNP-capable socket.ietf118-server-ipv6 is the IPv6 address of the server machine used for the Global IPv6 test (as shown in Figure 5), and the final entry above, for ietf118-server, is the equivalent ILV for the server for ILNP. In short, any existing application can use ILNP and the eNID mechanism _transparently_. This means that existing applications benefit from the use of eNIDs without requiring any re-design, re-engineering, or even recompilation--existing program binaries that use IPv6 will gain use of eNIDs directly and immediately. Unmodified program binaries were used both in the Testbed network (Section 3.3.1) and the Global network (Section 3.3.2) evaluation. The list of software is given in Table 3.  
In short, any existing application can use ILNP and the eNID mechanism _transparently_. This means that existing applications benefit from the use of eNIDs without requiring any re-design, re-engineering, or even recompilation--existing program binaries that use IPv6 will gain use of eNIDs directly and immediately. Unmodified program binaries were used both in the Testbed network (Section 3.3.1) and the Global network (Section 3.3.2) evaluation. The list of software is given in Table 3.