How to Implement IPv6 ACLs on Cisco Routers: Traffic Filtering and Security Configuration

Every network engineer eventually hits the moment where IPv4 access lists just aren’t enough anymore. As IPv6 rolls out across enterprise and service provider networks, securing that traffic with IPv6 access control lists (ACLs) becomes a core skill rather than a nice-to-have. This guide walks through everything needed to design, configure, verify, and troubleshoot IPv6 ACLs on Cisco routers, from the underlying protocol behavior to production-ready deployment patterns.

Why IPv6 ACLs Are Different From IPv4 ACLs

On the surface, IPv6 ACLs look a lot like their IPv4 cousins — permit/deny statements matched against source and destination addresses, protocols, and ports. But there are structural differences that trip up even experienced engineers.

First, IPv6 ACLs are always named, never numbered. There’s no equivalent of access-list 101. Every IPv6 ACL starts with ipv6 access-list NAME.

Second, IPv6 ACLs implicitly permit ICMPv6 neighbor discovery messages (neighbor solicitation and neighbor advertisement) unless you explicitly deny them. This exists because IPv6 relies on ICMPv6 for basic address resolution — the equivalent of ARP in IPv4. If you carelessly deny all ICMPv6 traffic, you can silently break neighbor discovery and Stateless Address Autoconfiguration (SLAAC) on the local segment.

Third, address matching uses IPv6 prefix notation (2001:db8::/32) instead of wildcard masks. There’s no dotted-decimal wildcard mask syntax in IPv6 ACLs — everything is prefix length based, which is arguably more intuitive once you’re used to it.

Finally, every IPv6-enabled interface has an implicit deny at the end of the ACL, same as IPv4, but the implicit permit rules for neighbor discovery sit ahead of that final deny.

IPv6 ACL Types

Cisco IOS and IOS-XE support two main IPv6 ACL types:

• Standard IPv6 ACLs — filter based solely on source address (rarely used in practice since extended ACLs give you far more control at no real cost).
• Extended IPv6 ACLs — filter based on source/destination address, protocol (TCP, UDP, ICMPv6, etc.), port numbers, DSCP, flow labels, and more. This is what you’ll use in virtually every real deployment.

There’s no “extended” keyword needed — any ipv6 access-list you create supports extended matching by default.

Basic Syntax

Router(config)# ipv6 access-list ACL-NAME
Router(config-ipv6-acl)# permit ipv6 any any
Router(config-ipv6-acl)# deny ipv6 any any log

Applying it to an interface:

Router(config)# interface GigabitEthernet0/1
Router(config-if)# ipv6 traffic-filter ACL-NAME in

Note the command is ipv6 traffic-filter, not ip access-group — another common point of confusion for engineers coming from IPv4.

Lab Scenario: Filtering Traffic Between VLANs

Consider an enterprise network with two VLANs:

• VLAN 10 (Users): 2001:db8:10::/64
• VLAN 20 (Servers): 2001:db8:20::/64

The requirement: users can reach the web server on TCP 443, but nothing else in the server VLAN should be reachable from user space. Management access (SSH) should only come from the NOC subnet 2001:db8:99::/64.

ipv6 access-list SERVER-VLAN-IN
 permit tcp 2001:db8:10::/64 host 2001:db8:20::100 eq 443
 permit tcp 2001:db8:99::/64 any eq 22
 permit icmp any any nd-na
 permit icmp any any nd-ns
 deny ipv6 any any log

Apply inbound on the SVI or physical interface facing the server VLAN:

interface Vlan20
 ipv6 traffic-filter SERVER-VLAN-IN in

This ACL explicitly permits neighbor discovery messages even though they’re implicitly allowed, purely for clarity and auditability — a best practice worth adopting since implicit rules don’t show up in show ipv6 access-list counters, making troubleshooting harder.

Protecting the Router Itself: Control Plane Considerations

Router Advertisement (RA) and neighbor discovery traffic deserve special attention. If you’re filtering traffic on an interface where the router itself needs to send/receive RAs (for SLAAC), be careful not to block ICMPv6 type 134 (Router Advertisement) or 133 (Router Solicitation) unless that’s intentional — for instance, to prevent rogue RA attacks from unauthorized hosts.

A common security hardening pattern is to combine IPv6 ACLs with RA Guard rather than trying to block RAs purely via ACL, since RA Guard operates at Layer 2 and is more effective against spoofed RAs on switched segments:

ipv6 nd raguard policy HOST-POLICY
 device-role host
!
interface GigabitEthernet0/1
 ipv6 nd raguard attach-policy HOST-POLICY

For ACL-based control plane protection, use an infrastructure ACL applied to the receive path:

ipv6 access-list INFRA-PROTECT
 permit tcp 2001:db8:99::/64 any eq 22
 permit ospf any any
 permit icmp any any
 deny ipv6 any any log

Advanced Matching: Flow Label, DSCP, and Extension Headers

IPv6 ACLs can match on fields IPv4 ACLs simply don’t have, such as flow label and routing/extension headers:

ipv6 access-list QOS-MARKING-CHECK
 permit tcp any any dscp ef
 permit udp any any dscp af41

You can also filter packets containing IPv6 extension headers, which is a genuine security concern since malformed or excessive extension headers have historically been used to evade inspection or crash devices:

