IPv6 Voucher-Based Addressing for Neighbor Discovery Address Resolution

IPv6 Voucher-Based Addressing for Neighbor Discovery Address Resolution University of Michigan

Detroit Michigan US zpuhl@xmit.xyz zpuhl@umich.edu https://xmit.xyz/

Internet IPv6 Maintenance ipv6 ndp vba spoofing privacy Voucher-Based Addressing is an extensible IPv6 address generation and verification methodology for SLAAC-enabled local networks. Individual link-layer identifiers are bound to sets of deterministic output IP addresses. Neighbor Discovery Link Voucher options distributed with Router Advertisement or Redirect messages form a shared consensus between neighbors of the parameters used to auto-generate interface addresses. Cryptographic key derivation functions are used to generate pseudo-random addresses and to intentionally stretch address computation times. Host-selected parameters can be used to derive any number of both stable and ephemeral, privacy-focused addresses for each on-link prefix and at the link-local scope. Neighbors can then verify the link-layer-to-IP bindings during NDP address resolution processes to prevent active neighbor spoofing attacks in local networks.

Introduction The Neighbor Discovery Protocol (NDP) is self-aware of its potential for misuse in neighbor spoofing attacks. Section 11 of the RFC provides a brief threat analysis followed by pointers to both SEcure Neigbor Discovery (SEND) , as well as Security Associations with native IPSec (Section 4 of ), as solutions for its weaknesses. Though SEND has been considered the canonical solution for its namesake (securing ND), it and its complementary Cryptographically Generated Addressing (CGA) have failed to achieve widespread adoption. NDP Address Resolution (NDAR; Section 7.2 of ) establishes a process for discovering the link-layer identifier (LLID) of a neighbor's IP address. This process faithfully relies on an untrusted neighbor owning the target IP to respond with its own LLID (and not, e.g., a malicious neighbor to respond with a redirected LLID). If the target IP address is already being directly correlated with an LLID through the NDAR process, it is then sensible to tightly bind the two identifiers together: IP addresses should be provably derived from their underlying interface LLID. Maintaining awareness of address privacy concerns, this binding needs to be formed in a way where temporary and stable identifiers can coexist with minimal impacts to pre-established privacy conventions. Voucher-Based Addressing (VBA) offers local IPv6 networks (1) a common procedure for binding LLIDs to IP addresses, (2) rotatable and private IP address generation, and (3) prevention of subversive spoofing attacks that lead to network traffic interception. Address bindings use mutual key derivation functions to map public input components to deterministic output IP addresses. These bindings can be subsequently verified through the same procedure by neighboring nodes to assert a target's bindings before proceeding with further communications. The address generation process creates rotatable IP addresses which appear entirely random to off-link actors, who are by design unaware of all input parameters associated with creating the addresses. This document describes a cross-application of cryptographic key-stretching techniques and LLID-IP bindings in generating multiple useful, random IPv6 addresses. The result is a high-impact, low-complexity, gradually adoptable, optional amendment to the NDAR process, with minimal changes to NDP options, formats, or behaviors. It is proposed as an alternative to SEND , CGA , and opaque IIDs , and it does not intend to obsolete or update any other document.

Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Background This document assumes the reader's basic familiarity with the following specifications. These can be referenced in order to provide plenty of helpful context for the concepts proposed herein.

IP Version 6 Addressing Architecture .
Neighbor Discovery for IP Version 6 .
IPv6 Stateless Address Autoconfiguration .
IPv6 Neighbor Discovery (ND) Trust Models and Threats .
SEcure Neighbor Discovery (SEND) .
Cryptographically Generated Addresses (CGA) .
Semantically Opaque Interface Identifiers .
Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 .
Security and Privacy Considerations for IPv6 Address Generation Mechanisms .
Recommendation on Stable IPv6 Interface Identifiers .
PKCS #5: Password-Based Cryptography Specification Version 2.1 (primarily Sections 3 and 4).
The Argon2 Key Derivation Function .
The Scrypt Key Derivation Function .

Terminology To acquire necessary context, please see Section 2.1 of for definitions of the following terms used equivalently in this document: neighbor, node, interface, link, address, router, host, on-link, off-link, IP, ICMP, packet, and target.

ND (sometimes NDP): Neighbor Discovery (Protocol) .
SEND: SEcure Neighbor Discovery .
CGA: Cryptographically Generated Addressing .
NDAR: The Neighbor Discovery Address Resolution process; see Section 7.2 of .
NC: Neighbor Cache, as specified in Section 5.1 of .
RS, RA, NS, and NA: Respectively: Router Solicitation, Router Advertisement, Neighbor Soliciation, and Neighbor Advertisement. A collection of abbreviations for ICMP packet types defined by NDP in .
NUD: Neighbor Unreachability Detection (Section 7.3 of ).
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 connected network interface.
IID: Interface Identifier. The unique identifier of an interface on a network. See Section 2.5.1 of .
SLLAO: Source Link-Layer Address Option. An ND option indicating the LLID of the packet sender or (typically) the NDAR initiator .
TLLAO: Target Link-Layer Address Option. An ND option indicating the LLID of the NDAR target .
DAD: Duplicate Address Detection (Section 5.4 of ).
SLAAC: Stateless Address Autoconfiguration .
VBA: Voucher-Based Addressing. The primary address generation and verification concept introduced by this document.
LV: ND Link Voucher option. A data payload intended to be distributed by a responsible node on-link. Details are statefully maintained on neighbors and are used in both generating and verifying VBAs.
LOVMA: Local On-link Voucher Multicast Address. A multicast group used by VBA-capable hosts to get non-essential information from the current Voucher Bearer or from other VBA-capable neighbors.
VB: Voucher Bearer. The on-link node solely responsible for dissemination of the LV and authorized by any potential link guarding to transmit Router Advertisements or Redirects with an LV attached.
VSR: Voucher Status Report. A type of data payload sent by VBA-capable nodes to the LOVMA. Shares information about the node's VBA preferences. Mainly used in optimizations as an optional protocol feature.
VCI: Voucher Capability Indication. A type of LOVMA data payload sent by candidate VBs to indicate their candidacy as a future VB.
VHA: Voucher Handoff Advertisement. A type of data payload sent by the current VB to the LOVMA, signing off on an election process for a new LV.
IEM: Interface Enforcement Mode. An interface-level, mutable operating mode which controls interface address VBA generation and verification behaviors.
LL2IP: Used to shorten the phrase "link-layer-address-to-IP" when discussing address bindings.
Binding: Used primarily to describe a coupling between two types of addresses on different layers of the network protocol stack. In the case of this document, it describes LL2IP bindings, where Link-Layer Identifiers are 'bound' to one or more IP addresses.
KDF: Key Derivation Function, as defined in Section 3 of .
Salt: An extra random value used in computing a hash which makes it impossible for attackers to precompute output values. See Section 4.1 of for more information.
Hextet: A 16-bit aggregation; data that is 16 bits in size.
RA-Guard: The Router Advertisement Guard mechanism, as specified in .

NOTE: Any use of the terms 'IP', 'DHCP', or 'ICMP' in the following sections of this document are synonymous with 'IPv6', 'DHCPv6', and 'ICMPv6', respectively. When referencing the IPv4-based versions of these protocols, it will be explicitly noted.

Voucher-Based Addressing This section outlines the design goals of Voucher-Based Addressing. It reviews the primary mechanisms driving the proposal and discusses related requirements for its adoption. It includes concrete processes and procedures used by VBA-capable network nodes to both verify neighbor bindings and to auto-generate their own VBAs.

Design A Voucher-Based Address is defined as any unicast IP address derived from a hashed combination of known voucher information, a subnet prefix, a work factor selection, and a bound LLID. The actual address derivation process is underpinned by a deterministic procedure parameterized by these values. This same derivation procedure is employed independently by neighbors to verify purported address bindings during NDAR transactions. This section will outline the design goals of VBA aspiring to synergistically balance privacy, flexibility, and simplicity.

Link-Layer Address Bindings VBAs are generated by using the LLID of the underlying, assigned interface as a partial input. They operate on the assumption that LLIDs must be unique on the same broadcast domain (link layer) at any given time in order for higher-level protocols to successfully operate. Due to this assumption of temporal uniqueness, nodes actively using and responding from exchanged LLIDs during NDAR are considered 'owners' of said LLIDs. Therefore, it follows that VBAs can be directly formed and authenticated from this 'identity'. Consider the effects of a MAC spoofing attack in an Ethernet LAN, as presented in Section 3.B of . Two nodes attempting to use the same LLID on a shared link will cause frames to be unreliably delivered and to flip-flop between two different paths in the network's link-layer switching infrastructure. This only benefits a threat actor if its objective is to deny service to a target, rather than to intercept or change frames. More specifically, the intended threat model for VBA assumes the presence of SILENT, TRANSPARENT spoofing attacks in which malicious neighbors arbitrate and intercept traffic without the knowledge of any parties on the path of communication. During NDAR, the goal is to associate a Target IP with a corresponding LLID to which frames can be forwarded at the link layer (see Section 7.2 of ). Because deterministic VBA generation partially depends on the value of the generating interface's LLID -- and thus the same one which would be reported in an NDAR exchange -- purported NDAR IPs and their bound LLIDs cannot be falsified. Thus, NDAR becomes safe from false reporting of LLIDs for IP addresses that do not produce a legitimate binding, so active neighbor spoofing becomes impossible. VBA verification is a procedure run by neighbors which mirrors the address generation procedure independently. Verification is parameterized by (1) data which identifies the target node during NDAR (IP address and LLID), and (2) data which lies outside of the generating node's administration. Such 'outside' information is found within the Link Voucher details that all VBA-capable neighbors are expected to know when performing verifications.

