Every enforcement mechanism in Neurowall — whitelist, blocklist, custom rules, DDoS flood gates — exists as a parallel, independent implementation for both IPv4 and IPv6, including full IPv6 extension header parsing. Neither protocol is the primary path with the other bolted on.
Plenty of firewalls added IPv6 support as an afterthought — basic pass/drop filtering, without the same rule richness, DDoS protection, or extension-header awareness that IPv4 traffic gets. As IPv6 adoption grows, a firewall that treats it as a second-class path leaves a real gap in coverage that's easy to overlook until it's exploited.
Mobile carriers, cloud providers, and modern ISPs increasingly default to IPv6 — a firewall with weaker IPv6 coverage is weaker coverage for a growing share of real traffic, not a hypothetical edge case.
IPv6's extension header chain (Hop-by-Hop, Routing, Fragment, Destination Options, and more) can be abused to obscure the actual payload from naive parsers — a firewall that doesn't walk the chain can miss what it's actually filtering.
A flood attack over IPv6 is just as real as one over IPv4 — DDoS mitigation that only covers IPv4 leaves half the address space unprotected against the exact attack it exists to stop.
Most real networks run dual-stack today — a rule that only reliably applies to one protocol family creates policy that's inconsistent depending on which protocol a client happens to use.
Every enforcement structure in the fast packet-filtering layer is duplicated per address family rather than sharing one generic implementation — a deliberate design choice that keeps IPv4 and IPv6 as equally first-class paths through the same filtering steps.
Whitelist and blocklist prefix matching each have independent IPv4 and IPv6 lookup structures, sharing the same entry limits and lookup logic — a CIDR block or allow entered for one family has no effect on the other, and vice versa.
Custom rules are matched against family-specific maps, so a rule targeting an IPv6 range is evaluated with the same rule-matching logic as an IPv4 rule — not routed through a shared, protocol-agnostic path that might handle one family less precisely.
The DDoS tail-call stages (header validation, then flood gates for SYN/ACK/ICMP/FIN/RST) exist as distinct IPv4 and IPv6 program targets, both reachable from every DDoS-inclusive pipeline profile described in Pipeline Profiles.
IPv6 packets are parsed through their full extension header chain to reach the final protocol, port, and fragment metadata that rules and DDoS logic actually need — not just the fixed header, which alone can hide the real payload type.
IPv6's extension header mechanism means the "real" upper-layer protocol can sit behind a chain of optional headers. Neurowall's parser walks that chain to find it — capped at a fixed maximum so a maliciously long header chain can't be used to exhaust parsing time as its own denial-of-service vector.
| Extension header type | Handling |
|---|---|
| Hop-by-Hop Options | Parsed and walked past to reach the next header |
| Routing Header | Parsed and walked past to reach the next header |
| Fragment Header | Parsed — fragment metadata extracted for rule/DDoS matching |
| Destination Options | Parsed and walked past to reach the next header |
| ESP / AH (encrypted/authenticated) | Recognized in the chain walk; final protocol identified without needing to decrypt payload |
| Chain length | Capped at a fixed maximum extension count — bounds worst-case parsing cost per packet regardless of how long an attacker-crafted chain is |
| Common pattern | Where it falls short |
|---|---|
| IPv6 as a pass/drop-only path | Basic allow/deny works, but the richer rule engine, DDoS heuristics, and threat-intel blocking that IPv4 traffic gets aren't fully available for IPv6 |
| Fixed-header-only parsing | Extension headers are ignored or only partially walked — traffic that hides its real protocol behind a header chain can slip past rules expecting to see it directly |
| Unbounded extension header walking | Without a cap, a crafted packet with an excessively long header chain can be used to burn CPU time in the parser itself — a DoS vector inside the DoS-protection layer |
| Shared IPv4/IPv6 rule tables with implicit coercion | Address-family ambiguity in a shared table can produce subtly wrong matches — an IPv6 address string handled by logic written and tested primarily against IPv4 assumptions |