# Securing IPv6 Neighbor Discovery Address Resolution with Voucher-Based Addressing
## 5 Discussion
### Other Security Considerations  
Networks requiring a mix of ephemeral addresses in parallel with static, stable addresses will encounter difficulties with VBA. Preserving the state of a voucher long-term will not be a feasible strategy to maintain stable addresses, since its preservation for any extended period grants more time for threat actors to compute collisions. Assigning static addresses to nodes in a VBA-enabled network can be accomplished using a couple of approaches:  
* Use the AGVL IEM on either all the interfaces within the local network, or on the interfaces known to interact with the target static address(es) directly. The AGVL IEM will permit per-implementation behaviors to strongly prefer the Secured results of NDAR exchanges over the Unsecured ones. This option will remove any guarantees of address ownership or on-path attack prevention from the static address(es). This is because a static address failing the VBA verification process will be tagged in the Neighbor Cache as an Unsecured entry, at the same level of preference and security as any other addresses whose bindings fail to verify. * If neighbors do not interact with the static address(es), then the only affected parties are the node(s) with static assignments and the subnet gateway, which will likely route traffic to and from the static address(es). If this is the case within the subnet, then only host-to-router NDAR transactions will fail verification, so a static entry in the NC of the router should correlate each LLID to each static IP address expected to use the gateway. An additional concern specific to IPv6 networks is anycast addressing. Anycast addresses are allocated from the unicast address space and are thus indistinguishable from nodes establishing connections to them. NDAR exchanges with these targets may, therefore, respond with varying LLIDs and cause VBA verification to be unreliable. For this reason, it is not recommended to utilize anycast addresses, because the ownership of the address cannot be bound to any particular LLID. The IPv6 Addressing Architecture specification in Section 2.6.1 (RFC 4291 [33]) defines a Required Anycast Address. VBA maintains compatibility with this requirement by disabling address verification for per-prefix subnet anycast addresses. For example, a node using SLAAC to generate an address in the subnet 2001:db8:700::/64 will disable VBA verification for the address 2001:db8:700::  
Another concern regarding the security and stability of the position that the Voucher Bearer takes in the VBA process for each local subnet is providing neighbors with a consensus on VBA generation parameters. If a malicious neighbor successfully races to provide LV options to joining neighbors before the legitimate VB can provide its own, then the neighbors will retain (and be subsequently \"locked\" to) misleading and mismatched voucher details. The ultimate, clean solution to this is to put an end to the capability of nodes to freely send RA or Redirect NDP messages on the local subnet, which by extension will disable the ability to send unauthorized LV NDP options. This is performed with the help of mechanisms like Router Advertisement Guard (see RFC 6105 [32]) or some other infrastructure-level packet filtering. Despite the complications this introduces in the network's configuration, it is a low-cost implementation because it does not need to be a shared prerequisite for nodes who are joining the local network. Lastly, considering the constraints of VBA verification, it is possible for a sending node \(\mathrm{N_{A}}\) to have verified the VBA for some neighbor \(\mathrm{N_{B}}\) without the reverse being true if \(\mathrm{N_{A}}\) does not provide an SLLAO during the initial NDAR exchange. \(\mathrm{N_{A}}\) can send packets to an application or service on \(\mathrm{N_{B}}\) without requiring any response traffic in return. The nodes receiving unsolicited packets from neighbors, for which no response is required or demanded by the sender, do not need to verify the sender's address binding.