ipv6 access-list DENY-ROUTING-HEADER
 deny ipv6 any any routing
 permit ipv6 any any

Verification Commands

Router# show ipv6 access-list
Router# show ipv6 access-list ACL-NAME
Router# show ipv6 interface GigabitEthernet0/1
Router# show access-list

Sample output:

ipv6 access-list SERVER-VLAN-IN
    permit tcp 2001:DB8:10::/64 host 2001:DB8:20::100 eq 443 (12 matches)
    permit tcp 2001:DB8:99::/64 any eq 22 (4 matches)
    permit icmp any any nd-na (48 matches)
    permit icmp any any nd-ns (52 matches)
    deny ipv6 any any log (17 matches)

Use the match counters to confirm the ACL is actually catching the traffic you expect — an ACL with zero hits on its permit lines but full connectivity usually means it’s applied to the wrong interface or direction.

To debug denied packets in real time (use cautiously in production, as logging can be CPU-intensive):

Router# debug ipv6 packet

Common Configuration Mistakes

• Forgetting the implicit deny. Just like IPv4, an IPv6 ACL with only permit statements still ends in an implicit deny-all. Engineers used to relying on that final deny for IPv4 often forget to add permit icmp any any nd-na and nd-ns, which silently breaks neighbor discovery.
• Applying the ACL in the wrong direction. in versus out matters just as much as it does in IPv4 — verify against the direction of the traffic you actually want to control.
• Confusing ipv6 traffic-filter with ip access-group. These are not interchangeable; using the wrong command simply fails silently or throws a syntax error.
• Using standard ACLs for anything beyond trivial address filtering. Extended ACLs give you the same performance with far more flexibility — there’s little reason to reach for standard IPv6 ACLs in modern deployments.
• Not logging denies during initial rollout. Add log to your deny statements while you’re validating a new ACL, then remove it once the policy is confirmed stable, since excessive logging affects CPU on high-traffic interfaces.

Best Practices for Production Deployment

1. Build ACLs in a lab or with ipv6 access-list ... resequence staging before touching production interfaces.
2. Always explicitly permit ND traffic, even though it’s implicit — this documents intent and shows up in counters.
3. Use object-style naming conventions (e.g., VLAN20-IN, MGMT-SSH-ONLY) so ACL purpose is clear from show run output alone.
4. Apply infrastructure ACLs on edge and core routers to protect the control plane from unauthorized management access.
5. Pair ACLs with RA Guard and DHCPv6 Guard at the access layer rather than relying purely on Layer 3 ACLs for first-hop security.
6. Test failover scenarios — if you’re running HSRP/VRRP for IPv6, confirm the ACL doesn’t inadvertently block FHRP multicast traffic on ff02::/16.

Troubleshooting Checklist

• Confirm the ACL is applied: show ipv6 interface | include ACL
• Confirm the direction matches intended traffic flow.
• Check match counters after generating test traffic.
• Verify neighbor discovery isn’t broken: show ipv6 neighbors.
• If SLAAC-based hosts lose connectivity after applying an ACL, check for accidental blocking of RA/RS ICMPv6 types.
• Use ping ipv6 and traceroute ipv6 from a test host to confirm expected permit/deny behavior end to end.

FAQs

Do IPv6 ACLs support wildcard masks like IPv4? No. IPv6 ACLs use prefix-length notation exclusively (/64, /48, etc.).

Can I use the same ACL name for both an IPv4 and IPv6 ACL? Yes, IPv6 ACL names exist in a separate namespace from IPv4 numbered/named ACLs, so there’s no conflict, though using distinct names avoids confusion during troubleshooting.

Will denying all ICMPv6 break IPv6 entirely? Yes, if you deny ICMPv6 outright without permitting ND, you break address resolution on the segment. Always carve out explicit permits for nd-na, nd-ns, and typically RA/RS types where SLAAC is in use.

Are IPv6 ACLs processed in hardware on platforms like ASR or Catalyst switches? On most modern platforms (ASR1000, Catalyst 9000 series) IPv6 ACLs are processed in hardware via TCAM, similar to IPv4, so performance impact is minimal when properly designed. Older platforms or software-based paths may see more CPU overhead — check the platform-specific hardware forwarding documentation.

Can I apply an IPv6 ACL to a VTY line for management access control? Yes:

line vty 0 4
 ipv6 access-class ACL-NAME in

Summary

IPv6 ACLs are a foundational tool for securing modern dual-stack and IPv6-only networks. While the syntax parallels IPv4 ACLs closely, the differences — named-only ACLs, prefix-based matching, the ipv6 traffic-filter command, and the implicit permit for neighbor discovery — matter enough to catch out anyone who treats IPv6 ACLs as a copy-paste exercise. Building ACLs deliberately, testing neighbor discovery behavior, logging during rollout, and combining Layer 3 ACLs with Layer 2 protections like RA Guard gives you a defense-in-depth posture that scales from a small branch office to a full enterprise core.

References

• Cisco IOS IPv6 Command Reference: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-book.html
• Implementing Traffic Filtering for IPv6: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/configuration/xe-16/ipv6-16-book/ip6-traffic-filter.html
• IPv6 First-Hop Security Configuration Guide: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-x/configuration_guide/ipv6/b_17_ipv6_9300_cg.html