If you've worked with IPv4 access lists (ACLs) on Cisco IOS before, IPv6 ACLs will feel quite familiar to you. However, there are a few caveats you'll need to be aware of, which this article explores.
The following topology shows two subnets connected by a dual-stack router, configured to route both IPv4 and IPv6 traffic in parallel.
We'll work through several examples of common traffic filtering practices, first demonstrating how each is accomplished in IPv4, and then in IPv6.
Denying a Subnet
If we want to prevent subnet A from reaching subnet B over IPv4, we can define and apply a standard ACL on the router's FastEthernet0/1 interface in the outbound direction:
interface FastEthernet0/1 ip access-group Deny_Subnet_A_IPv4 out ! ip access-list standard Deny_Subnet_A_IPv4 deny 192.168.12.0 0.0.0.255 permit any
Here exists the first major difference we notice between IPv4 and IPv6 ACLs: IPv6 supports only extended ACLs. We cannot create a standard (source-only) IPv6 ACL. IPv6 also only supports named (versus numbered) ACLs.
Router(config)# ipv6 access-list ? WORD User selected string identifying this access list log-update Control access list log updates
Because IPv6 ACLs are supported in extended form only, remember that we'll always need to specify both a source and a destination in each entry (even if one or both are "any").
Now, you might assume that, because IPv6 addresses are so much longer than IPv4 addresses and because ACL wildcards are relatively confusing, defining an IPv6 ACL entry (ACE) must be a burden. Actually, it can be quite simpler than an IPv4 ACE. Here's our ACE to block subnet A for IPv6:
Router(config-ipv6-acl)# deny ipv6 2001:db8:0:12::/64 any
Here we notice a second substantial difference from IPv4: no wildcard masking. We can simply define our source IPv6 subnet in CIDR notation, and append a destination of "any". Because the logic of IPv6 ACLs remains unchanged from IPv4, don't forget to add a final entry,
permit ipv6 any any, to allow all unmatched traffic.
With our IPv6 ACL completed, we just need to apply it to an interface. There is a minor difference in syntax here: instead of using the command
ip access-group to apply our IPv6 ACL, we use the more aptly named command
ipv6 traffic-filter, followed by the ACL name and a direction (in this case, "out").
Our final IPv6 ACL configuration looks like this:
interface FastEthernet0/1 ipv6 traffic-filter Deny_Subnet_A_IPv6 out ! ipv6 access-list Deny_Subnet_A_IPv6 deny ipv6 2001:DB8:0:12::/64 any permit ipv6 any any
Denying Specific Hosts
Just as with IPv4, we can use the
host keyword to match specific IPv6 host addresses (effectively a /128 mask):
ip access-list extended Deny_Host_A_to_B_IPv4 deny ip host 192.168.12.77 host 192.168.23.203 permit ip any any
ipv6 access-list Deny_Host_A_to_B_IPv6 deny ipv6 host 2001:DB8:0:12::4D host 2001:DB8:0:23::CB permit ipv6 any any
Limiting Access to VTY Lines
A recommended security practice is to apply an ACL to your router's remote administration interfaces (e.g. VTY lines) and allow only authorized hosts to connect to the router. Under IPv4, this is performed under line configuration using the
access-class command followed by an IPv4 ACL number or name, and a direction (typically "in"). IPv6 uses the similar command
ipv6 access-class, followed by an IPv6 ACL name and a direction.
line vty 0 15 access-class Authorized_IPv4_Hosts in ipv6 access-class Authorized_IPv6_Hosts in
Matching Upper Layer Protocols
One detail that is important to remember about IPv6 is that IPsec's authentication header (AH) may be present even on non-encrypted packets. When AH is used, the router must look beyond it to find the next encapsulated protocol (e.g. TCP or UDP). IOS provides a simple feature called IPv6 ACL Extensions for IPsec Authentication Header to support this:
This feature provides the ability to match on the upper layer protocol (ULP) ... regardless of whether an authentication header (AH) is present or absent. TCP or UDP traffic can be matched to the upper-layer protocol (ULP) (for example, TCP, UDP, ICMP, SCTP) if an AH is present or absent. Before this feature was introduced, this function was only available if an AH was absent.
This feature introduces the keyword auth to the permit and deny commands. The auth keyword allows matching traffic against the presence of the authentication header in combination with the specified protocol; that is, TCP or UDP. IPv6 traffic can be matched to a ULP when an AH header is present. To perform this function, enter the ahp option for the protocol argument when using the permit or deny command.
Note that this feature is not available on all platforms; Cisco's Feature Navigator shows that it is available only on first-generation ISR routers and later. Be aware that on unsupported platforms, IPv6 ACLs cannot see beyond the AH header.
The syntax for matching an upper layer IPv6 protocol remains essentially the same as with IPv4:
ip access-list extended Deny_TCP_80_IPv4 deny tcp any any eq www permit ip any any
ipv6 access-list Deny_TCP_80_IPv6 deny tcp any any eq www permit ipv6 any any
There are undoubtedly more differences we haven't covered here, but these should be the most prominent. To review:
- IPv6 supports only named, extended access lists.
- IPv6 ACE addresses use CIDR notation instead of wildcard masks.
- IPv6 ACLs are applied to interfaces using the command
- IPv6 ACLs are applied to lines using the command
- Older routers may not be able to reliably match upper layer protocols in IPv6 packets containing an IPsec authentication header (AH).
Please feel free to contribute any noteworthy omissions in the comments.