Key Derivation Functions & Address Privacy Link-layer bindings using a simple embedding or hashing scheme should suffice if the goals of VBA were only binding verification. For example, modified EUI-64 interface identifiers are formed by a long-established address derivation methodology which uses the LLID of an underlying interface; see Section 2.5.1 of . These could be used to confirm and fulfill the same purpose. But a design goal of VBA is to also establish a privacy-focused address generation procedure which will obscure the node's LLID while permitting rotatable addresses. EUI-64 is by design a rudimentary address derivation methodology which does not permit such flexibility. For this requirement, VBAs employ more sophisticated hashing during the address generation process to create a pseudo-random output address. A hash-based address does not allow outside trackers to know the LLID of the node. Using hashing and key derivation techniques ensures that any LLID of arbitrary length can be reliably bound to an address suffix that is fixed at 64 bits in length. Furthermore, hashing an LLID and producing an output will only create a one-to-one binding, but many IP address generation schemes already offer ways to derive many privacy-focused addresses from an LLID (e.g., Section 5 and Appendix A.3 of ). These addresses are usually by design NOT reversible, unless reversing parties are aware of all input parameters for the generation function. This is intended to preserve the privacy of the address. VBA strikes a careful balance of (1) keeping off-link nodes unaware of local LV information used in address derivation, and (2) ensuring on-link nodes are indeed aware of all parameters used to generate an address. Off-link actors cannot possibly know the VBA's bound LLID because they cannot receive ND messages, nor can they determine it from the address itself: VBAs will always appear as random as a consequence of using the outputs of deterministic hashing functions. More to the point, VBA elevates use of simple hashing to use of key derivation functions (KDFs), which allow a set of one-to-many LL2IP bindings. This is because KDFs accept work factor values specifying how many times the pseudo-random function or underlying hash function must be iterated to produce a final result. VBA computes KDFs with various inputs that specifically identify a neighbor's on-link interface, and the result of the KDF is planted into its generated VBA(s). Work factor selections are embedded into resultant IPs adjacent to their KDF outputs, such that the following three components are an inherent value always exchanged by an NDAR transaction:

The target's Link-Layer Address (LLID) and IP address (VBA).
A portion of the KDF's hash output (present within the VBA).
The work factor used when computing the KDF hash (also present within the VBA).

Interfaces using this generation process therefore enforce that all three items are mixed together and conveyed to verifiers -- who must also be aware of current Link Voucher details -- to produce the same output VBA. Each increment or decrement of the embedded work factor value produces an entirely new, seemingly random address with almost no correlation to the previous one.

Interface Configurations & States This section outlines different interface-level configurations and options which MUST be available in any implementation of VBA. It also discusses topics specific to caching LV information on local interfaces and outlines some specific details of the process. For more information on Link Vouchers, see .

Interface Enforcement Modes Per-interface modes (IEMs) are able to granularly dictate VBA behaviors. Flexibility in per-interface decision-making grants VBA a higher degree of flexibility with neighbors and adaptability in mixed networks. Implementations MUST allow nodes to independently opt into any one of the following IEMs for each local interface.

AAD - Address Awareness Disabled: The interface MUST NOT generate or verify any VBAs. It MUST NOT participate in any LOVMA communications. VBAs are ignored entirely in this mode, except for advertisements of Link Voucher options, which MUST still be recorded and tracked. This mode SHALL always be used by interfaces where a known LV is not present.
AGO - Address Generation Only: The address generation procedure MUST be used for interface unicast addresses. NDAR MUST NOT be supplemented by VBA optimization or verification procedures.
AGV - Address Generation & Verification: The address generation and verification procedures MUST be used. NDAR is REQUIRED to fail (deny neighbors, skip caching) if the advertised LLID cannot be verifiably bound to the given IP address according to the current Link Voucher. This SHOULD be the default IEM on non-transitioning links with a well-established VBA conformance.
AGVL - Address Generation & Verification with Levels: Both address generation and verification procedures are employed, but verification failures MUST NOT discard NDP messages. Addresses which successfully verify MUST be marked or indicated in the local NC as "Secured". Any address which fails to verify MUST be indicated as "Unsecured" and given less preference than "Secured" responses. This SHOULD be the default IEM on transitioning links that do not have full VBA adoption. If multiple Secured responses are entered for the same IP, each with a different LLID, then there may be an addressing collision and the behavior of the interface becomes undefined. In this rare case, the pool of Secured responses are considered equally valid VBAs, so it is left to the implementation to decide the correct course of action.

Preserving Voucher-Related State Regardless of their current IEM settings, VBA-capable interfaces are REQUIRED to store the full state of the most current, validated Link Voucher. If an LV is not available on-link, then no stored LV state is required and the node MUST enter the Address Awareness Disabled state. If an LV subsequently becomes available, then the node MAY choose to enter a different IEM based on the implementation (and whether the AAD IEM is manually set on the interface). LV details MAY also be set statically on an interface. In such cases, the static information MUST contain at least a VoucherID, Voucher Seed, and Algorithm Type specification. Any interface with static details configured MUST ignore any received LVs. Static LVs MUST always be considered active and preferred; therefore, they MUST NOT expire.

Link Voucher Acquisitions Interfaces connecting to the link for the first time are REQUIRED to accept and cache the first LV received. If the connecting interface intends to maintain responsibility for the LV as a VB, it MUST follow the process outlined in . Available LV options can be discovered by sending a plain RS message according to normative ND processes. Interfaces receiving multiple valid LVs simultaneously SHOULD use the LV with the most recent Timestamp value. An active LV expires when no updated LV with the same 'VoucherID' has been received within the amount of seconds specified in the voucher's 'Expiration' field. When an expiration occurs, the interface MUST again accept the first received LV. The 'Expiration' time can also elapse for an interface while it is disconnected from the link. If such an expiration occurs, then that interface MUST follow the same LV acquisition process. Because LV distribution to interfaces requires automatic Trust On First Use , it is essential for more adversarial networks to implement some form of protection against distribution of unauthorized LVs at a lower or intermediate level. See for more information. In the cases where these protective mechanisms are not available, administrators MAY choose to set LV information on each node statically. Administrators in this sitation SHOULD also choose to employ some form of intrusion detection to better prevent the distribution of unauthorized LVs.

Host Recipients & Link Voucher Transitions The node responsible for the current LV MAY at any time issue a handoff of that responsibility to another node (see ). During the period of transition between the previous LV and the new one, VBA-capable interfaces which are subscribed to the LOVMA channel SHOULD receive VHA multicast packets specifying the parameters of the new LV. These LOVMA-connected interfaces are strongly RECOMMENDED to allow both LVs to be cached, so that VBAs generated using either LV are immediately valid. These interfaces are also strongly RECOMMENDED to begin VBA generation with the new LV parameters ahead of time, in anticipation of the completed LV transition.

Link Voucher Transitions Time ~~~~~~~~~~~~~~~~~~~~~~~~~~~+ ... LV_A Validity | ~~~|~~~~~|~~~~~X~~~~~~~~~~~Z | | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | LV_B Validity ... | | +~~~~~|~~~~~|~~~~~|~~~~~|~~~~~~~ |==|=====|=====|=====|=====|=====|=====|===> Time | O O O O O O O ... | | | [ LV_A Active [ Overlap [ LV_B Active (1) (2) (3) ** 'X' marks the final advertisement for LV_A. Each 'O' at 'X' until and including 'Z' will include a VHA from the VB of LV_A. ** 'Z' marks the time at [X + LV_A.Expiration]. ** 'O' indicates the advertisement of an LV on-link. Moments: 1 = Link Voucher A is active for all nodes. 2 = VHA. LOVMA-subscribed nodes become aware of a transition window. Both LV_A and LV_B are considered active LVs. 3 = LV_A expires. Link Voucher B is active for neighbors and the transition completes. ]]> If another VHA appears indicating a third LV as appointed for election, receivers MUST ignore the VHA until one of the two LVs from the original VHA has expired. This prevents abuse which could flag several active LVs on the same link as being valid, causing an 'address generation storm' that drains available resources from neighbors. Once the transition window ends, the amount of valid LVs MUST return from 2 to 1. The transition window ends when the original LV is intentionally not refreshed within its LV-specified Expiration time. This indicates a final transfer of the current LV (and possibly the VB node). For interfaces that DO NOT regard LOVMA VHA datagrams, the 'transition' process is more akin to a 'hard handoff'. Due to LV requirements, these interfaces will not trust the new LV until the previous LV has expired, at which time any LV becomes acceptable. For this reason, any VBAs preemptively generated with the upcoming LV will not be successfully verified by neighbors unaware of the handoff, until the transition window has ended and the new LV becomes primary. Therefore, all implementations SHOULD parse VHAs in order to secure the handoff process, preventing malicious VBs from timing their own voucher injections during the 'hard handoff'. When a handoff completes, the LV for the interface has changed. Any time the stored VoucherID of the active LV transitions to another, the interface's non-static Neighbor Cache entries MUST be cleared and all VBAs, whether generated or verified, MUST be derived from the parameters of the newly active LV ONLY. This is true even in the case of a hard handoff. The handoff and transition window provides an opportunity for optimization. If neighbors are aware of the upcoming LV, then they MAY preemptively generate new interface VBAs in anticipation of the completed transition. Implementations MAY also choose to utilize this transition window for preemptive VBA verification of already-cached neighbors who advertise a Preferred Work Factor specified in LOVMA VSR packets. Finally, if the current node responsible for the LV either disconnects from the network or lets its LV expire without an election process, then the link becomes open and allows neighbors to fill in the LV void with their own. If no other VB assumes responsibility on the link while the primary VB is away or not transmitting updated LVs, then all VBA-enabled interfaces MUST retain the most recent LV for the purposes of VBA generation and verification, until a new LV becomes available.

Address Generation This section discusses VBA composition and the VBA generation procedure.

The Voucher-Based Address Generation Procedure K = A KDF specified by the Link Voucher. |---> L = A node-selected work factor. |---> Key = The 128-bit Link Voucher seed value. `---> Salt = [LLID] || 'v' || 'b' || 'a' || [PREFIX] Z = ~(L ^ Key[0..1]) SUFFIX = hextets{ Z, H[2..3], H[4..5], H[6..7] } `--> (using 0-based indexing) ]]> The IID for all VBAs (i.e., the SUFFIX) embeds two important details for verification:

A 16-bit 'Z' value, calculated as a bitwise complement of the XOR of the 16-bit 'L' value and the first hextet of the LV seed. This calculation uses this XOR computation to ensure the same work factor 'L' between different LV seeds will be unique and provide some resistance to tracking hosts between each varying LV seed. This is especially true if the node indicates a Preferred Work Factor value ().
- The 'L' value, also termed the 'iterations count' or 'work factor', controls how many times the KDF 'K' is iterated to produce the resulting hash. Increasing this value thus increases the work required to generate and verify the VBA and the cost of finding potential hash collisions.
48 bits from the resulting hash, or 'H' value, derived from the KDF after 'L' iterations. Implementations are REQUIRED to use the FIRST 8 bytes of the hash in formulating the SUFFIX value, replacing the first hextet with the 'Z' value as shown in the figure.

