How to secure IPv6 in dual-stack networks without compromising IPv4

Enterprise networks increasingly run IPv4 and IPv6 side by side, but most security controls still focus only on IPv4. When IPv6 is overlooked, attackers can silently hijack traffic using built-in autoconfiguration protocols like SLAAC. In this hands-on lab, we construct a dual-stack enterprise network in GNS3, demonstrate a live IPv6 man-in-the-middle attack using a Python script, and implement RA Guard to shut it down with a single policy change.

Why IPv6 SLAAC is a silent security risk

In IPv4 networks, hosts rely on DHCP or static configuration to obtain an address and gateway. IPv6 adds Stateless Address Autoconfiguration (SLAAC), where routers broadcast Router Advertisements (RAs) and hosts automatically generate their own addresses by combining the router’s prefix with a locally generated interface ID.

This design eliminates manual setup, but it also removes built-in security checks. An attacker on the same link can craft a rogue RA advertising a malicious prefix and themselves as the default gateway. Without any user interaction, every host on the segment will:

• Generate an IPv6 address within the attacker’s prefix
• Set the attacker’s link-local address as its default IPv6 route
• Forward all outbound IPv6 traffic through the attacker

The operating system follows RFC 4862 by design, so victims receive no warnings. This vulnerability exists even when IPv4 defenses like firewalls and ACLs are fully operational, making IPv6 an attractive blind spot for attackers.

Building a dual-stack lab to test real-world attacks

To study this threat in a controlled environment, we built a multi-VLAN enterprise network in GNS3 using Cisco IOSv images. The lab includes a core router, a distribution switch with Layer 2 security controls, and three corporate hosts. An isolated Kali Linux appliance acts as the attacker, connected to a separate VLAN to simulate an insider threat.

Essential components:

• GNS3 2.x with GNS3 VM
• Cisco IOSv router (vios-adventerprisek9-m.vmdk, IOS 15.2(4)S or later)
• Cisco IOSvL2 switch (vios_l2-adventerprisek9-m.vmdk)
• Kali Linux 2024 appliance
• GNS3 VPCS virtual hosts (three corporate clients)
• Python 3 and Scapy 2.5 for the attack script

Before proceeding, verify your IOS version with show version. Older images lack RA Guard support, which is the primary mitigation in this lab.

Designing the network topology and addressing scheme

The lab uses a three-tier design:

• Core router: Handles inter-VLAN routing and dual-stack ACLs
• Distribution switch: Enforces IPv6 security policies like RA Guard and DHCPv6 Guard
• Access layer: Corporate hosts in VLAN 10 and the attacker in VLAN 99

Traffic flows over an 802.1Q trunk carrying VLANs 10 (corporate users), 20 (servers), 30 (IoT/OT), and 99 (attacker segment). The IPv4 addressing uses private ranges, while IPv6 prefixes follow the documentation block 2001:db8::/32—appropriate for labs but replaceable with globally unique addresses in production.

Each VLAN has its own IPv4 subnet and /64 IPv6 prefix, with the router acting as the gateway for both protocols. The core router must have ipv6 unicast-routing enabled; otherwise, IPv6 traffic silently disappears without any error message.

Configuring dual-stack routing and gateway services

On the core router, enable IPv6 routing first:

interface GigabitEthernet0/1
 no shutdown

Then configure sub-interfaces for each VLAN, assigning both an IPv4 and IPv6 gateway address:

interface GigabitEthernet0/1.10
 description "Corp Users - VLAN 10"
 encapsulation dot1Q 10
 ip address 10.1.0.1 255.255.255.0
 ipv6 address 2001:db8:2:10::1/64
 ipv6 enable
 ipv6 nd prefix 2001:db8:2:10::/64

Repeat for VLANs 20 and 30, ensuring each prefix is advertised correctly. The ipv6 nd prefix command tells the router to announce the prefix in RAs, allowing hosts to autoconfigure their addresses.

Deploying parallel ACLs for IPv4 and IPv6

Security policies should treat IPv6 with the same rigor as IPv4. On the core router, we implemented ACLs to restrict traffic between VLANs and block bogus prefixes:

ipv6 access-list CORP-IPV6-IN
 deny ipv6 any any log-input
 permit ipv6 2001:db8:2:10::/64 any
 permit ipv6 2001:db8:2:20::/64 any

This blocks any unexpected IPv6 traffic while permitting legitimate flows between corporate and server VLANs. The same principle applies to IPv4 ACLs, ensuring consistent policy enforcement across both protocols.

Launching and mitigating a live SLAAC hijack attack

With the lab operational, we used Kali Linux to craft a rogue RA using Python and Scapy. The script broadcasts a forged RA with the attacker’s link-local address as the default gateway and a malicious prefix. Within seconds, corporate hosts began generating IPv6 addresses in the attacker’s range and routing traffic through the rogue gateway—all without user intervention.

To neutralize the attack, we enabled RA Guard on the distribution switch. RA Guard filters RAs based on trusted router ports, VLANs, and MAC addresses. Configured correctly, it drops unauthorized RAs before they reach hosts:

ipv6 nd raguard policy CORP-RA-GUARD
 device-role switch
 trusted-port

Applied to the trunk port facing the core router and access ports in VLAN 10, this policy immediately blocked the forged RA. Traffic reverted to the legitimate gateway, and the attack was neutralized with zero changes required on endpoint machines.

Key takeaways for real-world deployment

This lab demonstrates that IPv6 cannot be treated as an afterthought in enterprise security. Organizations should:

• Enable IPv6 routing explicitly on all routers
• Deploy RA Guard and DHCPv6 Guard on distribution switches
• Implement parallel ACL policies for IPv4 and IPv6
• Monitor IPv6 traffic for rogue RAs and unauthorized prefixes
• Include IPv6 in penetration testing and tabletop exercises

By applying the same rigor to IPv6 as to IPv4, security teams can close the silent vulnerability gap and prevent attackers from exploiting autoconfiguration protocols to bypass established defenses.