12.1 IPv4 and IPv6 Access Control Lists (ACLs): Standard, Extended, and Named Rules

IPv4 and IPv6 Access Control Lists (ACLs): Standard, Extended, and Named Rules

Access Control Lists (ACLs) represent the foundational security mechanism deployed on enterprise routers and multilayer switches to inspect, permit, or discard transit traffic traversing network interfaces. Operating primarily at Layer 3 (Network) and Layer 4 (Transport) of the OSI model, ACLs provide deterministic traffic filtering, protect core subnets from unauthorized access, partition broadcast domains, and serve as traffic classification engines for Quality of Service (QoS), Network Address Translation (NAT), and Control Plane Policing (CoPP). Mastering ACL rule mechanics, placement architecture, wildcard calculation, and protocol-specific nuances between IPv4 and IPv6 is essential for securing enterprise infrastructure.

Core ACL Architecture and Packet Filtering Principles

An Access Control List consists of an ordered sequence of permit and deny statements, commonly referred to as Access Control Entries (ACEs). When an interface receives or transmits a packet, the router parses the packet header fields against the configured ACEs according to strict operational tenets:

Incoming/Outgoing Packet
         │
         ▼
┌───────────────────┐
│ Evaluate ACE 10   │───[Match]───► Action: Permit (Forward) or Deny (Drop)
└───────────────────┘
         │ [No Match]
         ▼
┌───────────────────┐
│ Evaluate ACE 20   │───[Match]───► Action: Permit (Forward) or Deny (Drop)
└───────────────────┘
         │ [No Match]
         ▼
┌───────────────────┐
│ Evaluate ACE 30   │───[Match]───► Action: Permit (Forward) or Deny (Drop)
└───────────────────┘
         │ [No Match]
         ▼
┌──────────────────────────────────────────────┐
│ Implicit Deny (End of ACL)                   │
│ (deny ip any any / deny ipv6 any any)        │───► Action: Silently Drop Packet
└──────────────────────────────────────────────┘

1. Sequential Top-Down Processing: The packet filtering engine parses ACEs sequentially, starting from the lowest sequence number and proceeding downward. Rules are never evaluated out of order.
2. First-Match Termination: As soon as a packet satisfies all matching criteria of an ACE (source address, destination address, protocol, and port numbers), the designated action (permit or deny) is executed immediately. The device ceases all further evaluation for that packet. Subsequent rules with more specific or conflicting definitions are ignored.
3. Implicit Deny at End of ACL: Every IPv4 and IPv6 ACL automatically concludes with an invisible default deny statement (deny ip any any for IPv4; deny ipv6 any any for IPv6). Any packet that does not match an explicit permit statement is silently discarded. If an ACL contains only deny statements, it will drop 100% of all evaluated traffic.
4. Directional Interface Binding: ACLs are applied to interfaces in either the inbound (in) or outbound (out) direction. Inbound ACLs inspect packets immediately upon arrival at the ingress interface before the routing lookup occurs, conserving CPU and switching fabric resources. Outbound ACLs inspect packets after the routing engine determines the egress interface and rewrites the Layer 2 header, just prior to placing the frame onto the transmit queue.

Standard vs. Extended IPv4 Access Control Lists

IPv4 ACLs are categorized into two primary architectural types based on the depth of header inspection they perform:

Standard IPv4 ACLs

Standard ACLs inspect source IPv4 addresses exclusively. They cannot evaluate destination IP addresses, upper-layer transport protocols (TCP/UDP/ICMP), or Layer 4 port numbers.

• Numbered Ranges: Legacy Standard ACLs use number ranges 1–99 and the expanded range 1300–1999.
• Architectural Placement Rule: Standard ACLs must be placed as close to the destination as possible. Because standard ACLs lack destination filtering, placing a standard ACL near the traffic source risks inadvertently blocking that source from reaching other valid network destinations reachable through that same ingress path.

Extended IPv4 ACLs

Extended ACLs provide granular policy enforcement by evaluating multiple Layer 3 and Layer 4 header fields:

• Source and Destination IP Addresses: Specific hosts, subnets, or wildcard-masked address blocks.
• Protocol Type: IP, TCP, UDP, ICMP, IGMP, GRE, ESP, and OSPF.
• Layer 4 Port Numbers: Source and destination ports using logical operators such as eq (equal), neq (not equal), gt (greater than), lt (less than), and range (inclusive port range).
• TCP Control Flags: Inspection of TCP control flags, such as the established keyword, which checks whether the ACK or RST flags are set, verifying that the packet belongs to an existing bidirectional session.
• Numbered Ranges: Extended ACLs use number ranges 100–199 and the expanded range 2000–2699.
• Architectural Placement Rule: Extended ACLs must be placed as close to the source as possible. By dropping unauthorized traffic at the network edge nearest the initiating host, extended ACLs prevent denied packets from traversing the enterprise backbone, conserving intermediate bandwidth and router processing capacity.