The address generation algorithm is detailed procedurally as follows:

An interface connects to a link and obtains LV details after solicitation ().
The 'L' value is chosen based on (1) interface/node preference, (2) intended VBA difficulty, or (3) random selection.
The LV contains baseline KDF parameters and the 128-bit Seed value to use in address computation.
The KDF Salt is a variable-length CONCATENATION of a few different values, in the order specified below. 'Raw' values indicate binary values, NOT hexademical string notations of the values.
- The raw LLID of the network interface on which VBAs are being generated. Note that, since the Salt value is a variable-length value, this is not required to be an IEEE 802 MAC address, but it MUST represent the same link-layer address to which the VBA(s) will be bound and thus verified during NDAR.
- The string "vba" without a null termination.
- The raw PREFIX value. This MUST match the 64-bit prefix for which the VBA will be generated, including any randomly assigned padding bytes.
The final address SUFFIX is computed:
- The first 16 bits are the bitwise complement of an XOR between the work factor 'L' and the first hextet of the LV seed.
- The least significant 48 bits are 6 sequential bytes from the KDF hash, skipping the first two bytes (hextet) in the sequence.

Address Verification This section provides an overview of VBA verification.

Client Node: The node resolving the LLID of a neighbor's Target Address; sends the initial NS packet with an SLLAO.
Target Node: The node supplying its TLLAO in a responding NA.

VBA verification MUST only performed during NDAR when enabled by the IEM of the verifying interface. Verifying a VBA entails reproducing the address generation procedure run by the Target Node during SLAAC self-assignment and ensuring the output address is exactly equivalent to the Target Address being solicited by the Client Node. The Target Node address being resolved MAY be any unicast address, but MUST be within the address space of an on-link prefix. The following figure shows how VBA verification integrates into NDAR. Node 'A' is the Client Node and Node 'B' is the Target Node. Each moment of the process is numbered sequentially, leading up to a final determination by Node 'A' as to whether the information given by Node 'B' constitutes a valid binding.

The Voucher-Based Address Verification Procedure [solicit] --' <====|=== (solicited-node | | (1; SLLAO*) | multicast NS) | | | | +---------+-------. | | | | | | | | +~~~~~~V~~~~~~~|~~~~+~~~~~~~~~~~+ `---+->| H := LV.K( V | [rebuild | (3) | | L := Z'(B, LV), | addr B] | `--+-> LV.seed, v----' | | makeSalt(MAC, prefix(B)) | | ); | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ `----> | [prefix(B) || suffix(Z(L, LV), H)] == B | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ (4) {????} | | DROP <-- false <---' '---> true --> ACCEPT/CACHE ]]> The Link Voucher MUST always be used from the state preserved on the verifying interface. Nodes SHALL NOT request or use the LVs stored by other nodes for any reason. If the verification procedure fails due to an LV mismatch between nodes A and B, then there is most likely either (1) an ongoing voucher transition window or (2) multiple same-link LVs being distributed. During moment (1), the Client Node MAY choose to attach an SLLAO to its NS message, which will cause the Target Node to verify its binding with the IP Sender Address from the NS packet. For more information about the 'when' of VBA verification, see . In the above figure, the Z' (Z-prime) function returns the work factor 'L' embedded in Node B's address. This function is the opposite of Z; it uses an input address to determine L rather than using an input L to determine an output hextet. Despite the different inputs, the naming alludes to the opposite purposes for each function. Z' is necessarily computed for each VBA verification because the L value is a required component to reconstruct the solicited Target Address of the Target Node.

Z(L, LV) = ~(L ^ LV.seed[0..1]): Returns a hextet to insert into a generated address. A bitwise complement of the result of a work factor value XOR'd with the first hextet of an LV Seed value.
Z'(B, LV) = ~(B[8..9] ^ LV.seed[0..1]): Returns a work factor 'L' derived from a full IP address 'B'. In this case, 'B[8..9]' is equal to the length and position of the embedded hextet calculated by the function 'Z' above.

Behavioral Neighbor Discovery Changes This section describes the requirements and implications of VBAs with regard to ordinary NDP. Simple amendments to NDP are necessary to secure NDAR. Any behavioral NDAR change not explicitly declared in this section falls back to the typical NDAR behavior in Section 7.2 of . If a receiving interface uses either the AAD or the AGO IEM, then this section's behavioral changes MUST NOT apply to that interface or its Neighbor Discovery behaviors. This document requests modifications for the following NDP behaviors on VBA-capable interfaces:

Since LLIDs are deterministically bound to IPs and VBA collisions are highly unlikely, new LLIDs on neighbors have an impossibly low chance of producing the same VBA. This unlikelihood means that any NAs using a cached Target Address NOT in the INCOMPLETE state MUST be ignored if an included TLLAO attempts to update the record to a different LLID (or attempts to change the NC entry to a different state).
The value of an LLID from an NS should likewise never update for the same generated IP Source Address. So NS packets with an SLLAO attached MUST NOT update the state or values of any active NC entry. This is true only if the current LV has not changed; however, a change of LV already requires a refresh of NC entries.
Any "urgent updates" about underlying details for the previous IP are unnecessary. The Override flag in NA messages MUST NOT update the underlying LLID of an active NC entry. It also MUST NOT update the state of any NC entry. However, when the IEM is set to AGVL, the Override bit MUST NOT be ignored. This can let static addresses immediately notify neighbors of a change in their LLIDs. This is not secure and is NOT RECOMMENDED.

The Address Verification Shim VBA verification is a 'shim' software process that filters incoming requests to cache bindings between IP addresses and LLIDs. If the verification shim rejects a binding from entering the NC, then the verifying node will be denied from properly forwarding data frames to the requesting node. This revokes a malicious neighbor's ability to forge NDAR packets or to spoof another neighbor with a different LLID. Employing the verification shim results in repeated KDF computations that could be costly for neighbors with fewer resources. Therefore, the shim needs to be optimized and called as seldom as possible. This document specifies that VBA verification MUST only be performed when updating or creating a NC entry through NDAR exchanges. For the sake of optimization, NUD exchanges MUST NOT use the verification shim. Incoming NDAR messages failing verification MUST be ignored and NC entries MUST NOT be created or updated. Neighbors MUST NOT respond to any messages failing verification. There are a few situations when NDP messages MUST 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.
If the receiving interface is using the AGVL IEM: an NA packet is received and the Override flag is set.
An NA or Redirect packet is received on a node supporting Gratuitious ND and the Target Address does not already have an NC entry.

This list is perhaps not all-inclusive and does not consider other ND extensions which may allow certain ND packets to modify NC entries. Except for forward progress indications through NUD, NDAR packets of any type seeking to update an active cache entry (whether state or values) or to create a new entry, MUST be pipelined through the VBA verification shim depending on the current receiver's IEM.

Neighbor Unreachability Detection The NDP specification outlines Reachability Confirmations that regularly update NC values when one of two types of hints indicates connections with already-cached neighbors are making "forward progress" (Section 7.3.1 of ). Forward progress signals that an established connection is still ongoing and that a neighbor is still considered REACHABLE in the NC. Nodes engage in NUD to keep their NC entries in ideal REACHABLE states. VBA capitalizes on this behavior by foregoing address verification requirements when NS/NA transactions only serve to express forward progress. This means that any forward progress showing NO CHANGE in the LLID and IP address of a NC entry MUST allow the record to be refreshed as REACHABLE without requiring VBA verification. Any forward progress indicating that a change has occurred in the LLID for an IP address MUST be ignored and MUST NOT update the cache.

Link Voucher Updates Any expiration of a current LV MUST cause the dynamic NC to be immediately cleared. This could occur for any number of reasons, but the expiration indicates that the LV is no longer in active use and therefore any non-static addresses which were previously cached MUST be dropped. Implementations MAY wish as an optimization to categorize or label NC entries by the LV 'VoucherID' used to verify them, so that other NC entries will not be forcibly cleared (such as those from a new LV after a voucher transition completes). When a new LV is accepted and cached, whether by a transition or due to the absence of a current LV, any current NC entries (especially busy or recent ones) MAY have their LLIDs pre-computed into the new resultant VBAs that derive from the new LV's parameters. This can occur even if no NDAR messages have been exchanged with those neighbors yet. This process necessitates that the pre-computing party knows a neighbor's Preferred Work Factor specified on the LOVMA channel. This allows communications with select neighbors to immediately resume without any potential delays incurred by the VBA verification shim. It is left to the discretion of each implementation to apply this optimization where feasible. Static mappings entered into the NC MUST be preserved regardless of LV updates.

Gratuitous Neighbor Discovery Gratuitious ND allows routers to create STALE NC entries from received NAs, in order to expedite the exchange of neighbor LLID bindings. VBAs SHOULD support this option, since routers preemptively verifying a host's address bindings will allow the host to communicate off-link much faster than if the router required a reverse NDAR process for the host. Implementations SHOULD be flexible with Gratuitious ND in how it applies to IEMs requiring VBA verifications. If a flurry of NA packets is received in an ostensible attack, the router might quickly find itself with too much work and could start dropping packets. Implementations MAY therefore toggle enablement of this feature reactively based on the router's evaluated processing load in real-time.

Duplicate Address Detection When generating a VBA, the node MUST follow the ordinary means of Duplicate Address Detection (DAD) specified by the SLAAC RFC (section 5.4 of ). The DAD procedure SHOULD follow any other applicable DAD optimizations (, , etc.). Upon detecting a duplicate address, VBA-capable interfaces MUST select another work factor 'L' value to generate a different and non-conflicting address. This can become computationally expensive to recompute each new value based on the amount of address collisions, and can be abused in the case of denial of service attacks. To counter this weakness, implementations MUST employ one of two options based on the selected work factor (L):

L > 4: Cache the 4 leading KDF iterations (L-4 through L-1) during the VBA generation.
L <= 4: Cache the result of the VBA derived from the 'L' value only.

