# Securing IPv6 Neighbor Discovery Address Resolution with Voucher-Based Addressing
## 3 Voucher-Based Addressing
### Design Goals and Overview  
MAC spoofing attacks as presented in Section 3.B of [23] are a driving factor of why Voucher-Based Addressing functions in the first place. When two nodes share the same link-layer identifier in a switched network, frames will unreliably be forwarded to one \begin{table}
\begin{tabular}{l l} \hline \hline NDAR & Neighbor Discovery address resolution (see Section 7.2 of RFC 4861 [3]). \\ \hline \multirow{2}{*}{LLID} & A shorthand representation for the terms “link-layer address” or “link-layer identifier”. Both terms are synonymous and describe any individual link-layer identifier for a network interface. This term is generally used synonymously with MAC addresses in this research. \\ \hline \multirow{2}{*}{VBA} & Voucher-Based Addressing (the overall concept), or Voucher-Based Address (a single unicast IPv6 address generated according to this research). \\ \hline \multirow{2}{*}{LV} & Link Voucher. An NDP option consisting of a data payload distributed by a responsible neighbor. Its details are shared by neighbors and used in both generating and verifying VBAs. \\ \hline VB & Voucher Bearer. A neighbor that is solely responsible for the dissemination of the current Link Voucher. \\ \hline \multirow{2}{*}{IEM} & Interface Enforcement Mode. An interface-level, mutable operating mode which controls interface VBA generation and verification behaviors. \\ \hline \multirow{2}{*}{Binding} & Used primarily to describe a coupling between two types of addresses on different layers of the OSI Reference Model [21]. In the case of VBA, it is usually used in reference to link-layer identifiers as bound to network-layer identifiers. \\ \hline KDF & A cryptographic key derivation function. Defined in Section 3 of RFC 8018 [22]. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Related and necessary terminology as a reference for this research. of them based on which node most recently communicated through the switch. A flip-flopping of frame delivery at the link layer causes confusion of higher-level protocols and will most likely result in a denial-of-service attack on the legitimate node owning the MAC, thus disrupting the network. In the threat model from Section 3.2, this is an undesired consequence for stealthy threat actors. With this context, the principle of MAC address uniqueness per broadcast domain can be established. During the address resolution process, the goal is to associate a target IP address with its underlying link-layer address to which frames can be forwarded and switched. When LLIDs become the determining factors for higher-layer abstractions, such as IP addresses in the case of VBA, then \"bindings\" are created between the LLIDs and the abstractions. Since VBA generation depends on both these bindings and the principle of MAC address uniqueness at the per-interface scope, VBA verifications are considered valid proofs of MAC address ownership so long as the interface remains present on-link. The verification process is employed at specific times during NDAR transactions, independently mirroring the VBA generation process. Verifications are parameterized by (1) various inputs which identify the target node during NDAR (the IP and MAC addresses from NDP packets), and (2) inputs which lie beyond the control of the target node. Such external information resides within locally disseminated Link Voucher (LV; see Table 1) details agreed upon by all the neighbors. Due to the utilization of LL2 IP bindings in both generating and verifying VBAs, it is impossible to forge an association of an IP address to an LLID that cannot be bound to it. Enforcing binding verification secures the NDAR process against the issues of LL2 IP binding impersonation and thus against neighbor spoofing threats. Creating an IP address which incorporates verbatim the direct value of the LLID would suffice if the goal of bindings in VBA were only to validate address ownership.