# Securing IPv6 Neighbor Discovery Address Resolution with Voucher-Based Addressing
## 4 Results  
A testing laptop was used to generate a set of VBAs for each VBA Algorithm Type option and to evaluate the time taken by each KDF algorithm for each input iteration count. The laptop was used during a fully idle state, running the Windows 11 operating system. It was equipped with a 12 th-generation Intel(r) Core(tm) i7 processor, 32 GB of DDR4 RAM, and a GeForce RTX(tm) 30 Series GPU. The testing hardware is useful to know but is not particularly important, however, because all the results are relative to one another. That is, since all the tests are performed on the same device, their relationships will manifest similarly to how they would across other hardware. With a partial VBA generation implementation written in C, based on the procedure from Section 3.4, an experimental application spawns VBAs on-the-fly based on any set of dynamic or precompiled parameters. Using the minimal KDF work factors (i.e., iteration count values) for each default algorithm, Figure 10 shows a mostly linear trajectory for the results of each test. As expected, an increase in the input iteration count value is linearly associated with the time taken to compute the resultant VBAs. Deviations in the graph are realistic and spurious events generated by an active CPU on the testing laptop switching between various scheduled tasks through the underlying operating system. Even though the results of the graph are not aggregate statistics, the relationships between the data and their interdependencies demonstrate how VBA might perform in a real-world application. To emphasize a key point: any degree of hardware resources should manifest the same relationships between these three default VBA KDFs per Figure 10.  
Argon2 key derivation is highly preferred as the default Algorithm Type for VBA Link Vouchers because its minimal baseline settings produce a memory-bound KDF requiring relatively little time to compute addresses. This grants Voucher Beaers a simple origin when determining the desired level of the baseline computational difficulty for VBA generation on the local network. Both PBKDF2 and Scrypt share a similar baseline relationship with the iteration count used: about every 20-25 thousand additional required iterations result in 5 more milliseconds of computation time during address generation and verification. These two KDFs intentionally follow a similar progression with minimal difficulties because PBKDF2 is a CPU-bound KDF while Scrypt is a memory-bound KDF. Keeping these two minimal baselines close will allow implementations to choose from a similar baseline difficulty for each type (memory-bound or CPU-bound), and to make further determinations from that pattern. It should be noted that the Scrypt KDF's linearity slightly tapers into a gentle curve at higher iteration count values. The reason for this fall-off is unclear but it does little to affect any projections of minimal baseline computation times. Beyond the results in Figure 10, the same hardware was used to evaluate the individual relationships between work factors at an arbitrarily high difficulty for each KDF. The results from Figures 11-13 should not be used to compare one algorithm to another, as each algorithm's \"high\" difficulty setting was chosen independently from the others. Instead, the results are intended to demonstrate how much computing time a considerably high cost for each algorithm might require during generation and verification processes in relation to individual, node-selected work factor values. The input iteration count values selected during each VBA generation can widely change the aggregate cost of securing an address on the network, whether advantageous or not. Importantly, selecting the iteration count is in the control of the VBA-generating node. Neighbors who wish to ensure the legitimacy of a received LL2 IP binding will be expending the same, symmetric amount of time and energy to verify the binding.