Implementations SHOULD always prefer the option where the 'L' value is greater than 4, because L-4 through L-1 produce intermediate KDF hashes that are already necessary in order to calculate the hash at the final 'L' value. Conversely, any 'L' value at or under 4 will cache the generated KDF hash at 'L' then increment the input 'L' by one for each DAD collision, up to 4 times. A figure representing this process visually is shown below:

Using DAD with VBAs 4 : { L-4, L-3, L-2, L-1, L }, else : { L } (1) +~~~~~~~~~~~~~~+ |A|{B}------------>| Normal SLAAC | (B : Duplicate!) | v-----------| DAD Process | (B': Success) | [FAIL] (2) +~~~~~~~~~~~~~~+ | ^ `---> [cached (L-1) | or new (L+1) | (3) generates B'] --' ]]> In the figure, (1) shows node A engaged in DAD using the address B generated with L. After the collision is detected in (2), moment (3) shows the new VBA B' being immediately tried using the already-cached hash value from the work factor L-1. The DAD process is then successful and there are no duplicate addresses. The cost of computing L-1 or some other input work factor value has been avoided. To further cement this important optimization procedure, a written example process follows.

A new network host has received LV details; it specifies using PBKDF2 as the KDF.
The host arbitrarily selects 0xFF04 as its link-local VBA's 'L' value.
The host will iterate the PBKDF2 function through 0xFEFF.
The PBKDF2 cipher output for 0xFF00 (or L-4) iterations will be cached.
It will do the same for the next 3 steps (0xFF01, 0xFF02, & 0xFF03).
It will compute the final PBKDF2 round at 0xFF04 iterations, and will use the result to generate a valid link-local VBA.
When following the DAD procedure, an address collision is detected.
The host then immediately falls back to the KDF hash result from the L-1 value of 0xFF03 to create the link-local VBA.
This new VBA is completely different and does not register a DAD collision, so the interface continues using it.
The optimization has successfully removed the need to recompute the PBKDF2 algorithm up to some new work factor input, saving a significant amount of time in the VBA-enabled SLAAC process.

If all 5 attempted input work factors result in DAD collisions, then the node MUST give up and use some other implementation-specific course of action to contact an administrator or log a system management error. Note that truly benign DAD collisions are a dangerous prospect for VBA. Address collisions imply that a separate LLID with the SAME 'L' value and LV Seed has generated a KDF hash collision in the used 48-bit segment, exposing the possibility for node impersonation. Some implementations MAY wish to find trusted ways to detect such a collision, possibly by means of intermediate device monitoring (such as switching hardware), and take action(s) based on it. Nodes encountering a duplicate address will by necessity require a different work factor value to generate their current address. If the node advertises a Preferred Work Factor then it is RECOMMENDED that it send a gratuitous VSR update to the LOVMA channel with the new value (). Protections to mitigate denial of service attacks based on DAD are beyond the scope of this document. However, the cost of the VBA generation procedure is safeguarded from being abused by DAD mechanisms or their misuses. Since VBAs do not modify the actual DAD process, further work regarding DAD denial of service protections will apply likewise when using VBAs.

Neighbor Discovery Protocol Options The NDP option formats specified in this section MUST be supported to enable VBA functionality.

Link Voucher Option The Link Voucher option specifies the VBA generation and verification parameters which neighbors MUST use.

Structure of the NDP Link Voucher Option TLV Algorithm Type < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | > DER-encoded < > PublicKey & Signature < | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Padding < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

Type

Length

The total length of the LV from the Type through its end, inclusive, in units of 8 octets.

Expiration

A 16-bit big-endian value storing the amount of time in seconds that the LV should be considered legitimate when an update has not been received. This value MUST be a minimum of 3,600 (1 hour).

Reserved

64 bits of space reserved for future use. This value MUST be initialized to 0 by senders and MUST be ignored by receivers.

Timestamp

A 64-bit value representing the system time of the sender upon sending the option.

VoucherID

A pseudo-random 32-bit value which uniquely identifies an LV instance. This MUST NOT change between distributions of the same unique LV and seed value.

Seed

A 128-bit pseudo-random value used as an input in VBA generation. This value MUST be the same for each distribution of an LV instance identified by a VoucherID. It MUST NOT be the same value across different LV instances.

Algorithm Type

Specifies the type and difficulty of the KDF to use in VBA generation. See for more details.

ECDSA PublicKey & Signature

A variable-length field containing a DER-encoded ECDSA public key of type SubjectPublicKeyInfo according to Section 2 of . The public key structure is followed immediately by an adjacent DER-encoded ECDSA signature, derived using the Private Key corresponding to PublicKey. The signature is computed over a series of sequential octets, constructed in the following order:

The 16-bit 'Expiration' value.
The 64-bit 'Timestamp' value.
The 32-bit 'VoucherID' value.
The 128-bit 'Seed' value.
The full variable-length content of the 'Algorithm Type' value, including its Type and Length values.

The algorithm used in signature computation is ecdsa-with-SHA256, as defined in Section 3.2 of . The Signature MUST be a DER-encoded ASN.1 structure of the type ECDSA-Sig-Value (Section 2.2.3 of ). The final field appears as the following two immediately adjacent DER structures:

Padding

Any extra padding set on the datagram to round its total length to an even 8-octet boundary. Senders MUST initialize this value to 0. Receivers MUST ignore this field.

Processing Rules for Senders Voucher Bearers MUST always respond to Router Soliciation packets with a valid LV option. This is true whether it is using a Redirect or Router Advertisement to distribute its LV. Sending nodes wishing to distribute an LV MUST first check the link for an already-active LV. This entails following a process of router discovery, then only assuming LV responsibility if no LV is already present.

Send a Router Soliciation to the All Routers multicast group at FF02::2.
Wait for an LV option for at least 2 seconds before sending another RS.
Repeat this process 2 more times.
- If an LV is received within an RA or Redirect response, accept and use the parameters of the received LV. This condition means the Sender MUST NOT use or send their own LV, nor should it propagate any instances of received LVs.
- If no LV is received after the 3 total attempts, and...
  - the Sender IS NOT a router: the Sender's LV may be distributed on the local link as an option attached to an appropriate ND Redirect message.
  - the Sender IS a router: the Sender may attach its LV to an appropriate ND RA message.

Senders of LVs MUST maintain stateful information about their own LV options, so reliable and consistent vouchers can be sent whenever demanded. The rotation of stable LV information -- i.e., the VoucherID, Seed value, or Algorithm details -- MUST be signaled in advance using the LOVMA group (), which will initiate a transition window to the new VBA generation parameters. Expiration values MUST be set to an appropriate value. Senders MAY adjust this value without requiring a handoff. Timestamp values MUST always be sent to the precise system time as a big-endian 64-bit value. The Sender's LV option MUST always be unique and MUST NOT be a forwarded or duplicated copy of another LV. Additionally, the voucher's Seed value MUST NOT be preserved between different LV VoucherIDs or handoffs. It MUST always be a random value when first associated to an LV VoucherID. Protecting the network from malicious LV options is crucial to maintain the full consensus of the local network in VBA generation and verification parameters. See on RA-Guard and about LV Hijacking for more details. also discusses considerations for incorporating trust anchors and PKI into LV option signatures.

Processing Rules for Receivers An LV option appearing with any message except Router Advertisements or Redirects MUST be discarded and ignored. Nodes manually set to any IEM on their receiving interfaces MUST still regard and cache LVs according to the rules specified in this document. Nodes with static LV details assigned on their interface(s) MUST ignore and discard any received LVs. Nodes acting as authorized VBs MUST disregard any received LV options on the links for which they are already the active, responsible VB. Receiving nodes MUST statefully maintain and update all LV information per interface, if and only if the received LV is successfully verified according to its cryptographic signature and is not expired. The most recent, valid, and unexpired version of the LV is what MUST always be cached and preferred on the receiving interface. A received LV that does not contain a valid Signature, Timestamp, or Expiration MUST be ignored. Nodes receiving a new LV for the first time are 'locked' to that LV and its public key through an automatic "Trust On First Use" mechanism . Receivers therefore MUST NOT accept LVs which contain any other Public Key details or signatures which do not use the same Public Key. This period of trust in the public key's value remains in effect until the cached LV expires or until another LV is elected in a handoff and a transition begins. Received LVs which contain different VBA generation parameters (VoucherID, Seed, Algorithm details) MUST be ignored and MUST NOT update any cached LV entries, even if the signature field is valid. Likewise, any difference in the public key value MUST cause the LV to be ignored regardless of the LV's contents. LVs with invalid Timestamp values MUST be ignored. Timestamps MUST be considered invalid if the value falls outside of the range [CURRENT_TIMESTAMP - LV_Expiration] to [CURRENT_TIMESTAMP + LV_Expiration], where CURRENT_TIMESTAMP is the precise 64-bit system time measured by the Receiver. In cases where the precise system time is measured in sub-second intervals like microseconds, the unit of 'seconds' in the LV_Expiration time still applies and MUST be converted properly for accurate arithmetic with CURRENT_TIMESTAMP. This timestamping process ensures LV validity remains flexible even with minor clock drifting across the local network. Voucher transitions () allow 2 LV options to be considered valid and cached simultaneously. When a Receiver is subscribed to the LOVMA and detects a VHA electing a new LV, it MUST ignore further LV updates either signed by the previous LV's public key value or sharing its VoucherID. This will ensure the previous LV follows through with its commitment to self-expire once the transition began.

Algorithm Type Options Section 5 of specifies the definition of a Key Derivation Function (KDF):

A key derivation function produces a derived key from a base key and other parameters. In a password-based key derivation function, the base key is a password, and the other parameters are a salt value and an iteration count...

This section will discuss the default algorithms and KDF types that MUST be packaged with basic implementations of VBA. Future versions or extensions of this document MAY add new KDF algorithms corresponding and Type IDs. Any Algorithm Type option not specified in this document or in future versions MUST be ignored by receivers. An Algorithm Type choice is formatted as a Type-Length-Value (TLV) object, where Type is a numeric identifier uniquely representing a chosen KDF, Length is the width of the total Algorithm Type in units of 4 octets, and Value is a compact data format zero-padded to the nearest 32-bit (4-octet) boundary. Receivers MUST always ignore padding and senders MUST always initialize padded areas to zero.