ACL Types Comparison

Named ACLs and Sequence Number Management

Legacy numbered ACLs exhibit severe operational limitations: adding a rule appends it to the very bottom, and deleting a single rule using no access-list <number> deletes the entire ACL. Modern IOS XE also lets you edit numbered ACLs by sequence number, but only from ip access-list configuration mode. Cisco IOS XE resolves this through Named ACLs, configured via ip access-list standard <name> or ip access-list extended <name>.

Named ACLs index every ACE with a distinct sequence number (defaulting to increments of 10: 10, 20, 30...):

! Defining an extended named ACL with automatic sequence numbering
Router(config)# ip access-list extended BRANCH-FILTER
Router(config-ext-nacl)# 10 permit tcp 10.10.10.0 0.0.0.255 host 192.168.1.50 eq 443
Router(config-ext-nacl)# 20 permit tcp 10.10.10.0 0.0.0.255 host 192.168.1.50 eq 22
Router(config-ext-nacl)# 30 deny ip 10.10.10.0 0.0.0.255 192.168.1.0 0.0.0.255
Router(config-ext-nacl)# 40 permit ip any any

Granular Insertion and Deletion

Administrators can insert a new rule between existing statements without rebuilding the list by specifying an intermediate sequence number, or remove an isolated statement using no <sequence-number>:

! Insert a permit statement for DNS queries between sequence 10 and 20
Router(config)# ip access-list extended BRANCH-FILTER
Router(config-ext-nacl)# 15 permit udp 10.10.10.0 0.0.0.255 host 192.168.1.10 eq 53

! Delete the SSH rule at sequence 20
Router(config-ext-nacl)# no 20

Resequencing ACL Entries

When repeated insertions consume available sequence gaps, the global EXEC command ip access-list resequence restructures the sequence numbering across the entire list:

! Syntax: ip access-list resequence <name> <starting-sequence> <step-increment>
Router(config)# ip access-list resequence BRANCH-FILTER 10 10

Wildcard Masks and Calculation Mechanics

IPv4 ACLs utilize wildcard masks (inverse masks) to determine which bits in an IP address must match the configured rule and which bits can be ignored:

• Bit value 0: Match the corresponding bit in the IP address exactly.
• Bit value 1: Ignore the corresponding bit ("do not care").

Wildcard Mask Calculation Method

To calculate the wildcard mask for a standard contiguous IPv4 subnet, subtract each octet of the traditional subnet mask from 255.255.255.255:

$\text{Wildcard Mask} = 255.255.255.255 - \text{Subnet Mask}$

For a /27 subnet (subnet mask 255.255.255.224):

  255 . 255 . 255 . 255
- 255 . 255 . 255 . 224
-----------------------
    0 .   0 .   0 .  31

Keywords: host and any

• host <ip-address>: Represents a single host IP with wildcard mask 0.0.0.0 (all 32 bits must match exactly). For example, permit ip host 10.1.1.1 any is identical to permit ip 10.1.1.1 0.0.0.0 any.
• any: Matches any IP address, utilizing base IP 0.0.0.0 with wildcard mask 255.255.255.255 (all 32 bits are ignored).

Discontiguous Wildcard Masks

Wildcard masks do not require contiguous blocks of binary zeros and ones. Network engineers can construct discontiguous wildcard masks to match non-standard groupings. For example, to match all even-numbered third octets in the 172.16.0.0/16 network:

• Even numbers end in binary 0. Setting the least significant bit of the third octet to 0 forces an exact match on even values, while setting all other bits to 1 ignores them.
• Resulting wildcard: 0.0.254.255 (binary third octet: 11111110).
• Rule: permit ip 172.16.0.0 0.0.254.255 any matches 172.16.0.0, 172.16.2.0, 172.16.4.0, etc.

Wildcard Mask Calculation Reference

IPv6 Access Control Lists Architecture and Implicit Rules

IPv6 ACLs introduce major architectural modernizations over IPv4 implementations:

1. No Numbered ACLs: All IPv6 ACLs are strictly named. Numbered ranges do not exist in IPv6.
2. Unified Feature Set: There is no division between standard and extended ACLs. Every IPv6 ACL natively supports matching source IPv6, destination IPv6, Next Header protocol, and Layer 4 ports.
3. Prefix Length Notation: Wildcard masks are eliminated. IPv6 ACLs designate subnets using standard CIDR prefix lengths (e.g., 2001:db8:acad:10::/64) or the any and host <ipv6> keywords.

The Critical IPv6 Implicit Rules

Unlike IPv4 ACLs, which contain only a single implicit deny statement, every IPv6 ACL ends with three invisible implicit rules:

permit icmp any any nd-na
permit icmp any any nd-ns
deny ipv6 any any

