Dual Stack Networking: What It Is and What Are the Risks

Dual stack networking is when IPv4 and IPv6 run at the same time across your hosts, routers, and services. It’s the most common “transition” approach to IPv6, but it also means you must secure both protocol families equally—otherwise you can unintentionally create an IPv6 “shadow network” with weaker controls.

How dual stack networking works

In a dual stack environment, endpoints typically have both an IPv4 address and an IPv6 address, and the network carries both IPv4 and IPv6 traffic. Which protocol gets used is often decided automatically by the OS and application behavior—something defenders often discover only after an incident.

Addressing and configuration (host side)

A dual-stacked host commonly gets:

• IPv4 via static config or DHCPv4 (often behind NAT at the edge).
• IPv6 via one (or more) of:
• SLAAC (Stateless Address Autoconfiguration) using Router Advertisements (RA)
• DHCPv6 (stateful IPv6)
• Static IPv6 assignment

Many operating systems will prefer IPv6 when it’s available (exact preference depends on OS policy, RFC 6724 rules, and local configuration).

DNS behavior and protocol selection (A vs AAAA)

DNS can return:

• A records (IPv4)
• AAAA records (IPv6)

If a hostname has both A and AAAA, many clients will attempt IPv6 first, then fall back to IPv4 if IPv6 fails. Modern “happy eyeballs” behavior (RFC 8305) can race both paths to reduce latency—good for UX, but it means IPv6 paths get exercised even when you think “we’re mostly IPv4.”

Routing and security controls (network side)

At the network layer, dual stack means:

• Routers run both IPv4 routing and IPv6 routing
• Firewalls and ACLs must be configured for both protocol families
• Monitoring systems must parse and alert on both IPv4 and IPv6 flows

Operationally, IPv6 is not “IPv4 with longer addresses.” Neighbor Discovery replaces ARP, ICMPv6 is essential for IPv6 to function, and NAT is usually not part of the design. That changes both how traffic behaves and how attacks manifest.

Practitioner takeaway: why dual stack can increase risk

Dual stack can effectively create two networks on the same wires. If your tooling, policy, or staff coverage only fully addresses IPv4, you can end up with:

• IPv6 routes you didn’t intend
• IPv6 traffic that bypasses IPv4-focused firewalls/proxies
• Logging blind spots (no IPv6 in SIEM/NetFlow/DNS logs)
• Asset inventory gaps (devices/services reachable over IPv6 only)

When you’ll encounter dual stack networking

Dual stack is common anywhere organizations want IPv6 capability without breaking IPv4-dependent systems.

Enterprise LANs and Wi‑Fi

Many managed networks enable IPv6 by default or partially (e.g., link-local IPv6 everywhere, global IPv6 on some VLANs). You’ll see dual stack when:

• Corporate Wi‑Fi provides IPv6 (often via SLAAC)
• Guest networks offer IPv6 even if internal segments do not
• New switches/routers advertise IPv6 prefixes by default

Cloud and hosting

Major cloud platforms and CDNs support IPv6, and many services are reachable over both protocols. Dual stack shows up when:

• Load balancers publish both A and AAAA records
• Kubernetes nodes/pods are configured for dual stack
• Apps are “IPv6-ready” but security groups/firewall rules are not

ISPs and branch connectivity

ISPs frequently provide IPv6 alongside IPv4, and CPE routers may enable IPv6 automatically. You’ll encounter dual stack in:

• Branch offices using business broadband
• SD-WAN underlays that include IPv6 reachability
• Remote worker networks where home routers hand out IPv6 prefixes

SaaS access and external services

Even if your internal network is “IPv4 only,” endpoints may still use IPv6 on external networks. If your security model assumes traffic goes through an IPv4 proxy/VPN, dual stack can be a problem when IPv6 takes a direct path.

If you’re also evaluating endpoint protections that understand modern network paths (including IPv6-aware telemetry), see our comparison: best antivirus for Windows business endpoints.

Security risks of dual stack networking (and what to do next)

The risks are less about IPv6 itself and more about mismatched governance between the stacks.

1) Shadow IPv6 paths that bypass controls

Risk: IPv6 connectivity exists, but your egress filtering, proxy enforcement, or IDS/IPS coverage is IPv4-centric. Endpoints may reach the internet over IPv6 even when IPv4 is restricted, or they may reach internal services over IPv6 that weren’t intended to be exposed.

What to do:

• Enforce policy parity: whatever you block/allow/inspect on IPv4, replicate on IPv6.
• Validate egress: ensure IPv6 traffic traverses the same choke points as IPv4.

2) Firewall/ACL gaps due to separate rule sets