Structure of an Algorithm Type Option Value < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]> The list of default KDF Algorithm Type choices is given below.

PBKDF2_SHA256

The Password-Based Key Derivation Function (PBKDF2) is defined in Section 5.2 of . It is a CPU-bound KDF, use of which can result in significant computation speed disparities between systems with variable hardware resources. It is included primarily for portability, universality, and ease of implementation. This specification explicitly uses PBKDF2 with SHA-256 as its PRF in Type 1. Implementations using this Type MUST use SHA-256 as the underlying PBKDF2 pseudo-random function.

Type

Length

Value

ITERATIONS_FACTOR: A big-endian 16-bit integer representing the multiplier of an input KDF work factor 'L'. This value MUST be greater than 0; receivers of 0 values MUST assume 1 instead. This factor can be used by an LV to automatically scale the difficulty of the PBKDF2 KDF on the link.
Padding: 16 bits (2 octets) of padding initialized to zero. Senders MUST set this to 0. Receivers MUST ignore this padding.

Argon2d

The Argon2 algorithm is specified in Section 3 of . It is a Memory-bound cryptographic KDF which will ideally provide less disparate address computation speeds than CPU-bound algorithms like PBKDF2. VBA explicitly uses Argon2d instead of Argon2i or Argon2id because address generation does not require any resistance to side-channel attacks. The in-memory data used by the KDF SHOULD NOT be treated as secret for any reason. All implementations with this Type MUST specifically use Argon2d. Implementations SHOULD always prefer to use this Type over others, provided all participating network devices have Argon2d support. The work factor 'L' value is used as the 't' input for Argon2d computations. The Argon2 't' parameter indicates the number of passes and is used to increase the algorithm's running time regardless of MemorySize. To give the LV parameters in the Value field more weight, 't' MUST always be reduced from the input 'L' value as follows: t := (L >> 8) + 1 The Argon2 parameters for Secret Value 'K' and Associated Data 'X' MUST NOT be used or distributed by the LV. The Tag Length 'T' for Argon2d MUST be set to 32 and MUST NOT be changed.

Type

Length

Value

Parallelism: An 8-bit integer determining how many degrees of parallelism (lanes) are allowed to run during KDF computation. This value SHALL NOT be set to 0. Receivers MUST consider Parallelism values of 0 to automatically indicate a Parallelism of 1.
MemorySize: A big-endian 24-bit integer representing the number of kibibytes (KiB) used in the KDF computation. This value SHOULD be carefully controlled and SHOULD if possible take into consideration the computing resources across the link on which the LV will be distributed. This value MUST be a minimum of 8 × Parallelism and MUST NOT be set to 0. Receivers MUST adjust the minimum MemorySize accordingly if the value does not meet the minimum threshold for the ACTUAL degree of Parallelism being used.

Scrypt

The Scrypt KDF algorithm is specified in Section 6 of . It is a Memory-bound cryptographic function which, similar to Argon2, ideally provides less disparate address computation costs than CPU-bound KDF techniques. The work factor 'L' value is used in parts of the 'N', 'r', and 'p' inputs for Scrypt computations. The Scrypt 'N' parameter indicates the CPU/Memory cost of running the computation. This value MUST be a power of 2. The 'r' Scrypt parameter indicates the desired block size (RAM cost). The 'p' parameter indicates the desired degree of parallelization. Actual values are computed by the following conversion: N (Cost) := MAX(1 << (MIN(11, MAX(1, ((L & 0xFF00) >> 8) / 24))), 2) << SCALING_FACTOR p (Parallelization) := MAX( 1, (L & 0x00F0) ) r (BlockSize) := MAX{ 1, (L & 0x000F) )
The Scrypt parameter 'dkLen' (derived key length) MUST always be set to 32 and MUST NOT differ between implementations.

Type

Length

Value

SCALING_FACTOR: An 8-bit integer setting the difficulty scaling of the Scrypt algorithm. This value MUST only be 0 through 5 inclusive. Receivers MUST adjust the maximum SCALING_FACTOR to 5 if the value of this field is greater than 5.
Padding: 24 bits (3 octets) of padding initialized to zero. Senders MUST set this to 0. Receivers MUST ignore this padding.

Local On-link Voucher Multicast Address The LOVMA group is defined for the express purpose of sharing non-essential, independent VBA details between neighbors. All VBA-capable neighbors are strongly RECOMMENDED to join this group, regardless of their IEM settings. Nodes are not required nor expected to make practical use of any LOVMA traffic. However, current link VBs are always REQUIRED to join the LOVMA channel. This multicast group is located at the IP address FF02::ABBA. A helpful mnemonic to remember this address is to think of ABBA as the closest possible hexademical rendition of "a VBA". The designated UDP port on which all LOVMA data is sent and received is 2196.

Constraints When utilizing the LOVMA channel for any purpose, implementations MUST regard these constraints:

LOVMA messages are considered unidirectional. Neighbors SHOULD NOT send unicast responses in reply to multicast traffic. This recommended constraint prevents asymmetric traffic volumes and any resulting denial-of-service vulnerabilities.
All LOVMA datagrams MUST be User Datagram Protocol (UDP) packets.
VBA-capable neighbors MUST NOT assume that any other VBA-capable nodes are subscribed to the LOVMA multicast group or receiving any of its related datagrams. However, neighbors MAY assume the presence of the current link VB on the LOVMA.
Subscribing nodes MUST NOT offer any trust of LOVMA packets, unless some datagram verification procedure is explicitly declared in the Defined Datagram Type specification.
Senders of LOVMA traffic are REQUIRED to send packets from a link-local VBA bound to the sending interface.

Defined Datagrams All LOVMA datagrams MUST use a Type-Length-Value (TLV) format. Type is an 8-bit integer identifying the datagram type, Length is an 8-bit integer specifying the length of the packet (including the Type and Length fields) in units of 4 octets, and Value is the data to be handled. The Type and Length fields MUST NOT be set to 0. Receivers MUST ignore datagrams with a Type of 0 or a Length of 0.

Structure of an LOVMA Datagram ... < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

Voucher Status Reports (VSRs) A node MAY occasionally send VSRs to the LOVMA channel to gratuitously let other nodes know of its presence as a VBA-capable interface, in addition to a few VBA-related status fields. Senders are REQUIRED to add their interface LLIDs onto transmitted VSR packets. This allows receivers to easily identify the sending interface by ID, rather than the IP Source Address of the datagram, to associate the sender with one of its potentially many on-link IP addresses. Senders MUST adhere to the rules defined in the below figure. Receivers are not required to parse any of the fields. Receivers MAY confirm the IP Source Address and LLID by running the VBA verification procedure to check the binding, but it is not necessary and therefore NOT RECOMMENDED due to its potential costs.

Structure of a VSR Datagram LLID < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Padding < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

Type

Length

Variable. The length of the datagram in its totality, rounded up to the nearest 4 octets.

IEM

A 3-bit value identifying the IEM of the sending interface according to the table below. This value MUST be set to the AAD IEM if the sending interface does not have a currently cached, active LV. IEM Identifier Mappings

Value	IEM
0	AAD
1	AGO
2	AGV
3	AGVL
4	Reserved
5	Reserved
6	Reserved
7	Reserved

Reserved

Space reserved for future use. This value MUST be initialized to 0 by senders and MUST be ignored by receivers.

VoucherID

The ID of the cached, active LV stored for the sending interface. Senders MUST initialize this to 0 if no LV is present or if they are operating in the AAD IEM.

Preferred Work Factor

Senders MAY use this field to indicate a preferred work factor ('L') value used often when generating VBAs within each on-link prefix. Receivers MAY associate this field with the LLID value to preemptively calculate VBAs for the Sender when the current LV changes or transitions.

LLID Length

The length in bytes of the LLID field. Stored as a big-endian value.

LLID

A variable-length field containing the sending interface's LLID.

Padding

Any extra padding set on the datagram to round its total length to an even 4-octet boundary. Senders MUST initialize this value to 0. Receivers MUST ignore this field.

Voucher Capability Indications (VCIs) A node MAY notify the LOVMA channel about its potential candidacy as a Voucher Bearer by sending a VCI datagram. The VCI is an informational datagram REQUIRED to be sent for consideration of election by the current VB. Receivers are typically intended to be the current VB, but any neighbor MAY make use of VCI details. Neighbors MUST NOT consider VCI packets as valid LVs. The current VB MAY maintain a state of unexpired VCI packets, especially when it intends to elect a new node responsible for the LV. Current VBs SHOULD NOT elect a new VB without first receiving a VCI datagram indicating the Sender's readiness to be elected. Sending nodes MUST NOT assume that issuance of a VCI packet is guaranteed to lead to eventual election as a VB. The decision for election by the current VB MUST be indicated by receipt of a signed VHA datagram, whose signature's PublicKey matches that of the current, active LV of the VB.

Structure of a VCI Datagram Link Voucher Contents < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

Type: 2
Length: Variable. The length of the datagram in its totality rounded up to the nearest 4 octets.
Reserved: Space reserved for future use. This value MUST be initialized to zero by senders and MUST be ignored by receivers.
Link Voucher Contents: The entirety of the ND Link Voucher option to be attached to future RAs or Redirects. This MUST also include the LV's ND Option Type and Length values. Validation of this field follows the same rules outlined by . Receivers MUST NOT expect the signature or PublicKey of the LV option to be the same as that of the current LV, because this packet type is only announcing a node's candidacy for future election, and it is NOT attempting to declare a new LV. Receivers MUST ignore the entire VCI if validation of the embedded LV fails for any reason, including invalid cryptographic signatures, null IDs, etc.

