FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses
Extracted elements (25)
Address ownership under FCFS SAVI follows the First-Come, First-Served principle: the first host to claim a source address (observed at a binding anchor) is treated as the owner. Proof of ownership is established by binding the IP address to the Layer 2 switch port through which it was first seen.
FCFS SAVI distributes binding state across devices: each FCFS SAVI device stores only bindings for source addresses arriving through its own Validating Ports. NS/NA messages are used to maintain coherency so no two devices bind the same IP address to different anchors simultaneously.
FCFS SAVI is scoped only to locally assigned IPv6 addresses (SLAAC/DAD-based) and validates only local traffic. Transit traffic from routers is explicitly out of scope; ingress filtering (RFC 2827) is recommended to complement FCFS SAVI for that traffic class.
FCFS SAVI requires no changes to hosts whose source addresses are verified. All validation relies solely on existing protocols (Neighbor Discovery, DAD); no new protocol messages or altered host behavior are defined.
The specification recommends that the SAVI device generate DAD_NS messages upon receiving a data packet with no binding (rather than simply discarding it) to avoid disconnecting legitimate hosts whose DAD packets were lost due to spanning-tree delays, 802.1X authentication timing, SAVI device reboots, or topology changes. Silently dropping packets would violate the end-to-end fate-sharing principle by making host connectivity depend on SAVI device state.
Untrusted routers (e.g., a mobile phone acting as a router on a Validating Port) are not supported by the default FCFS SAVI specification: their transit traffic carries off-link source addresses that would be dropped by Validating Port checks. Supporting such scenarios would require a new port type or manual configuration.
When Secure Neighbor Discovery (SEND, RFC 3971) is deployed, FCFS SAVI is incompatible because the SAVI device must generate DAD_NS messages but lacks the host's private key required to sign them. SEND SAVI should be used instead of FCFS SAVI in SEND environments.
An FCFS SAVI device MUST support two methods for populating the Prefix List: manual configuration and learning on-link prefixes from Router Advertisement messages received on Trusted Ports. It MUST also send a Router Solicitation on boot using the unspecified source address.
FCFS SAVI-capable devices MUST be deployed forming a connected perimeter so that no data packet can enter the protected realm without passing through an FCFS SAVI device.
If an FCFS SAVI device supports customer VLANs (IEEE 802.1Q), it MUST behave as if there is one independent FCFS SAVI process per customer VLAN, with separate binding state per VLAN.
In TENTATIVE state, if a Neighbor Advertisement for the address is received on a Trusted Port, the binding is cleared and state returns to NO_BIND; stored data packets are discarded. This prevents a racing host from hijacking the address.
Only switch ports MUST be used as binding anchors. Other forms of binding anchors (e.g., MAC addresses) are out of scope; their spoofability could open new DoS vectors if used with packet dropping.
Ports connected to other FCFS SAVI devices and ports connected to routers MUST be configured as Trusted Ports. Ports connected to hosts SHOULD be configured as Validating Ports; untrusted hosts MUST be on Validating Ports.
The FCFS SAVI device MUST join the solicited-node multicast group for every address in a state other than NO_BIND, so that DAD_NS packets for those addresses are reliably received even if the originating host has moved.
The FCFS SAVI device MUST limit the memory used to store buffered data packets (during DAD verification) so other device functions retain available memory even under attack. It MUST also perform per-port rate limiting of DAD_NS messages it generates to prevent amplification attacks.
Upon receiving a data packet on a Validating Port with no existing binding (NO_BIND state), the SAVI device SHOULD execute DAD on behalf of the address (2 NS messages, T_WAIT apart). The device MUST NOT forward data packets until the binding has been verified; packets MAY be stored or discarded in the interim.
When a data packet with a source address outside any on-link prefix arrives on a Validating Port (transit traffic), the packet SHOULD be discarded. Logging or alarms MAY be used as an alternative; an ICMPv6 Destination Unreachable (code 5) MAY be sent back.
Personally identifying information (PII), including MAC addresses, MUST NOT be stored in the FCFS SAVI DB except during an identified attack attempt. Implementations MUST NOT log binding anchor information unless there is specific reason to believe it is involved in source address spoofing; information MUST be deleted as soon as the address state returns to NO_BIND.
Default timer values: TENT_LT (tentative lifetime) = 500 ms; DEFAULT_LT (valid binding lifetime) = 5 minutes; T_WAIT (DAD retransmit interval used by SAVI device) = 250 ms. Implementations MAY allow these to be modified.
FCFS SAVI devices have two port types: Validating Ports (VPs), where FCFS SAVI processing and filtering are applied, and Trusted Ports (TPs), where packets are forwarded without SAVI validation. Routers and inter-SAVI links use TPs; hosts use VPs.
The FCFS SAVI database (DB) stores per-address binding entries containing: IP source address, binding anchor (port), lifetime, status (TENTATIVE, VALID, TESTING_VP, or TESTING_TP-LT), and creation time. A separate FCFS SAVI Prefix List records on-link prefixes and their associated interfaces.
An attacker can destroy a legitimate binding by preventing the bound host from replying to a DAD_NS (e.g., intercepting the NA or DoS-ing the host). If no NA is seen from the original binding anchor, the SAVI device may grant the binding to the attacker's port.
An attacker can exhaust FCFS SAVI DB memory by sending packets with many distinct source addresses. When memory is full, it is RECOMMENDED to evict entries with the highest creation time (newest first), preserving older legitimate entries. Per-port memory reservations (minimum 4 bindings per port) are also RECOMMENDED to isolate DoS effects.
If multiple hosts share a binding anchor (e.g., all are behind a legacy non-SAVI switch on a single Validating Port), they can spoof each other's IP addresses without detection. This residual threat is inherent when binding anchors are shared; it can be avoided by not sharing anchors.
The FCFS SAVI binding state machine for each (IP address, device) pair has five states: NO_BIND (no binding exists), TENTATIVE (DAD in progress), VALID (binding confirmed and usable for filtering), TESTING_TP-LT (DAD_NS received from Trusted Port or lifetime expiring), and TESTING_VP (conflicting DAD_NS or data packet from a different Validating Port). Transitions are triggered by reception of DAD_NS, data packets, NA messages, and timer expiry.