# Securing IPv6 Neighbor Discovery Address Resolution with Voucher-Based Addressing
## 5 Discussion
### Sintplicity, Privacy, and Flexibility  
As the original goals of this research stated, the introduction of Voucher-Based Addressing aims to satisfy three core ideals: simplicity, privacy, and flexibility. In this brief section, the work of this research will be fairly evaluated against these ideals to determine its adoption potential. A justification is fairly provided to explain why simplicity, privacy, and flexibility are indeed goals achieved by VBA in practice. Simplicity is key to drawing audience attention to a protocol or idea; complexity can be understandably intimidating. The solutions of the past which have found themselves too complex or difficult to implement have been buried by the sands of time and relegated to a purgatory of only academic citations and no concrete manifestations. VBA is a simple scheme because it does not require huge, mandatory impacts on NDP that cause disruptions in the network or at the node-to-node level. With a mixture of Interface Enforcement Mode selections, a broadcasted Link Voucher option, and already-present details about a node, addresses can be generated and verified using a procedure that is easy to follow and implement. The address verification shim process is a small snippet of the software that carries the entire weight of VBA. It is modifiable with one simple per-interface setting (the IEM). Figure 14: A mixed local network is shown where a single valid Link Voucher is delegated to VBA-capable neighbors. Neighbors without VBA capabilities are shown in blue, and VBA-aware neighbors are shown in red, orange, yellow, and green for the IEMs AAD, AGO, AGVL, and AGV, respectively. Different links are shown between some hosts to indicate their connectivity and security within this transitioning network. Inbound traffic to verifying nodes is generally considered secure. Privacy is important to establish properly and consciously in proposals that determine the unicast generation of interface IP addresses, whether local or global in scope. It is also an afterthought of many proposals and research which might be elegant and practical otherwise. It is important to understand that \"privacy\" in this regard does not beget the confidentiality of data from prying eyes; rather, it affords protection against target identifiability over the course of time. VBA manifests privacy in its ability to generate disposable, deterministic, outwardly pseudo-random addresses while still providing enough information for on-link neighbors to reconstruct and validate them. VBAs have no flags or other magic values which indicate that they are VBAs, further adding to their obscurity. The VBAs assigned to a local interface stem from a one-to-many pairing of the interface LLID to its assigned output address(es) coupled with a set of node-selected iteration count values. This means a node is free at any time, even if the voucher parameters have not changed, to choose a new interface identifier which shares no correlation to another chosen iteration count, defeating any address tracking or activity correlation concerns between the addresses. Since the iteration count values are selected over the entire 16-bit spaces they may occupy, they become indistinguishable from any otherwise random 16-bit integers and data. Furthermore, the use of a consistent iteration count selection across subnets and networks still results in varying address values between different local voucher seeds based on the XOR operation within the VBA generation algorithm, further obscuring the value. VBAs originating from the same input parameters with varying iteration counts cannot be used to determine the internal state of the VBA algorithm (and thus the details of the interface's link-layer address or active voucher). This is because a hashing algorithm generates the majority of each final address suffix. VBAs can be regenerated for each subnet prefix, so location tracking is not possible.