Voucher Handoff Advertisements (VHAs) The node responsible for the LV MAY at any time elect a new VB using the VHA datagram. This handoff communication notifies subscribing VBA-capable nodes of a change in VB and thus the PublicKey information used to sign the new LV. If the signature on the VHA is valid, listening nodes MUST accept the start of the handoff process whereby both VoucherID fields become temporarily valid for the link. If the Signature field is not verifiable using the current LV's PublicKey, then receivers MUST ignore the packet. If there is no current LV and a VHA is received, then it MUST be ignored. The transition window duration is based on the 'Expiration' value of the current VB's LV at the time the VHA is sent. Exceedingly long Expirations will entail exceedingly long transition windows, and there is no limit to its duration. VHA retransmission frequency is variable but is RECOMMENDED to follow the same frequency as the node's previous RA or Redirect issuances. VBs initiating a handoff MUST send at least one VHA notification every 5 seconds for a minimum of 3 minutes. If the 'Expiration' value is high, nodes handing off VB responsibility MAY choose to stop transmitting VHAs after this minimum threshold has elapsed. Candidate nodes considered for VB election MUST be gathered from either (1) manually configured details or (2) senders of recent, unexpired VCI notifications on the LOVMA channel. When the elected node observes the VHA packet granting it VB responsibility, it MUST begin sending gratuitous RAs or Redirects to the link for which it is now a VB. Sending an RA to the link always follows the receipt of a valid, unexpired VHA from the previous VB. After 2 minutes, the new VB MUST consider the LV parameters (including the PublicKey) of the previous VB as invalid, and MUST NOT trigger any more RAs driven by receipt of VHAs from the previous VB. VHAs MUST also be used to indicate a change in active LV details using the 'Refresh' bit. This indicates that the handoff represents a transition between LV parameters from the same VB rather than a change of issuing VB nodes. Using the VHA for this purpose affords neighbors enough time to fully transition addresses between varying LV parameters, just like in an ordinary election. See for more details regarding the handoff process at the per-interface scope.

Structure of a VHA Datagram < > DER-encoded Signature < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Padding < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

Type

Length

Variable. The length of the datagram in its totality rounded up to the nearest 4 octets.

R (Refresh Bit)

A single bit. When set to '1', it indicates that the transition is only an LV refresh and does not represent a change of the link VB to a different node. This field is mostly used for informational purposes and for any implementation-specific optimizations.

Reserved

15 bits of space reserved for future use. This value MUST be initialized to 0 by senders and MUST be ignored by receivers.

Timestamp

The current precise system time encoded as a 64-bit value. Timestamps MUST be considered invalid if the value falls outside the range [CURRENT_TIMESTAMP - 120] to [CURRENT_TIMESTAMP + 120], where CURRENT_TIMESTAMP is the precise 64-bit system time measured by the receiving node and 120 is in units of seconds. If the CURRENT_TIMESTAMP is measured in sub-second units like microseconds, then the 120 value MUST be converted to an appropriate value. This requirement ensures timestamp validity remains flexible even with minor clock drifting across the local network.

Signer VoucherID

The VoucherID of the active LV which is signing the handoff to the Upcoming VoucherID. Nodes using this ID for their active LV MUST disregard any further advertised LVs with this ID upon receiving this VHA datagram. A receiver MUST ignore this packet if the Signer VoucherID does not represent the active LV held in the cache of its receiving interface.

Upcoming VoucherID

The VoucherID of the upcoming LV which will be assuming 'active' status on the network after the handoff window completes.

ECDSA Signature

A variable-length field containing a DER-encoded ECDSA signature (and thus PublicKey), derived using the Private Key corresponding to the sender's Signer VoucherID. The signature is computed over a series of sequential octets, constructed in the following order:

The 64-bit 'Timestamp' value.
The 32-bit 'Signer VoucherID' value.
The 32-bit 'Upcoming VoucherID' value.

The algorithm used in signature computation is ecdsa-with-SHA256, as defined in Section 3.2 of . This field MUST be a DER-encoded ASN.1 structure of the type ECDSA-Sig-Value (Section 2.2.3 of ). The implied PublicKey value MUST be equal to the PublicKey of the active LV on the receiving interface. If it differs, then the VHA MUST be ignored.

Padding

Any padding necessary to round the packet size up to the nearest 32-bit boundary. This value MUST be initialized to 0 by senders and MUST be ignored by receivers.

Voucher Bearers A Voucher Bearer (VB) is a neighbor responsible for the current, active, majority-accepted Link Voucher option. This section introduces VB constraints, recommendations, or other requirements for implementations and deployments.

Appointments Any willing neighbor MAY be elected to serve as the VB, whether by manual configuration or by a process of election and appointment from the current VB (see ). Current VBs wishing to transfer LV ownership to another responsible candidate MUST use the LOVMA channel and issue handoffs per the election process (see ). Neighbors MUST NOT be granted VB responsibilities without first announcing their candidacy through valid an LOVMA VCI message. If the current VB is not a router nor responsible for routing subnet traffic, then it MUST distribute the LV via an ND Redirect packet with an LV option instead of using an RA packet with the LV option. The Redirect message MUST otherwise conform to the constraints of normative NDP Redirects (Section 8 of ). VBs MAY at any time let their own LVs expire if they do not wish to elect another VB, or if there are no other candidates available on the LOVMA channel. VBs SHOULD NOT let their own LVs expire without first appointing a responsible successor. If there is no successor, then the most recent LV MUST remain current for the link until another neighbor assumes VB responsibilities.

Employing RA-Guard Fake or malicious LVs can be problematic for neighbors that do not yet have an LV stored for. Illegitimate VBs represent a threat more thoroughly explored in . Bogus RAs/Redirects are a known problem in local IPv6 networks with no active protections, causing potential failures of neighbors. An excerpt from the RA-Guard RFC is noted:

describes a solution framework for the rogue-RA problem where network segments are designed around a single L2-switching device or a set of L2-switching devices capable of identifying invalid RAs and blocking them. The solutions developed within this framework can span the spectrum from basic (where the port of the L2 device is statically instructed to forward or not to forward RAs received from the connected device) to advanced (where a criterion is used by the L2 device to dynamically validate or invalidate a received RA, this criterion can even be based on SEND mechanisms).

The RA-Guard system SHOULD be augmented and deployed with VBA awareness, capable of tracking the state of LVs and LOVMA channel elections. This will allow an intermediate network device or set thereof, such as a switch, to only require RA-Guard Learning Mode for a short initial period. It can then subsequently "follow" the authorized LV around the link. The difference with RA-Guard in this scenario is to restrict the forwarding of frames containing encapsulated RA/Redirect packets when and where appropriate based on what the system understands about the state of vouchers on the network. One notable exception to this, however, is that an RA-Guard implementation MAY drop its protections if and only if the most recent and legitimate LV has expired without a successor. This is because some responsible VB needs to be free to supersede a "dead" or expired LV. In the case where the elected VB is not a link router nor responsible for routing traffic and ND Redirect messages are being sent with attached LV options, a Redirect-aware flavor of RA-Guard is strongly RECOMMENDED to also include these in its learning processes. Use of RA-Guard is primarily suggested for networks with a "revolving door" of neighbors, public networks, or networks which otherwise need to fortify and guarantee their security posture. Appointments or elections of new VBs should be considered with caution because the lack of PKI permits false claims of initial identity. The exact deployment of RA-Guard is beyond the scope of this document, but it is strongly RECOMMENDED.

Specification Optimizations This section briefly summarizes and references the various optimizations built into VBA by default.

Summary

Avoiding Repeat Verifications: Neighbor Discovery NUD is used to avoid continuous and expensive verification of active neighbors. If the current LV has not changed, then bindings reported in an NDAR exchange do not need to be re-verified after being cached. provides more details about this crucial performance optimization.
Duplicate Address Detection: The SLAAC DAD process is optimized to reduce the burden of regenerating another VBA from scratch for each collision. describes this cost reduction.
The LOVMA Channel & Preemption: The LOVMA group affords various VBA optimizations to the link. It enables the use of transition windows for VBA-capable neighbors to detect upcoming LV changes (). It allows hosts to note their preferred work factors for upcoming VBA generations, new prefixes, and LV transitions (). Lastly, it allows nodes to become candidates for VB election when the current VB no longer wishes to maintain responsibility for the LV ().
Key Derviation Function Selections: The options presented in permits the flexibility to choose a baseline difficulty setting for VBA generation and verification on the link. From this baseline, which implementations MAY choose either by default settings or by other details gathered about the link, nodes are permitted to scale the difficulties of each VBA they generate based on selected work factor values.

A Note About Packet Loss & Speed This document proposes various optimizations to ensure the performance of VBA is commensurate with its simplicity. However, the cost of binding verification may be significant depending on an LV's imposed Algorithm Type option as compared to the relative computing power of the verifying node. Such a process could create a situation where VBAs cannot be verified fast enough. As such, optimizations become inversely proportional to security. Preemptive caching of neighbor bindings results in fewer lost packets and much less ND-driven delays when enabled, but it also allows malicious attackers to spoof thousands of false advertisements per second, inundating neighbors with backlogs of LL2IP bindings to verify (assuming the IEMs on the receiving interfaces mandate verification). It is left to both (1) other works and (2) per-implementation details to balance these issues. While this document attempts to find a happy medium, it can only make generic suggestions due to its umbrella of effect.

Transition Considerations It is unrealistic to assume that VBAs could be deployed simultaneously across all nodes in even relatively tiny local networks. There will undoubtedly be network devices present which have no support for VBA. While that is especially true at the time of drafting this document, it is certain that some hardware vendors and software developers will never implement VBA or provide necessary operable support. Therefore, VBA must come pre-packaged with an exploration of its ability to work in a transitionary environment where its full support is lacking.

Tweaking Interface Enforcement Modes Local IEMs can be adjusted on nodes communicating directly with unsupporting nodes to better accommodate their lack of verifiable bindings. For example, a VBA-capable node corresponding with its noncompliant neighbor might opt to use the AGVL IEM. This would allow it to strongly prefer Secured cache entries for the rest of the network (such as the default gateway) while still caching and marking Unsecured any NDAR responses that do not successfully verify. In the case of a subnet router in a mixed network -- that is, a local network consisting of VBA-capable and incapable neighbors -- using the AGVL IEM can again prove very advantageous for the sake of accommodation. Assuming most nodes communicate with valid VBAs and a few cannot, only those few nodes are at risk of neighbor spoofing attacks.

Security Considerations This section includes discussions related to the security of VBA. It also serves to clarify certain processes or tangential topics which may not have had adequate exploration in the rest of this document.

