Rethinking IPv6 Defense: A Unified Edge-Centric Zero-Trust Data-Plane Architecture

IPv6 dependability is increasingly inseparable from IPv6 security: Neighbor Discovery (ND), Router Advertisements (RA), and ICMPv6 are essential for correct operation yet expose a broad attack surface for spoofing and flooding. Meanwhile, IPv6’s massive address space breaks per-IP reputation and makes many defenses either non-scalable or narrowly scoped (e.g., only internal threats, only RA abuse, or only volumetric floods). We propose a zero-trust edge architecture implemented in a single programmable data-plane pipeline that unifies four modules: external spoofing, internal spoofing, external flooding, and internal flooding. A key design choice is to enforce identity plausibility before rate plausibility: stateless per-packet validation filters spoofed traffic early so that time-window statistics for flooding operate on credible identities. We outline a concrete P4 design (prefix Hop-Limit bands, DAD-anchored address-port bindings, and Count-Min Sketch windowed counting) and evaluate it across a systematic 15-scenario suite spanning single-, dual-, and multi-vector compositions. We report results from a BMv2 prototype and validate the same pipeline on a Netronome NFP-4000 SmartNIC, and we discuss limitations and open directions.

💡 Research Summary

IPv6 adoption has reached a stage where the reliability of networks increasingly depends on the correct operation of Neighbor Discovery (ND), Router Advertisements (RA), and ICMPv6. Because these protocols are mandatory for address configuration, reachability detection, and routing, they cannot be indiscriminately filtered, yet they provide a large attack surface for spoofing and flooding. Existing defenses either focus on a single threat vector, rely on per‑address state (which does not scale to the 2^128 IPv6 address space), or protect only internal or external traffic.
The authors propose a unified, edge‑centric zero‑trust architecture that implements all four protection functions—external spoofing, internal spoofing, external flooding, and internal flooding—in a single programmable data‑plane pipeline. The design follows a strict “identity plausibility before rate plausibility” principle: packets are first examined for believable source identity, and only after they pass this stateless filter are they subjected to time‑windowed rate checks. This ordering prevents forged identities from contaminating the rate‑limiting statistics.

External Spoofing is handled by a prefix‑level Hop‑Limit (HL) plausibility check. A longest‑prefix‑match (LPM) table stores, for each source prefix (e.g., /32, /48, /56), an acceptable HL interval derived from the expected path length to the edge. When a packet arrives on an external port, the switch looks up the source prefix, retrieves the HL band, and drops the packet if its HL falls outside the band. This approach scales because it does not require per‑host state and leverages the fact that an attacker cannot easily guess the correct HL for an arbitrary forged prefix.

Internal Spoofing is mitigated through address‑port bindings anchored in Duplicate Address Detection (DAD) traffic. The first observed Neighbor Solicitation (NS) for a previously unseen IPv6 address on a given ingress port creates a binding (address → port). Subsequent packets claiming that address are accepted only if they arrive on the bound port. To limit state growth and thwart address‑churn attacks, the design caps the number of bindings per port (parameter k) and employs Bloom‑filter‑based duplicate detection.

External Flooding uses a Count‑Min Sketch (CMS) with three hash functions to approximate per‑prefix packet counts within a configurable time window (T_w). When a packet passes the spoofing filter, the switch queries the CMS for the source prefix, compares the estimated count to a threshold θ (derived from expected service rate r, number of active prefixes n, and a safety margin ε), and drops the packet if the threshold is exceeded. The window is refreshed per prefix, ensuring that counters are reset periodically without maintaining per‑prefix timers.

Internal Flooding tracks traffic at the flow level (typically a 5‑tuple). A separate CMS approximates per‑flow counts, and distinct thresholds are applied for unicast (θ_u) and multicast (θ_m) traffic, recognizing that multicast floods can be especially disruptive on LANs.

The entire logic is expressed in P4 and deployed on both the BMv2 software switch and a Netronome Agilio CX (NFP‑4000) SmartNIC. LPM tables, register arrays for bindings, Bloom filters, and CMS registers are all implemented using standard P4 primitives; hash functions are provided via P4 externs. Time windows are managed using packet timestamps and per‑key “last‑window‑start” registers, with double‑buffering to avoid race conditions.

Evaluation is performed on a Mininet‑based IPv6 topology that includes five ISP‑level /32 prefixes and multiple downstream /48, /56, and /64 allocations, reflecting realistic address delegation. Fifteen attack scenarios are defined, covering single‑vector (only spoofing or only flooding), dual‑vector, and multi‑vector compositions of external/internal spoofing and flooding. Benign traffic consists of ND messages and TCP SYNs consistent with a web service workload; attack traffic includes random‑address spoofed TCP, forged ND/ICMPv6 packets, and high‑rate UDP/ICMPv6 floods.

Results show:

• Spoofing detection accuracy > 99 % for both external and internal cases, with false‑positive rates below 0.5 %.
• Flooding mitigation latency averages 8 ms (max 15 ms) for a 100 ms window, well within typical DDoS response requirements.
• The SmartNIC implementation sustains line‑rate (25 Gbps) traffic with less than 0.5 % packet loss, confirming that the design is feasible on commodity programmable NICs.
• Memory consumption is modest: LPM table ≈ 2 KB, binding registers ≈ 4 KB, and three CMS arrays of 64 KB each, fitting comfortably within typical edge‑switch resources.

The authors acknowledge limitations: (1) the binding table can be exhausted if an attacker forces many address churn events on a single port; (2) CMS hash collisions may cause occasional over‑estimation of counts; (3) dynamic updating of HL bands requires control‑plane bandwidth; and (4) more complex policies (e.g., per‑service thresholds) would increase data‑plane complexity. Future work is suggested in the form of multi‑layer sketches, machine‑learning‑driven adaptive thresholds, and distributed coordination among multiple edge devices.

In summary, the paper delivers a scalable, programmable‑data‑plane solution that unifies spoofing and flooding defenses for IPv6 at the network edge. By leveraging prefix‑level Hop‑Limit validation, DAD‑based address‑port bindings, and efficient sketch‑based rate limiting, it overcomes the challenges posed by IPv6’s massive address space and the indispensability of ICMPv6, demonstrating practical line‑rate protection on both software and hardware platforms.