Risk: Teams maintain mature IPv4 rules but forget IPv6 equivalents. Some platforms treat IPv4/IPv6 policies separately (e.g., different security groups, ACL tables, or UI tabs). Result: “default allow” on IPv6 in places you didn’t review.

What to do:

• Audit rules for both families and require change control to include IPv6 checks.
• Prefer “deny by default” for IPv6 where appropriate, then open explicitly.

3) Neighbor Discovery / RA abuse on local networks

Risk: IPv6 uses Router Advertisements and Neighbor Discovery. A malicious or misconfigured device can send rogue RAs, causing clients to adopt attacker-controlled gateways or DNS, enabling interception or traffic redirection.

What to do:

• Use RA Guard / DHCPv6 Guard / ND inspection features on managed switches.
• Restrict who can be a router on access VLANs.
• Monitor for unexpected RAs and prefix changes.

4) Monitoring and incident response blind spots

Risk: Your logs and detections may not normalize IPv6 addresses, may not ingest AAAA DNS queries, or may ignore ICMPv6 signals. Analysts may not recognize IPv6 literals in alerts or may lack allow/deny lists for IPv6.

What to do:

• Ensure telemetry sources (firewall, proxy, DNS, EDR, NetFlow/IPFIX) include IPv6.
• Update SIEM parsing and detection logic for IPv6 fields and CIDRs.
• Train responders to interpret IPv6 and common IPv6 log formats.

A practical way to reduce exposure during response is to ensure your threat intel and detections consistently use Indicators of Compromise; see what is an IOC? for a quick refresher and examples.

5) Application and configuration assumptions

Risk: Some apps bind to :: (all IPv6 interfaces) and inadvertently accept external connections over IPv6 when IPv4 is restricted. Alternatively, services may expose management ports on IPv6 only, escaping IPv4-only scanners.

What to do:

• Scan and inventory on both IPv4 and IPv6.
• Review service bind addresses and listen sockets for IPv6 exposure.

6) Misuse of transition mechanisms

Risk: Even in “dual stack,” you may also have transition tech like tunnels (6in4, Teredo, ISATAP) or translation (NAT64/DNS64) in the mix. Tunnels can create covert paths; translation can complicate attribution and logging.

What to do:

• Disable legacy tunneling on endpoints where not needed.
• Document and monitor NAT64/DNS64 if used; ensure logs preserve client identity.

Quick checks to confirm dual stack (and whether IPv6 is actually used)

Use these to verify dual stack networking is present and to spot gaps in IPv6 visibility.

Check addresses and routes

# Linux: show addresses and routes
ip -br addr
ip -6 route

# Windows: show IPv6 config and routes
ipconfig /all
netsh interface ipv6 show route

# macOS: check IPv6 addressing
ifconfig | grep -E "inet6|inet "
netstat -rn -f inet6

Validate DNS behavior (AAAA vs A records)

# Does the name have IPv6 (AAAA) records?
nslookup -type=AAAA example.com
dig AAAA example.com +short
dig A example.com +short

Test actual IPv6 connectivity

# IPv6 ping (ICMPv6)
ping -6 ipv6.google.com

# Prefer IPv6 in curl (if available)
curl -6 https://example.com/ -I
curl -4 https://example.com/ -I

What to look for in logs

Search for:

• Source/destination containing : (IPv6 literal)
• Fields like src_ipv6, dst_ipv6, ipv6, AAAA
• ICMPv6 types (e.g., Neighbor Solicitation/Advertisement, Router Advertisement)

Hardening checklist (practical, high-impact)

• Firewall parity: mirror IPv4 policies in IPv6 (ingress and egress).
• Default-deny where appropriate: avoid “implicit allow” on IPv6 interfaces/VLANs.
• RA/ND protections on access networks: RA Guard, DHCPv6 Guard, ND inspection.
• Inventory + scanning: ensure vulnerability and port scans cover IPv6 space.
• Telemetry parity: SIEM, DNS logs, flow logs, and EDR should ingest and normalize IPv6.
• Disable unused tunnels: Teredo/ISATAP/6to4 where not explicitly required.
• Runbooks: include IPv6 blocks, allowlists, and containment steps (not just IPv4).

Recommended tools (optional, if you need them)

If dual stack introduces more “direct to internet” paths than you intended (especially for remote staff), a business VPN can help enforce consistent egress and reduce split-path surprises. Options to consider include NordVPN (Check NordVPN pricing →) or Surfshark (Try Proton VPN →)—just ensure IPv6 handling is explicitly tested in your environment (DNS, kill switch behavior, and routing).

For endpoint malware cleanup and visibility on laptops that roam across networks, Malwarebytes can be a pragmatic add-on in some stacks (Get Malwarebytes →). And for identity hardening (often the first thing attackers go after once they find an unmonitored path), consider a team password manager like 1Password (Try 1Password →).