Collision Resistance & Time-Memory Tradeoffs VBA generation only preserves 48 bits from a resultant hash. While a collision is unlikely, nodes treat this as they do the DAD process: even if it is unlikely, it is possible and must be handled appropriately. Potential hash collisions expose a weakness of VBA because LL2IP binding is done through a deterministic hashing process and nothing else. In other words, there is no other mechanism used for certifying neighbor addresses. Thus, any other spoofable LLID producing the same 48-bit 'H' portion of the VBA suffix will result in an equally valid VBA according to the verification procedure. The employment of cryptographic KDFs drastically reduces the capacity for attackers to discover address collisions and use them for spoofing purposes. This brute-force resistance is a consequence of each KDF intentionally requiring more time than traditional hashing to compute. Section 3 of defines a KDF in the exact manner this specification intends to apply it:

Another approach to password-based cryptography is to construct key derivation techniques that are relatively expensive, thereby increasing the cost of exhaustive search. One way to do this is to include an iteration count in the key derivation technique, indicating how many times to iterate some underlying function by which keys are derived.

Thus, KDFs are applied to VBA for the added purpose of slowing collision discoveries. This same tradeoff of requiring slightly more time for address computation in order to protect against brute-force enumeration is a strategy also recommended for use in password storage systems to protect user secrets (see ). To prevent any possible time-memory tradeoff attacks, the LV is distributed between nodes to ensure that input parameters generating VBAs are always generously salted by a 128-bit pseudo-random value, as well as the subnet prefix, so they can never be pared down to a simple dictionary attack. This same value from the LV is also intended to rotate occasionally in order to prevent long-term attacks. An attacker searching for inputs producing a colliding address is therefore subjected to the misery of enumerating many different link-layer addresses in order to generate an IP address that matches the target's 48-bit hash suffix. This spoofed IP address must also embed the same work factor as its target because it needs to be an equivalent IP. If the target IP address contains a high work factor value, then this searching process will be even slower and more unlikely to succeed. All the while, these collision-producing inputs must be obtained before the rotation of the LV Seed, which will reset the hypothetical attacker's marathon entirely. LVs also specify the use of shared KDF algorithms and difficulties on the link. This permits a dynamic adjustment of the base computation time required to derive or verify all link VBAs. For example, adjusting computation time to be an approximate minimum of 20 milliseconds per address for the least powerful node, and an estimated 1 millisecond for the fastest, produces a negligible delay in processing legitimate ND messages. Simultaneously, this hypothetical time taken to compute each VBA hamstrings any node, regardless of computing power, from being able to search collisions expeditiously. This guarantees responsiveness while also protecting addresses. Continuing the above example, 1-millisecond VBA generation times for the most powerful link nodes still equates to attempting only 1,000 spoofed LLIDs per second (3,600,000 LLIDs per hour). If the LLID in this case were an IEEE 802 MAC address, 3.6M attempted MAC addresses is equivalent to only about a millionth of a percent of all possible addresses (2⁴⁸ when not accounting for reserved MAC address ranges).

Concerning Adversaries In an ideal network, VBA deployments would be unnecessary for the purpose of securing address ownership. One sample trust model which may disregard VBA verifications is a small enterprise network for which all LL2IP bindings are entered statically. Another might be a private home network, where on-path attackers are very unlikely to be lurking. The implications of VBA against adversaries should be explored from a broad perspective. Notably, this exploration assumes a hypothetical VBA deployment that is using the AGV IEM to enact full, strict protections on all address bindings. With the context of the design goals of this document, of various ND problem statements (Section 4 of ), and of IPv6 address privacy concerns ( and ): consider how VBA either proposes a resolution for a potential issue or encounters a drawback.

Falsifying Neighbor Discovery Messages Sending Neighbor Advertisements or Solicitations with false link-layer addresses. The sender of a NS can use a false SLLAO, while the sender of a NA can use a false TLLAO. Since NDAR specifies optimizations or instructions to enter these into the Neighbor Cache on receipt (without verification), the protocol becomes vulnerable to abuse. VBA is a way to force this purported binding in NA/NS packets to be verified. This specification dictates that any cache-affecting ND instruction, or optimization to automatically accept link-layer address options, be shimmed with the VBA verification process first. NDAR messages which fail VBA verification are subsequently dropped and do not update the NC, mitigating the issue.

Prolonging Attacks & Lies Asserting a false link-layer address in Neighbor Unreachability Detection packets. Malicious nodes can extend impersonation attacks against the target node by responding to NUD probes, in order to indicate continued reachability. Again, with VBA this attack is not possible because of the imposed verification requirement. If NUD probes detect any changes in cached LL2IP bindings -- e.g., a malicious node responds with an LLID that is different from an original cache entry -- the attack target will drop the packet and will neither update nor refresh its NC with the unverified information.

Tracking Address or Device Activity Correlating unicast address activities in the long-term across networks. discusses four primary issues of deriving IP addresses from LLIDs: network activity correlation, location tracking, address scanning, and device-specific vulnerability exploitation. The applicability of this discussion, however, only applies to addresses from which any off-link actor might derive the LLID directly or somehow become aware of it. VBAs are created using an irreversible hashing function mixed with details available only on-link; therefore, LLIDs are not recoverable by off-link nodes. Stable VBAs do not truly exist unless the active LV is also stable. In such a case, addresses being spawned by the VBA generation process are still pseudo-random in appearance. Nodes employing these addresses also have the option to select a new work factor at any time despite any stable LV details, rotating the used address for a fresh one that is still valid and verifiable.

Forcing Neighbors Offline Nodes who are 'killed' or go offline are impersonated. When a node goes off-link, there is no consequence for a malicious node spoofing its LLID. Since the VBA threat model assumes an insecure link-layer, this remains a persistent problem. VBA is designed primarily to prevent active, transparent spoofing; that is, the quiet arbitration of data between two active neighbors without intercepting or disrupting messages between either party. VBA does not employ PKI to certify LL2IP bindings; rather, it hinges on the principle that two link-layer interfaces on a shared link cannot share the same identifier at the same time without causing noticeable network disruptions.

Hijacking or Desynchronizing Link Vouchers Hijacking the role of link VB can be achieved by a few different means, based on the level of security employed in the local network. Without RA-Guard, false VBs are free to constantly advertise and inject their own rogue LVs onto the network. For neighbors on the network already having an active LV, this is only a problem if VHAs in the LOVMA are not being used and the current LV expires. For neighbors joining the network for the first time, there is a timing opportunity for an abuse of automatic Trust On First Use . If a legitimate VB goes offline and is not able to transmit any updated LVs to the network, then its current LV can expire. When an LV expires, the design of VBA requires nodes to accept any incoming LV as providing direction and consensus for addressing. If a malicious neighbor uses denial-of-service methodologies to force a current VB offline for long enough, then it can force an expiration of the current LV and gain control of it. Relatively short 'Expiration' windows for LVs are disallowed in LVs because of (1) possible time synchronization issues between nodes, (2) 'address generation storm' prevention, and (3) compensating for possibly slow VBs who cannot deliver LVs to the link fast enough. Most relevant to this section are items 2 and 3. The 'address generation storm' prevention relying on this mechanism stops malicious VBs from over-rotating the current LV and exhausting resources of neighbors who will be very busy trying to keep up with VBA generations. Compensating for a slow VB with long 'Expiration' windows requires malicious nodes to force that same legitimate VB off the link for longer in order to take their place. Hijacking, tampering with, or otherwise desynchronizing the LV can be used for either malicious denial-of-service attacks or to set the difficulty of VBA computation to a very low threshold.

Denial of service attacks could result from setting LV parameters to an excessive difficulty. By asking local nodes to verify and generate according to absurd KDF settings, even for low work factor values chosen on each neighbor, absurd amounts of computing resources could be consumed and wasted. This could potentially harbor enough resources on a neighbor to force it offline.
Consider a situation where Group_A represents hosts aware of legitimate LV_A and Group_B represents hosts aware of malicious LV_B. Having multiple LVs active on the same link will inevitably lead to different logical subnetworks, where Group_A hosts are generating and verifying VBAs according to a completely different LV than Group_B. Depending on per-interface IEMs, hosts from one group will be completely barred from communicating with hosts in the other.
Malicious VBs could transmit an LV dictating use of a KDF with very minimal requirements. For example, PBKDF2_SHA256 with an ITERATIONS_FACTOR of 1. Targeting hosts with low work factor values would be most efficient for pre-computing a valid and spoofed LLID that produces an address collision. Undermining the entire subnet in this way affords the attacker a greater advantage by greatly reducing the computation costs of neighbor spoofing.

All of the concerns in this section allude to the importance of guarding the local link from malicious LV options in the first place. Though spoofing attacks are still LESS feasible with VBA enabled, regardless of LV control, that still does not outweigh the risks assessed above. has more information about RA-Guard and protecting against concerns of rogue LVs.

Denial of Service VBA primarily counters spoofing attacks in local networks. Mitigation of NDP denial-of-service attacks is only an auxiliary goal that could be achieved by integrating other protocols or designs. Placing the burden of resolving these problems onto this document could reduce its flexibility and applicability by forcing it to apply specific mitigation strategies rather than leaving them as optional add-ons. This section discusses concerns about potential denial-of-service threats when employing VBA. When a topic is presented without a solution, it is STRONGLY IMPLIED that an implementation of this document SHOULD find and use another solution to mitigate the problem, or at least maintain an awareness of the weakness(es) during development.

Neighbor Solicitation Flooding Section 4.3.2 of outlines an attack targeting last-hop routers that inundates a network with traffic destined to on-link hosts which do not exist. VBAs do not suffer from this attack vector or from any situation involving creation of repeated NS packets, as there is no extra cost incurred in creating them. When a VBA-capable node is receiving a flood of NS packets instead of sending them -- particularly if the NS messages contain spoofed SLLAOs -- then the node may be forced to compute a large volume of verifications in a short interval. This could easily lead to resource exhaustion if the receiving interface's actively stoed LV specifies a more difficult set of KDF settings. A malicious neighbor may also initiate a series of connections from bogus IP addresses that demand return traffic at higher layers of the network stack, such as TCP SYN floods. This would necessitate that the target of the attack engages in NDAR to determine the LLIDs of the supposed initiating IPs if the LLIDs were not provided in NS SLLAOs. If the bogus initiating IPs use high work factors, then the influx of queued work for the verification process could quickly overwhelm the target.

