# Securing IPv6 Neighbor Discovery Address Resolution with Voucher-Based Addressing
## 3 Voucher-Based Addressing
### Address Generation and Verification
In summary, VBA requires modifications to the following NDP behaviors on VBA-enabled interfaces:  
* Any new LLIDs on neighbors have an impossibly low chance of organically producing the same VBA as one already cached by verifying neighbors. Such an unlikelihood implies that any Neighbor Advertisement (NA) packets targeting an already-cached IP address which is not in the INCOMPLETE state must be ignored if an included Target Link-Layer Address Option (TLLAO) attempts to update the cache entry state or change its binding to a different LLID. This will prevent threat actors from maliciously triggering costly VBA verification processes where they are not necessary. * The value of an LLID within a Neighbor Solicitation (NS) packet must likewise never update any existing cache entry for the given IP source address. This is because it is a statistical improbability for any known VBA to have been genuinely formed from a different LLID when the voucher has not changed. * Any supposed urgent updates about underlying details for a known VBA are unnecessary. The Override flag in received NAs must not be able to freely update the underlying LLID or state of any cache entry. Some devices might wish to support the laxer AGVL IEM which allows compatibility with static unicast addresses on-link. In the case where an IEM is set to AGVL, the Override flag in NAs should not be ignored, in order to let static addresses immediately notify neighbors of a change in their interface LLIDs. VBA verification is a \"shim\" software process--a small functionality added as a process between two existing procedures--that prescreens incoming requests to insert or update cached bindings according to the normative Neighbor Discovery process. In Figure 6, Host B calls upon the verification shim of a verifying neighbor, Host A, in step 4. If the shim rejects the binding from entering or updating the Neighbor Cache, then Host A will be denied from properly forwarding data frames to the advertising Host B. This is because a cache entry in the Reachable state does not exist and will not be created. Prefiltering in such a manner immediately eliminates any threat actor's opportunity to forge NDAR messages or to redirect traffic maliciously. Employing the verification shim results in repeated KDF computations that could impact performance significantly for systems with minimal resources, so the shim must be optimized and called as seldom as possible. For the sake of optimization, NUD exchanges must not call upon the shim when none of the NDAR parameters (i.e., the IP address or the LLID) are being changed. Incoming NDAR messages failing VBA verification must be immediately ignored, and NC entries must not be created or updated as a result of their receipt. Nodes, likewise, must not respond to any packets failing the verification process. There are a few situations when address resolution packets cannot be optimized and must explicitly pass through the VBA verification shim for approval:  
* An NS, RS, or RA packet is received with an SLLAO attached and an NC entry for the IP source address is not already present. * An NA or Redirect packet is received for a target address whose NC entry is in the INCOMPLETE state. * An NA packet is received and the Override flag is set, and the receiving interface is using the AGVL IEM. The above list is perhaps not all-inclusive and does not consider other extensions to NDP which may allow certain messages to modify or insert cache entries. Except for forward progress indications through NUD, NDAR transactions of any type seeking to update or create any active NC entry must be pipelined through the verification shim first depending on the current IEM.