# Securing IPv6 Neighbor Discovery Address Resolution with Voucher-Based Addressing
## 3 Voucher-Based Addressing
### Address Generation and Verification  
To gain further advantage, this work elevates simple hashing techniques to the use of key derivation functions (KDFs; see Table 1), enabling a set of one-to-many LLZIP bindings and enforcing a minimum address computation time. KDFs accept input iteration values specifying how many times the driving pseudo-random function (or underlying hash function) must be iterated before producing a final result. In VBA generation, various inputs that specifically identify the target node, as well as the chosen iteration count, are computed by a known KDF into a hash value. The input iteration count is then obscured and planted into the generated VBA adjacent to a slice of the resultant hash such that the following three components are an inherent value exchanged by any NDAR transaction: (1) the target's reported LILD and IP address (i.e., VBA itself); (2) a portion of the KDF's hash output (embedded within the VBA); and (3) the iteration count that was supplied when computing the KDF hash (also embedded within the VBA). Interfaces using the VBA generation procedure during SLAAC, therefore, enforce that all three aforementioned items are bound together and conveyed to neighbors, alongside on-link voucher details, to produce the same output VBA during verification. Each increment or decrement of the iteration count value produces an entirely new, seemingly random address with no correlation to another VBA produced from a different iteration count value. Nodes falsifying any information during the NDAR process will be denied communication with enforcing neighbors who cannot successfully verify the illegitimate bindings. VBAs are composed of three key components in order from the most-significant to least-significant byte: the 64-bit subnet prefix, a 16-bit \(Z\) value indicating the encoded iteration count (L) used to compute the address, and a 48-bit hash-derived address suffix (H). If the subnet is less than 64 bits in length, then the remaining gap between the end of the subnet prefix and the beginning of \(Z\) is always populated with pseudo-random noise by the generating node. VBA generation is not compatible with networks whose subnet prefixes exceed 64 bits in length. A VBA contains only a partial conveyance of the information required for neighbors to reconstruct and therefore verify the address binding. Figure 3 provides a simple visual representation of how an IPv6 address is partitioned. The interface identifier for all the VBAs, also called the suffix, embeds two important details for verification. A 16-bit \(Z\) value is calculated as a bitwise complement of the XOR of the 16-bit L value (the iteration count used in the KDF function K) and the first hextet (a 2-byte, 16-bit unit of data) of the current voucher seed value. The \(Z\) value is used to ensure that the same input iteration count value, L, will be unique across different voucher seeds to provide enhanced address privacy. Figure 3: The overall structure of a Voucher-Based Address. The L value is a significant member of the generated VBA: this parameter controls how many times the KDF function specified in the voucher is iterated to produce the resulting hash value from which H is derived. Increasing this value increases both the work required to verify the VBA and the work necessary to discover potential collisions with H. H is the other value embedded in the VBA which consists of 48 bits acquired from computing the resulting KDF function with L iterations. The first 8 bytes of the resultant KDF hash are used in formulating the suffix of the VBA, where its first hextet (bytes 1 and 2) is replaced with the Z value as shown in Figure 4.  
The address generation algorithm depicted in Figure 4 is detailed procedurally as follows:  
1. A node connects to a network and discovers link VBA compatibility from a Link Voucher option obtained upon router solicitation. 2. The local L value is chosen based on (1) node preference, (2) intended VBA difficulty, or (3) random selection.