Neighbor Advertisement Flooding NA floods, either with (1) randomized target addresses and TLLAOs or (2) randomized TLLAOs for a known target address, will not affect VBA-capable neighbors. VBA-mandated NC behavior for NAs does not by default permit the presence of an Override flag to affect a cache entry, nor do NAs affect cache entries which have matured beyond the INCOMPLETE state. A more effective attack vector is listed in the previous section. Falsified incoming connections could bait a target node into sending a litany of NS packets, each of which an attacker could reply to with a bogus, high-difficulty VBA to verify.

Link Voucher Over-rotation Large local networks might have thousands of devices on the same logical link using NDP to resolve each others' bindings. When a network is of this size and the active LV is transitioned to another through the election process, optimizations for low-resource neighbors could get excessively costly. Pre-generation of anticipated VBAs according to the new LV parameters would be the primary culprit. To reduce this burden, implementations MAY choose to either limit their optimizations at a certain cache size or pre-generate VBAs only for the most recently contacted, high-throughput neighbors.

Computational Fairness The selection of an appropriate KDF is essential to scale the difficulty of discovering hash collisions. The choice of KDF is also essential for fairness in computing generated interface addresses. A network having widely varying computing resources across nodes will record disparate address generation and verification times when using CPU-bound KDFs instead of choosing Memory-bound KDFs for address calculations . Even when using memory-bound KDFs like Argon2d, the proper delegation of baseline algorithm parameters in the LV SHOULD always tend toward being more forgiving for neighbors with limited resources. The balance of low compute latencies with high security might be difficult to determine. Implementations MAY attempt to discover and apply defaults that achieve this goal as universally as possible.

Static Addresses Networks requiring a mix of ephemeral addresses alongside static, stable, long-term addresses might encounter difficulties deploying and maintaining VBA. Preserving the state of a local LV long-term will not be feasible to maintain stable addresses, since long-term LVs introduce a vulnerability to malicious address collision discoveries. Assigning long-term addresses to neighbors on a VBA-capable network can be accomplished using a few approaches:

Use the AGVL IEM () on either the whole subnet or on interfaces known to interact with the target static address(es) directly. The AGVL IEM will permit per-implementation behaviors to strongly prefer Secured results of NDAR over Unsecured ones, allowing bindings for static addresses to be cached as long as no Secured responses are received. It is not necessary to set AGVL on the interfaces with static addresses (unless such interfaces also interact with other static addresses), because the selected IEM affects neighbor verifications and does not impose restrictions on statically-assigned local interface addresses.
If local nodes simply do not interact with the static addresses, then the only affected parties are the node(s) with the static assignments and the subnet router, which will ostensibly route traffic to and from the static address(es). Most RAs will specify a link-local address as the subnet gateway: if this is the case within the subnet, then only router-to-host traffic will fail VBA verification. This is because the router needs to be aware of the LLID corresponding to the static IP address, but the host forwarding to the router can always safely verify using the router's link-local VBA. Therefore, a static entry in the NC of the router can correlate the appropriate LLID(s) to the static IP address(es) of each neighbor. Doing this for long-term static IP addresses will mitigate any potential spoofing attacks for both neighbors involved while still ensuring that all NDAR transactions with other neighbors still verify according to IEM settings.
Simply use manual NC entries across the whole subnet wherever interactions with the static IP addresses may be required. Doing this abates the need for VBA at all.

Anycast Addresses Anycast addresses are allocated from the unicast address space and are thus indistinguishable to nodes establishing connections to them. NDAR exchanges with these hosts may therefore respond with varying LLIDs and cause VBA verification to be unreliable. For this reason, it is NOT RECOMMENDED to utilize anycast addresses for on-link prefixes within VBA-enabled networks, because the address cannot be successfully bound to any one LLID. The IPv6 Addressing Architecture RFC () outlines a Required Anycast Address in Section 2.6.1. VBA implementations SHOULD maintain compatibility with this requirement by disabling verification for on-link subnet anycast addresses. For example, a node using SLAAC to generate an address in the subnet 2001:db8:700::/64 SHOULD disable VBA expectations and verifications for the address 2001:db8:700::. Because VBA protections must be disabled for this target address, implementations SHOULD avoid using the subnet Required Anycast Address wherever possible.

IANA Considerations This document defines a new Neighbor Discovery Protocol option type and one new link-local multicast address. The introduced Link Voucher option type contains another set of Type-Length-Value (TLV) packet options. The multicast address also uses other assigned TLV packets to convey important (but optional) protocol information. One new Neighbor Discovery Protocol option is defined in this document and must have a new Option Type value assigned in the "IPv6 Neighbor Discovery Option Formats" subregistry of the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry.

The Link Voucher option (63), described in .

The Link Voucher option includes a new option type used to convey KDF algorithm selections. Assigned in the "Algorithm Type Options" subregistry are string identifiers corresponding to integers which indicate their Algorithm Type values. Future values MUST be assigned according to the Standards Action policy of . Default registrations are defined in this document: Initial Values of the "Algorithm Type Options" Subregistry

Type	Name/Identifier
1	VBAKDF_PBKDF2_SHA256
10	VBAKDF_ARGON2D
20	VBAKDF_SCRYPT

See for information about the Local On-link Voucher Multicast Address subscribed to by VBA-enabled network interfaces. This section will also contain specific packet formats. Assigned in the "Link-Local Scope Multicast Addresses" subregistry of the "IPv6 Multicast Address Space Registry":

Address(es): FF02::ABBA
Description: Local On-link Voucher Multicast Address
Reference: draft-puhl-6man-ndp-vba-00

The well-known UDP port 2196 is used for multicast traffic on the LOVMA channel. Assigned in the "Service Name and Transport Protocol Port Number Registry":

Service Name: vba_lovma
Port Number: 2196
Transport Protocol: UDP
Description: IPv6 Voucher-Based Addressing LOVMA updates
Reference: draft-puhl-6man-ndp-vba-00

A set of three TLV packet types used specifically in the new LOVMA channel are defined in this document. Assigned in the "LOVMA Message Types and Options" subregistry of the "Voucher-Based Addressing (VBA) Parameters" registry. The values in the "LOVMA Message Types and Options" subregistry are string identifiers corresponding to integers which indicate their packet Type values. Future values MUST be assigned according to the Standards Action policy of . Default registrations are defined in this document: Initial Values of the "LOVMA Message Types and Options" Subregistry

Type	Name/Identifier	Reference
1	LOVMA_VSR
2	LOVMA_VCI
3	LOVMA_VHA

Future Work This section provides an overview of adjacent topics that might be explored in future work related to this document.

Deployments using DHCP DHCP is not mentioned elsewhere in this document because VBAs are designed primarily for SLAAC-based environments. However, future work might wish to add features into DHCP servers that support VBAs, using something like DHCP Snooping to ensure that only legitimate servers are assigning addresses. Because of its centrality and responsibility, a DHCP server would also be well-suited as the link VB if no connected router supports VBA. One notable change of generating VBAs server-side is the lack of an ability for client nodes to dynamically self-determine a work factor. Allowing nodes to choose their own work factor values affords them the ability to (1) randomize it according to their own decision-making processes and (2) preserve a Preferred Work Factor (see about VSRs). In a future proposal, DHCP client options might be amended to allow a client to request a certain 'security level' as a work factor value. Such an option could also present an opportunity to exchange other information about client preferences or other important VBA details.

Neighbor Discovery Proxies specifies a Neighbor Discovery Proxy as a network-layer device or software used to provide a presence for nodes who have gone off-link or have always been residents off-link. This is supposed to stand in lieu of a classic link-layer bridge. Due to link-layer binding, VBA does not support ND proxying unless the proxy is also able to spoof the LLIDs of all intended target nodes. These spoofed LLIDs would need to appear on the interface attached to the link that it must receive and answer ND packets on. One solution to enabling ND proxy while keeping the rest of the network secure is to apply the same strategy used for static addressing and create manual cache entries. Another solution might be to enable the AVGL IEM on the nodes who are required to transact with the proxy. Support for ND proxies is not very well defined by this document since it conflicts with one of its primary goals. Future experimentation may wish to explore ways to integrate the two concepts seamlessly and securely.

Certifying Link Vouchers Link Vouchers are susceptible to impersonation despite the use of asymmetric cryptography in signing their details. Once a host becomes aware of a valid public-key and signature, it becomes 'locked' to this key and will not accept LVs from senders NOT using it in their signatures (unless the current LV expires or a VHA is issued). However, the point of first contact between a legitimate, authorized VB and its neighbors is still vulnerable. This is because any malicious neighbor could craft its own LV and advertise it if it is not first blocked by infrastructure-based solutions like RA-Guard. Section 6 of dictates the use of a Public Key Infrastructure (PKI) to ensure communication is genuine between hosts and routers, and that each router is authorized to provide router information. Trust anchors are used to determine whether a certificate presented by a router validates its role in SEND: if the router presents a certificate that is trusted by the anchor, then neighbors sharing the same trust anchor will consider it as legitimate. Future additions to this specification MAY invoke PKI and certificates for public-key signatures appearing on LVs. This could include amendments to the LV option which would extend the field to convey trust anchor or certification path information. While this proposal seeks to avoid the complexities introduced by PKI, it might be a crucial consideration for first-contact trust wherever RA-Guard or similar protections cannot be used. This is likely a much more performant use of certification paths than SEND, simply because the trust of a public key only needs to be verified during LV signature verification and not for various NDP messages.

References Normative References Informative References Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER) International Telecommunications Union A Survey of Ethernet LAN Security Department of Communications and Networking, Aalto University, Finland Department of Communications and Networking, Aalto University, Finland Department of Communications and Networking, Aalto University, Finland TOFU for OpenPGP Johns Hopkins GnuPG The Elliptic Curve Digital Signature Algorithm (ECDSA) Certicom Research, Canada Certicom Research, Canada Certicom Research, Canada Recommendation for Password-Based Key Derviation, Part 1: Storage Applications National Institute of Standards and Technology Moderately Hard, Memory-bound Functions University of California at Santa Cruz Google Microsoft Research Microsoft Research

Code Snippets Source code demonstrating the VBA address generation and verification procedures is available at https://github.com/NotsoanoNimus/voucher-based-addressing.

Acknowledgements The author would like to thank Dr. Jinhua Guo of the University of Michigan for his valuable, constructive feedback and support of this work.