Imagine deploying a shiny new IPv6 ACL on your border router to block unwanted traffic, only to find that legitimate users can't reach critical servers. IPv6 ACLs behave differently from IPv4 ACLs in subtle ways—especially regarding implicit rules, ICMPv6 handling, and extension headers. On the CCNA 200-301 exam (objective 5.6), you must diagnose why an IPv6 ACL is blocking traffic when it shouldn't be. This chapter arms you with a systematic troubleshooting approach, covering common misconfigurations, verification commands, and the 'gotchas' that trip up even experienced engineers.
Jump to a section
Think of an IPv6 ACL as a security guard at the entrance of a museum. The guard has a clipboard with rules: 'Allow visitors with tickets (permit), deny anyone without (deny).' But the guard also has a special rule: 'Always allow the museum director (implicit permit for certain traffic).' In IPv4 ACLs, the guard automatically lets in anyone who doesn't match a deny rule (implicit permit all). In IPv6 ACLs, the guard's default is to deny everyone unless explicitly allowed (implicit deny all). This is a critical difference. Now, imagine the museum has a policy that staff must always be allowed to enter, but the guard's clipboard doesn't list them individually—it's an unwritten rule (implicit permit for ICMPv6 neighbor discovery and certain other traffic). However, if the guard sees a visitor carrying a strange package (IPv6 extension headers), the guard might get confused and block them even if the main rule says 'allow.' In IPv6, extension headers (like Hop-by-Hop, Routing, Fragment) are part of the packet but are not inspected by the ACL unless you explicitly configure it. So, a packet with a valid destination might be blocked because the ACL doesn't understand the extension header. The guard's training (ACL logic) processes rules in order from top to bottom. Once a rule matches, action is taken and no further rules are checked. If no rule matches, the packet is denied (implicit deny). But the guard has a secret list of 'always allow' exceptions (implicit permit for ICMPv6 ND, etc.) that are checked before the implicit deny. Misunderstanding these implicit rules is the number one cause of blocked traffic.
An IPv6 Access Control List (ACL) is a sequential list of permit or deny statements that filter IPv6 packets based on source/destination addresses, protocol, port numbers, and other fields. Cisco IOS supports two types: Router IPv6 ACL (applied to interfaces with ipv6 traffic-filter) and Port ACL (applied to switch ports with ipv6 port-security or similar). The primary purpose is security—blocking unwanted traffic, limiting access to network segments, and preventing attacks. On the CCNA exam, you must know how to configure and troubleshoot IPv6 ACLs, especially why traffic gets blocked unexpectedly.
How IPv6 ACLs Work Step by Step
When a packet arrives at an interface with an inbound IPv6 ACL, the router performs these steps:
1. Check for Implicit Rules: Before processing user-defined entries, the router applies two implicit permit statements at the end of every IPv6 ACL:
- permit icmp any any nd-na (Neighbor Advertisement)
- permit icmp any any nd-ns (Neighbor Solicitation)
- permit icmp any any router-advertisement (if configured)
- permit icmp any any router-solicitation (if configured)
These ensure that IPv6 Neighbor Discovery (ND) and Router Discovery work; otherwise, devices couldn't find each other.
2. Process User-Defined Entries: The ACL is traversed from top to bottom. For each entry, the router checks if the packet matches the source/destination, protocol, and ports. If a match is found, the action (permit/deny) is executed immediately. If no match, the next entry is checked.
3. Implicit Deny: If the packet reaches the end without matching any entry, it is denied. This is a key difference from IPv4 ACLs, which have an implicit permit at the end.
Key States, Timers, and Defaults
Implicit Permit for ICMPv6 ND: Always present. Do not try to remove it; it's built-in.
No Implicit Permit for Other ICMPv6: Unlike IPv4, where ICMP echo is often allowed by default, IPv6 ACLs deny all other ICMPv6 types unless explicitly permitted.
Order of Entry: The order is critical—Cisco IOS does not reorder entries. Always add new entries at the end unless you use sequence numbers.
Sequence Numbers: Each entry has a sequence number (default increments by 10). You can insert or delete entries by sequence number.
Maximum Entries: Varies by platform; typically 1000-2000 entries per ACL.
IOS CLI Verification Commands with Real Example Output
To verify an IPv6 ACL, use:
show ipv6 access-list
show ipv6 interface [interface]
show running-config | section ipv6 access-listExample output for show ipv6 access-list:
IPv6 access-list BLOCK_SSH
permit tcp any host 2001:db8:1::10 eq 22 (10 matches) sequence 10
deny ipv6 any any (100 matches) sequence 20To see if the ACL is applied to an interface:
show ipv6 interface GigabitEthernet0/0Look for: Inbound IPv6 ACL: BLOCK_SSH
How It Interacts with Related Protocols
ICMPv6: As mentioned, ND messages are implicitly permitted. Other ICMPv6 types (echo, destination unreachable, etc.) are denied unless explicitly allowed. This is a common cause of troubleshooting issues—ping fails because ICMPv6 echo is blocked.
IPv6 Extension Headers: The ACL processes only the base IPv6 header and, for TCP/UDP, the Layer 4 header. Extension headers (e.g., Hop-by-Hop, Routing, Fragment) are not examined unless you use the routing, hop-by-hop, or dest-option keywords. A packet with a Routing extension header might be blocked if the ACL has a deny for ipv6 any any because the router sees the extension header as part of the packet but the ACL doesn't understand it—actually, the router still matches the base header, so a permit for the destination should work. But if you have a deny for ipv6 any any, it will match regardless of extension headers.
Fragmentation: IPv6 fragmentation is handled differently. Only the first fragment contains the Layer 4 header; subsequent fragments have only the Fragment extension header. An ACL that matches on Layer 4 ports will not match subsequent fragments, so they may be permitted or denied based on the base header. Use the fragments keyword to control fragment handling.
Common Misconfigurations
Missing permit for ICMPv6: If you have an ACL that permits only TCP port 80, ping will fail. You need explicit permit for ICMPv6 echo.
Wrong order: A deny entry placed before a permit for the same traffic will block it.
Typos in IPv6 addresses: IPv6 addresses are long; a single hex digit error can cause a mismatch.
Applying ACL to wrong interface/direction: Inbound vs outbound—if you apply inbound, it filters traffic coming into the interface; outbound filters traffic leaving.
Trap Patterns for the Exam
Implicit permit vs deny: Candidates often forget that IPv6 ACLs end with implicit deny, not permit. They might think a permit entry at the end is needed, but actually, if you have no permit, everything is denied.
ICMPv6 ND is always permitted: Even if you have a deny all, ND messages still get through. This is a trick: the ACL may show 'deny ipv6 any any' but ND still works.
Sequence numbers: You can insert a permit before a deny using a sequence number. The exam might ask which entry will be matched first.
Summary
IPv6 ACLs are powerful but require careful planning. Always verify with show ipv6 access-list and test with ping/traceroute. Remember the implicit permits for ND, and explicitly permit other ICMPv6 types if needed.
Identify the Symptom
Begin by determining what traffic is being blocked. Is it a specific application (e.g., SSH, HTTP) or all traffic? Use `ping` and `traceroute` from a test host to the target. If ping fails but other services work, the issue is likely ICMPv6 being blocked. If all traffic fails, check if the ACL is applied correctly. Also, verify if the traffic is inbound or outbound on the router interface. Use `show ipv6 interface [interface]` to see which ACLs are applied and in which direction. For example: `show ipv6 interface GigabitEthernet0/0` will show 'Inbound IPv6 ACL' and 'Outbound IPv6 ACL' lines. If an ACL is applied, note its name.
Examine the ACL Configuration
Display the ACL using `show ipv6 access-list [acl-name]`. Look at the order of entries. Check if there is a permit entry for the desired traffic. If the ACL ends with `deny ipv6 any any`, that will block everything not explicitly permitted. Also check if there are any entries with `log` keyword that might indicate hits. For example, if you see `permit tcp any host 2001:db8:1::10 eq 22 (0 matches)`, it means no SSH traffic has matched yet—so maybe the traffic is not reaching the router or the ACL is on the wrong interface. Also, look for implicit entries—they are not shown, but you must remember they exist. Use `show running-config | section ipv6 access-list` to see the full configuration.
Verify ACL Application and Direction
Confirm that the ACL is applied to the correct interface and direction. Use `show ipv6 interface [interface]` and check for the ACL name under 'Inbound IPv6 ACL' or 'Outbound IPv6 ACL'. If the ACL is applied inbound on the interface facing the source, it filters traffic coming into the router. If outbound, it filters traffic leaving the router. Common mistake: applying an inbound ACL when you meant outbound. Also, ensure the interface is not a Layer 2 switch port—IPv6 ACLs cannot be applied to switchports; you need to configure a VLAN interface or use a Layer 3 interface. For switchports, use port ACLs with `ipv6 port-security` or `mac access-group` (but that's different).
Check for Implicit Deny of ICMPv6
If ping fails but other TCP/UDP services work, the likely cause is that ICMPv6 echo request/reply are not explicitly permitted. Remember, IPv6 ACLs have implicit permit only for Neighbor Discovery ICMPv6 types (133-137). All other ICMPv6 types, including echo (type 128) and echo reply (type 129), are denied unless you add a permit statement. To fix, add a permit entry for ICMPv6 echo: `permit icmp any any echo-request` and `permit icmp any any echo-reply`. Or more broadly: `permit icmp any any` to allow all ICMPv6 (but be careful—this may be too permissive). Use `show ipv6 access-list` after adding to confirm matches.
Inspect for Extension Header Issues
Some IPv6 packets carry extension headers (e.g., Routing, Fragment, Authentication). By default, IPv6 ACLs process the base header and Layer 4 header (if present). Extension headers are not inspected unless you use the `routing`, `hop-by-hop`, `dest-option`, or `fragments` keywords in the ACL entry. If you have a permit entry for a specific destination but the packet has a Routing extension header, the ACL may still permit it because the base header matches. However, if you have a deny `ipv6 any any`, it will deny all packets regardless of extension headers. But there is a nuance: if the ACL has a permit for TCP port 80, but the packet is fragmented (Fragment extension header), the Layer 4 header is in the first fragment only; subsequent fragments will not match the TCP permit and will be denied by the implicit deny. Use the `fragments` keyword to allow all fragments: `permit tcp any any fragments`.
Test and Validate with Incremental Changes
Make one change at a time and test. For example, if you suspect ICMPv6 is blocked, add `permit icmp any any echo-request` and `permit icmp any any echo-reply` to the ACL, then ping from the test host. Use `show ipv6 access-list` to see hit counts increase. Also, use `debug ipv6 packet` with caution (only in a lab) to see if packets are being dropped by ACL. For production, use `show ipv6 access-list` with the `log` keyword to log matches. If the problem persists, double-check that the ACL is applied to the correct interface and direction. Also, consider that there might be another ACL (e.g., on a different interface) or a firewall policy blocking traffic. Use `traceroute` to see where packets stop.
In a typical enterprise network, IPv6 ACLs are used to segment traffic between departments, restrict management access to routers, and filter malicious traffic at the perimeter. For example, a company might deploy an IPv6 ACL on the border router to allow only specific services (HTTP, HTTPS, DNS) to a DMZ server farm while blocking all other inbound traffic. A common production scenario is blocking SSH access from the internet to internal routers. The ACL would permit SSH only from a management subnet and deny all other IPv6 traffic. When misconfigured, engineers often find that legitimate SSH connections from the management subnet are blocked because the permit entry for SSH is placed after a deny entry for all traffic. Another scenario is allowing ICMPv6 for troubleshooting but accidentally blocking it. In one real case, a network engineer applied an ACL that permitted only TCP port 443 to a web server. When the web server failed to respond to ping, the engineer spent hours checking routing and firewalls before realizing the ACL was blocking ICMPv6 echo. Performance considerations: IPv6 ACLs are processed in hardware on most Cisco switches (e.g., Catalyst 9000 series) using TCAM, so they don't significantly impact throughput. However, on routers, software processing can cause latency if the ACL has many entries. Also, logging (with the log keyword) can increase CPU usage. When scaling, use object groups to reduce the number of entries. Misconfiguration can lead to complete loss of connectivity, as seen when an ACL was applied inbound on a WAN interface without permitting routing protocols (OSPFv3 uses multicast addresses that must be explicitly permitted). In that case, OSPF neighbor adjacency dropped, causing a routing black hole. Always test ACLs in a lab before production deployment.
The CCNA 200-301 exam objective 5.6 specifically tests your ability to troubleshoot IPv6 ACLs that are blocking traffic. Expect scenario-based questions where you are given a network diagram, an ACL configuration, and a symptom (e.g., 'Host A cannot ping Host B'). You must identify the cause. The most common wrong answers: (1) 'The ACL is missing an implicit permit' – but IPv6 ACLs have an implicit deny, not permit. Candidates confuse IPv4 and IPv6. (2) 'The ACL is applied to the wrong interface' – while possible, the exam often includes a red herring where the interface is correct but the ACL order is wrong. (3) 'ICMPv6 is implicitly allowed' – only ND messages are implicitly allowed, not echo. (4) 'The deny all entry at the end will block everything' – actually, the implicit deny does that; a deny all entry is redundant. Key values: Sequence numbers default to 10,20,30... You can insert between them. The implicit permit for ND is always present. Commands: show ipv6 access-list shows hit counts; show ipv6 interface shows applied ACLs. A decision rule: If ping fails but TCP works, the ACL is likely blocking ICMPv6. If all traffic fails, check if the ACL has any permit statements at all. If the ACL has a permit for the traffic but it still fails, check the order (a deny before the permit) or the direction. Elimination strategy: Look at the ACL entries in order. If the traffic matches a deny entry, that's the problem. If no entry matches, the implicit deny blocks it. If the traffic should match a permit but doesn't, check for typos or incorrect protocol/port.
IPv6 ACLs end with an implicit deny all; there is no implicit permit like in IPv4.
ICMPv6 Neighbor Discovery (ND) messages (types 133-137) are implicitly permitted; all other ICMPv6 types are denied unless explicitly permitted.
Use `show ipv6 access-list` to view ACL entries and hit counts; `show ipv6 interface` to verify application.
IPv6 ACLs process only the base header and Layer 4 header; extension headers are not inspected unless specified.
The order of entries is critical; a deny entry placed before a permit for the same traffic will block it.
When troubleshooting blocked ping, add explicit permit for ICMPv6 echo-request and echo-reply.
Fragmented packets: only the first fragment has Layer 4 info; use 'fragments' keyword to allow all fragments.
These come up on the exam all the time. Here's how to tell them apart.
IPv4 ACL
Implicit permit at end (permit any)
Standard ACL uses source IP only
Extended ACL uses source/dest IP, protocol, ports
No implicit permit for ICMP types
Applied with 'ip access-group'
IPv6 ACL
Implicit deny at end (deny any)
No standard ACL; all are extended-like
Uses source/dest IPv6, protocol, ports, plus flow-label
Implicit permit for ICMPv6 ND (NS, NA)
Applied with 'ipv6 traffic-filter'
Mistake
IPv6 ACLs have an implicit permit at the end, like IPv4 ACLs.
Correct
IPv6 ACLs have an implicit deny at the end. Only specific ICMPv6 ND types are implicitly permitted.
Candidates often carry over IPv4 ACL behavior to IPv6, but Cisco changed the default to deny for security.
Mistake
All ICMPv6 traffic is implicitly permitted in an IPv6 ACL.
Correct
Only Neighbor Solicitation and Neighbor Advertisement are implicitly permitted. Other ICMPv6 types (e.g., echo) must be explicitly permitted.
ICMPv6 is essential for IPv6 operation, but only ND is automatically allowed to prevent breaking network discovery.
Mistake
Adding a 'permit ipv6 any any' at the end of an ACL will allow all traffic.
Correct
While it does permit all traffic, the order matters. If there is a deny entry before it, that deny still applies. Also, implicit permits for ND are still there.
Candidates think a catch-all permit solves everything, but ACLs are processed top-down; a preceding deny will block traffic.
Mistake
IPv6 ACLs can be applied to Layer 2 switch ports just like IPv4 ACLs.
Correct
IPv6 ACLs are applied to Layer 3 interfaces (routed ports, SVIs). For Layer 2 ports, use port ACLs or VLAN ACLs, which have different syntax.
Cisco switches have separate ACL types for Layer 2 and Layer 3; applying an IPv6 ACL to a switchport will result in an error.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Check the order of entries. If a deny entry appears before the permit entry, the deny will match first. Also, ensure the permit entry matches the traffic correctly—check source/destination addresses, protocol, and ports. Use `show ipv6 access-list` to see hit counts; if the permit has 0 matches, the traffic is not matching it. Another possibility: the ACL is applied to the wrong interface or direction. Verify with `show ipv6 interface`.
Add two permit statements: `permit icmp any any echo-request` and `permit icmp any any echo-reply`. Or use `permit icmp any any` to allow all ICMPv6, but that is less secure. The implicit permit only covers Neighbor Discovery (types 133-137).
Yes, but IPv6 ACLs have an implicit deny at the end, whereas IPv4 ACLs have an implicit permit. This is a critical difference. In IPv6, if no permit entry matches, the packet is denied. Additionally, IPv6 ACLs have implicit permit for ND messages before the implicit deny.
No, you cannot remove or override the implicit permit for Neighbor Solicitation and Neighbor Advertisement. These are essential for IPv6 operation. If you try to block them, the router will still allow them. This is a security feature to prevent accidental network isolation.
Use the command `ipv6 traffic-filter [acl-name] {in|out}` under interface configuration mode. For example: `interface GigabitEthernet0/0` then `ipv6 traffic-filter BLOCK_SSH in`. Verify with `show ipv6 interface GigabitEthernet0/0`.
`ipv6 access-list` is for Layer 3 ACLs applied with `ipv6 traffic-filter`. `ipv6 port-security` is for Layer 2 port security on switchports, which can limit the number of IPv6 addresses learned via ND. They are different features; the CCNA focuses on the former.
IPv6 fragmentation uses a Fragment extension header. Only the first fragment contains the Layer 4 header (e.g., TCP port). Subsequent fragments have only the Fragment header. If your ACL matches on Layer 4 info, only the first fragment matches; subsequent fragments will not match and may be denied by the implicit deny. To fix, add a permit entry with the `fragments` keyword: `permit tcp any any fragments`.
You've just covered Troubleshoot: IPv6 ACL Blocking Traffic — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?