Implementing and Verifying IPv6 ACLs

From IPv4 to IPv6: What's Different with ACLs?

While the core purpose of an ACL remains the same—to filter packets—Cisco took the opportunity with IPv6 to simplify and streamline the ACL model. Let's look at the main changes.

Based on what we've seen and what you learned about IPv4 ACLs, here are the most important distinctions:

• Named Only: As the image shows, all IPv6 ACLs are named. There are no numbered IPv6 ACLs. This is a welcome change that enforces better readability and manageability from the start.
• Extended Functionality: All IPv6 ACLs have the functionality of an IPv4 extended ACL. They can filter based on source/destination IPv6 address, protocol, and port numbers.
• No Wildcard Masks: You can forget about calculating wildcard masks. IPv6 ACLs use the much more intuitive prefix length (e.g., /64) to specify a network range, just as you do when configuring an IPv6 address on an interface.
• Implicit Rules are Different: This is a crucial point. In IPv4, there is one implicit deny ip any any at the end of every ACL. In IPv6, the situation is slightly more complex to allow for essential IPv6 functionality:
  1. permit icmp any any nd-na (Neighbor Advertisement)
  2. permit icmp any any nd-ns (Neighbor Solicitation)
  3. deny ipv6 any any

These two implicit permit statements are automatically included to allow Neighbor Discovery Protocol (NDP) to function. NDP is IPv6's equivalent of ARP in IPv4, and blocking it would break all Layer 2 to Layer 3 address resolution on a segment. After these two implicit permits, the final implicit deny is still present, blocking all other traffic that isn't explicitly permitted.

Configuring and Applying IPv6 ACLs

The configuration process is straightforward and follows a similar logic to named IPv4 ACLs. We'll use a simple topology to frame our example.

Let's watch a video that demonstrates the full process of configuring, applying, and verifying an IPv6 ACL in a Packet Tracer environment.

As you saw in the video, the process involves three main steps:

1. Create the named ACL: This is done from global configuration mode using the ipv6 access-list <ACL_NAME> command.
2. Define Access Control Entries (ACEs): Inside the ACL configuration mode, you specify your permit and deny statements. The syntax is flexible:
   • To specify a single host: host <ipv6_address>
   • To specify any address: any
   • To specify a network: <ipv6_prefix>/<prefix_length>
   • To specify ports: eq <port>, gt <port>, lt <port>, range <start> <end>
3. Apply the ACL to an interface: This is done in interface configuration mode using the ipv6 traffic-filter <ACL_NAME> {in | out} command.

Here is the syntax from the video, structured as a reference:

! Enter global configuration mode
R1# configure terminal

! Step 1: Create a named IPv6 ACL
R1(config)# ipv6 access-list BLOCK_WEB_TRAFFIC

! Step 2: Add ACEs to deny HTTP and HTTPS to a specific server host
R1(config-ipv6-acl)# deny tcp any host 2001:DB8:1:30::30 eq www
R1(config-ipv6-acl)# deny tcp any host 2001:DB8:1:30::30 eq 443

! Step 2.1: Add the final permit statement (CRITICAL!)
R1(config-ipv6-acl)# permit ipv6 any any
R1(config-ipv6-acl)# exit

! Step 3: Apply the ACL to the source-facing interface
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ipv6 traffic-filter BLOCK_WEB_TRAFFIC in

The "Gotcha": Be Careful with ICMPv6

We mentioned that IPv6 ACLs have implicit permits for Neighbor Discovery. However, ICMPv6 is responsible for much more than that, including Router Solicitations (RS), Router Advertisements (RA), and error messaging like "Destination Unreachable" and "Packet Too Big".

A common and critical mistake is to create an ACL that blocks all ICMPv6 traffic. Doing so can cripple your IPv6 network, preventing hosts from finding their default gateway, discovering the MTU of a path, and performing other essential functions.

Let's read about this common pitfall and how to avoid it.

The key takeaway is that unless you have a very specific reason (like mitigating an ICMP-based attack), you should not block all ICMPv6. Instead, your ACL should explicitly permit the necessary types before any broad deny statements.

Here is a best-practice example, adapted from the article, for a general-purpose IPv6 ACL:

ipv6 access-list IPV6_BASE_POLICY
 ! Permit necessary ICMPv6 for basic network function
 permit icmp any any nd-na
 permit icmp any any nd-ns
 permit icmp any any router-advertisement
 permit icmp any any router-solicitation
 permit icmp any any packet-too-big
 permit icmp any any time-exceeded
 permit icmp any any host-unreachable
 
 ! ... your specific permit/deny rules go here ...
 
 ! Final implicit deny will catch the rest

Notice that we don't need a permit ipv6 any any if our goal is to deny by default. The implicit deny will handle that. If our goal is to deny only a few things and permit the rest, we would add permit ipv6 any any after our deny statements but before the final implicit deny.

Verification

Once your ACL is configured and applied, you must verify it's working as intended. The process is very similar to IPv4.

1. Check the ACL configuration and hit counters: The show ipv6 access-list command is your primary tool. The counters next to each ACE are invaluable for troubleshooting, as they show you which rules are being matched.

2. Confirm the ACL is applied correctly: Use the show ipv6 interface <interface_id> command to ensure the ACL is applied to the correct interface and in the proper direction (in or out).

Let's return to the video to see this verification process in action.

The verification commands from the official Cisco documentation confirm what you saw in the video:

• show ipv6 access-list: Displays all configured IPv6 access lists.
• show ipv6 access-list <ACL_NAME>: Displays a specific access list and its hit counters.

Here's sample output, similar to what you might see after applying an ACL and sending some traffic through it:

Device# show ipv6 access-list inbound
IPv6 access list inbound
    permit tcp any any eq bgp (8 matches) sequence 10
    permit tcp any any eq telnet (15 matches) sequence 20
    deny ipv6 any any (143 matches) sequence 30

Seeing the match counters increment is the definitive way to know your ACL is actively filtering traffic.

Conclusion

In this lesson, we've extended your knowledge of ACLs into the IPv6 world. You've seen how Cisco has simplified the model while retaining powerful, granular filtering capabilities.

Key Takeaways:

• IPv6 ACLs are always named and function like extended ACLs. They use prefix lengths instead of wildcard masks.
• The implicit rules are different: two permit statements for Neighbor Discovery are included before the final deny ipv6 any any.
• Careless filtering of ICMPv6 can break essential network functions. Always permit necessary types like RA, RS, and NDP unless you have a specific security reason not to.
• Configuration involves the ipv6 access-list command, while application uses ipv6 traffic-filter on the interface.
• Verification relies on show ipv6 access-list to check configuration and hit counters, along with functional testing (e.g., ping, browser access).

Preview of the Next Lesson:

We've now covered traffic filtering for both IPv4 and IPv6 using ACLs. Next, we will shift our focus from the data plane to the management plane. In our upcoming lesson, we will configure and verify device access control using TACACS+ for AAA, which is a fundamental technology for securing administrative access to your network devices.