These statements are essential for basic IPv6 connectivity:

• permit icmp any any nd-na: Permits ICMPv6 Neighbor Discovery Neighbor Advertisement messages.
• permit icmp any any nd-ns: Permits ICMPv6 Neighbor Discovery Neighbor Solicitation messages.
• deny ipv6 any any: Silently discards all remaining unmatched IPv6 traffic.

IPv4 vs. IPv6 ACL Architectural Matrix

Advanced Filtering: Time-Based and State-Aware ACLs

Enterprise networks frequently require dynamic access policies governed by temporal schedules or session state:

Time-Based ACLs

Time-based ACLs activate or deactivate specific ACEs based on the system clock. They reference a pre-configured time-range object defined with either absolute timestamps or recurring weekly schedules:

! Step 1: Define recurring business hours schedule
Router(config)# time-range WORK-HOURS
Router(config-time-range)# periodic weekdays 08:00 to 17:00

! Step 2: Reference the time-range in an extended ACL
Router(config)# ip access-list extended CORP-ACCESS
Router(config-ext-nacl)# 10 permit tcp 10.1.1.0 0.0.0.255 any eq 80 time-range WORK-HOURS
Router(config-ext-nacl)# 20 permit tcp 10.1.1.0 0.0.0.255 any eq 443 time-range WORK-HOURS
Router(config-ext-nacl)# 30 deny tcp 10.1.1.0 0.0.0.255 any eq 80
Router(config-ext-nacl)# 40 deny tcp 10.1.1.0 0.0.0.255 any eq 443

Outside of Monday through Friday 08:00 to 17:00, sequence statements 10 and 20 are dynamically deactivated, causing web traffic to fall through to statements 30 and 40 for termination.

TCP Established Filtering

To allow internal hosts to initiate outbound connections while preventing external untrusted endpoints from establishing inbound sessions, extended ACLs support the established keyword:

Router(config-ext-nacl)# permit tcp any 10.1.1.0 0.0.0.255 established

The established match condition inspects the TCP header flags. It matches if either the ACK (Acknowledgment) or RST (Reset) flag is set to 1. Because initial TCP connection attempts (SYN packets) have ACK=0 and RST=0, external attackers cannot initiate new TCP handshakes into the protected subnet.

Complete CLI Configuration and Interface Binding Walkthrough

The following configuration illustrates the complete deployment of both IPv4 and IPv6 ACLs, verifying rules and binding them to operational interfaces:

! Step 1: Configure Named IPv4 Extended ACL
ip access-list extended WAN-INBOUND-V4
 remark Permit return traffic for established TCP sessions
 10 permit tcp any 10.200.1.0 0.0.0.255 established
 remark Permit inbound HTTPS to corporate DMZ web server
 20 permit tcp any host 10.200.1.50 eq 443
 remark Permit secure management SSH from trusted NOC subnet
 30 permit tcp 192.168.100.0 0.0.0.255 host 10.200.1.1 eq 22
 remark Permit ICMP echo-reply and unreachable
 40 permit icmp any 10.200.1.0 0.0.0.255 echo-reply
 50 permit icmp any 10.200.1.0 0.0.0.255 unreachable
 60 deny ip any any log-input

! Step 2: Configure Named IPv6 ACL with explicit ND safety
ipv6 access-list WAN-INBOUND-V6
 remark Permit established TCP return traffic
 sequence 10 permit tcp any 2001:db8:cafe:1::/64 established
 remark Permit HTTPS to IPv6 DMZ server
 sequence 20 permit tcp any host 2001:db8:cafe:1::50 eq 443
 remark Explicitly permit ICMPv6 Neighbor Discovery prior to logging deny
 sequence 30 permit icmp any any nd-na
 sequence 40 permit icmp any any nd-ns
 sequence 50 deny ipv6 any any log-input

! Step 3: Apply ACLs to Physical Interface
interface GigabitEthernet0/0/1
 description Primary Enterprise WAN Ingress
 ip address 198.51.100.2 255.255.255.252
 ipv6 address 2001:db8:ffff::2/64
 ! Apply IPv4 ACL using ip access-group
 ip access-group WAN-INBOUND-V4 in
 ! Apply IPv6 ACL using ipv6 traffic-filter
 ipv6 traffic-filter WAN-INBOUND-V6 in

Verification and Diagnostic Commands

To audit active access lists, evaluate sequence numbers, and inspect hit counters for security validation:

• show access-lists: Displays all configured IPv4 and IPv6 access lists, showing ACE sequence numbers and real-time packet match counters.
• show ip access-list [name]: Filters output to IPv4 access lists only.
• show ipv6 access-list [name]: Displays IPv6 access lists and explicit ACE match counters.
• clear access-list counters [name]: Resets hit count statistics to zero to establish an active monitoring baseline during troubleshooting.