Chapter 25. IPv6 Access Control Lists
This chapter covers the following exam topics:
4.0 Infrastructure Services
4.4 Configure, verify, and troubleshoot IPv4 and IPv6 access list for traffic filtering
4.4.a Standard
4.4.b Extended
4.4.c Named
IP version 6 (IPv6) access control lists (ACL) provide a way for the network and security administrator to control the flow of IPv6 connections traversing the network. IPv6 ACLs provide a way to secure inbound and outbound connections as a part to the overall corporate security strategy and policy. Thus, IPv6 ACLs are a component of a layered security model that provides diversity of defensive techniques and defense in depth of complementary security approaches.
IPv6 ACLs share many of the same characteristics as IPv4 ACL, so your knowledge of IPv4 ACLs is directly transferable to IPv6 ACLs. As you have already learned, IPv6 is similar to IPv4, but it has some subtle differences in the way it works. Your knowledge of IPv4 is essential to learning IPv6, and at this point, your knowledge of IPv6 is solidifying. The same is true for the subtle differences between IPv4 and IPv6 ACLs. Both IP version ACLs can filter on IP addresses of packets and upper-layer information. IPv6 ACLs provide the ability to filter on IPv6-specific header values and other IPv6 packet attributes.
IPv6 ACLs can be used for a variety of reasons and purposes. IPv6 ACLs can filter traffic traversing the network, but IPv6 ACLs can also filter management access traffic. IPv6 ACLs can also be used to create Quality of Service (QoS) policies and to filter routing advertisements. However, the focus of this chapter will be on the ways in which IPv6 ACLs can be used to filter IPv6 packets arriving and departing router interfaces.
This chapter builds upon the IPv6 information in the ICND1 book and the IPv6 chapters earlier in this book. This chapter covers the fundamental concepts of IPv6 ACLs. The focus is on standard and extended IPv6 ACLs.
“Do I Know This Already?” Quiz
Take the quiz (either here, or use the PCPT software) if you want to use the score to help you decide how much time to spend on this chapter. The answers are at the bottom of the page following the quiz, and the explanations are in DVD Appendix C and in the PCPT software.
1. IPv6 access control lists are configured in which of the following ways?
a. Using ACL numbers 2300–2499
b. Using ACL numbers 3000–3999
c. Using ACL names to uniquely identify each ACL
d. Using subinterfaces on the physical router’s interface descriptor block
2. Which of the following statements is true about IPv6 ACLs?
a. Cisco router interfaces can only have one IPv4 or one IPv6 ACLs applied in only one direction.
b. Cisco router interfaces can have either an IPv4 or IPv6 ACL applied, but in both directions.
c. Cisco router interfaces can have both IPv4 and IPv6 ACLs applied inbound and outbound on a single interface.
d. Cisco router interfaces can have either an IPv4 or an IPv6 ACL applied, but only in one direction.
3. Which of the following IPv6 ACL entries would match and permit IPv6 packets coming from the Internet destined for the 2001:0db8:1111:0001:0000:0000:0000:0000 prefix with a 64-bit prefix length?
a. permit ipv6 any 2001:db8:1111:1::1
b. permit ipv6 2001:db8:1111:1::/64 any
c. permit ipv6 any 2001:db8:1111:1::1/128
d. permit ipv6 any 2001:db8:1111:1::/64
4. Which of the following packet header fields can be filtered using IPv6 extended access control lists?
a. TCP source and destination port number
b. ICMPv6 type and code values
c. IPv6 extension header numbers
d. IPv6 flow label values
e. All of the other answers are correct.
5. The implicit rules at the bottom of IPv6 ACLs are there to permit which of the following packets?
a. Router Solicitation (RS) and Router Advertisement (RA) messages
b. Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages
c. All ICMPv6 messages on a LAN interface
d. All IPv6 multicast packets on a LAN interface
Answers to the “Do I Know This Already?” quiz:
Foundation Topics
IPv6 Access Control List Basics
IPv6 ACLs provide the network engineer with a method to filter IPv6 packets. IPv6 packets can match the configuration of the ACL and then be permitted or denied from entering or exiting the router’s interface. IPv6 ACLs can match on the various fields of the IPv6 header, including the source and destination addresses. IPv6 ACLs can also match on the other upper-layer header parameters and extension headers and Internet Control Message Protocol Version 6 (ICMPv6) packets.
There are several types of and uses for ACLs. ACLs can be used to filter control-plane activity, either to filter routing updates or to secure the router’s own internal control plane. ACLs are used when matching and classifying types of data traffic when configuring QoS. ACLs can also be used to filter management plane packets to help secure configuration activities by allowing only management protocol access from approved network administrator systems.
The traditional use of ACLs, and the focus of this chapter, involves their ability to permit or deny packets traversing the router’s data-plane interfaces. ACLs can filter many different types of packets, but this chapter narrows the focus to how ACLs can be used to filter IPv6 packets that are traversing the network. IPv6 ACLs can permit or deny specific types of IPv6 packets that are flowing from a source node to a destination node.
This first section of this chapter covers IPv6 ACLs and how they are used for filtering IPv6 packets in the data plan on router interfaces.
Similarities and Differences Between IPv4 and IPv6 ACLs
At this point you should be familiar with IPv4 ACLs but just starting to learn about IPv6 ACLs. As you learn about IPv6, you will notice subtle differences about IPv6 that have direct functional relationships with IPv4 protocol operations. Similarly, there are subtle similarities and differences between the way that IPv4 ACLs and IPv6 ACLs operate. Following are the ways that IPv4 and IPv6 are similar:
Both match on the source address or the destination address in the protocol header.
Both match individual host addresses or subnets/prefixes.
Both can be applied directionally (inbound and outbound) to a router’s interface.
Both can match on transport layer protocol information such as TCP or UDP source or destination port numbers.
Both can match on specific ICMP message types and codes.
Both have an implicit deny statement at the end of the ACL that matches all remaining packets.
Both support time ranges for time-based ACLs.
Of course, there are key differences between IPv4 and IPv6 ACLs as well. IPv4 ACLs match IPv4 packets only (and not IPv6), and match special fields found only in IPv4 headers. Likewise, IPv6 ACLs match against IPv6 address fields as well as other fields unique to an IPv6 header. The following is a summary of the key differences:
IPv4 ACLs can only match IPv4 packets and IPv6 ACLs can only match IPv6 packets.
IPv4 ACLs can be identified by number or name, while IPv6 ACLs use names only.
IPv4 ACLs identify that an ACL is either standard or extended based on the ACL number range or by using the standard or extended keyword. IPv6 ACLs have a similar standard and extended ACL concept, but do not differentiate the styles with a different configuration keyword.
IPv4 ACLs can match on specific values unique to an IPv4 header (e.g., option, precedence, ToS TTL, fragments).
IPv6 ACLs can match on specific values unique to an IPv6 header (e.g., flow label, DSCP) as well as extension and option header values.
IPv6 ACLs have some implicit permit statements at the end of each ACL, just before the implicit deny all at the end of the ACL, while IPv4 ACLs do not have implicit permit statements.
ACL Location and Direction
IPv6 ACLs, just like IPv4 ACLs, can be applied to any interface using that specific IP version protocol and can be applied to that interface in the inbound and the outbound direction. Furthermore, a router’s interface that is operating in dual-protocol mode with both IPv4 and IPv6 can have an inbound and outbound IPv4 ACL and an inbound and outbound IPv6 ACL on the interface. The IPv4 ACLs will have no filtering function on the IPv6 packets and, vice versa, the IPv6 ACLs will not affect any IPv4 packets on the interface.
When ACLs are used to perform security filtering at the edge of a network, the more secure configuration method is to use inbound ACLs applied to the router interface that faces the untrusted network. This puts the router into a position to block incoming packets before they enter any part of the network. The less secure method is to use outbound ACLs applied to the perimeter router’s internal interface. In this case, the router first computes the forwarding path, and then the ACL can block the packet before it begins to leave the interface. Furthermore, to filter packets leaving the trusted network, the best practice is to apply the ACL in the outbound direction on the interface that connects to the untrusted network. These best practices for ACLs also apply to IPv6 ACLs.
IPv6 Filtering Policies
Choosing what packets to permit and deny—called the filtering policy—is the hard part of building IPv6 ACLs. Configuring those filtering policies once they are chosen is the easy part.
Most security practitioners agree on the concept of having a “fail-safe stance” whereby filters should only permit what is allowed and block all else. In other words, “that which is not permitted is blocked.” This is the default method of configuration for Cisco IOS ACLs and is no different when it comes to IPv6 ACLs. Each IPv6 ACL has an implied deny ipv6 any any rule at the bottom, so that any packet that falls through the if-then-else rule base will be blocked by default.
When starting to create an IPv6 filter, you don’t just take your IPv4 policy and then change the addresses to IPv6 addresses and paste in the new policy. Because IPv4 and IPv6 operate in completely separate data planes, you cannot simply replace an IPv4 address with an IPv6 address in the policy and make it work. For starters, in most cases your IPv4 network is fully established and your IPv6 environment is just beginning to develop. It is more realistic to start a new IPv6 policy and allow only those services that you want to permit for IPv6. Your IPv6 filters will grow in size over time as your IPv6 deployment develops and you require more permit statements in the ACLs.
The next step in creating an IPv6 ACL and filtering policy is to determine the types of IPv6 packets that should be allowed. This depends on the location of the router performing the filtering and the nature of the interface that the ACL is being applied to. For example, an ACL applied to the inbound direction of an Internet-connected router’s external interface is much different than an ACL applied to the inbound direction of an internal data center router connecting to a LAN containing servers.
ICMPv6 Filtering Caution
For the sake of the exams, this chapter focuses mostly on how to configure and verify IPv6 ACLs. However, it helps to think about some more practical tips that will be of good use in production networks.
Taking an approach of explicitly filtering the traffic that should be allowed, and filtering all other traffic, actually requires that the network engineer fully understand the protocols that flow through the router. As it turns out, with IPv6, some types of ICMPv6 messages need to be permitted by IPv6 ACLs, otherwise the ACL can prevent IPv6 packet forwarding from working correctly.
First, with ICMP for IPv4, many network engineers filter most ICMP messages as a matter of habit. Many different attacks make use of ICMP for IPv4, and one way to deal with those attacks is to filter the messages. The temptation is to then do likewise and filter ICMPv6 messages.
Some ICMPv6 messages must be permitted by IPv6 ACLs. For instance, Neighbor Discovery Protocol (NDP) is part of ICMPv6. Additionally, endpoint hosts use a feature called Path MTU Discovery (PMTUD), which requires ICMP messages to flow through the network. (The PMTUD feature discovers the maximum-length IPv6 packet that can flow between the source and destination host; if the host sends larger packets, IPv6 routers discard those packets.) So, building IPv6 ACLs that filter the ICMPv6 messages used by PMTUD can prevent hosts from communicating over the IPv6 network.
Therefore, when building production IPv6 networks, allowing specific ICMPv6 message types to traverse a router interface is an essential practice for facilitating end-to-end connectivity. Understanding the ICMPv6 types and codes and their functions is useful when creating IPv6 ACLs. For future reference, the Internet Assigned Numbers Authority (IANA) maintains the list of ICMPv6 parameters:
http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml
For guidance on the types of IPv6 and ICMPv6 packets that should be permitted at these different locations, consult IETF RFC 4890, “Recommendations for Filtering ICMPv6 Messages in Firewalls,” and NIST Special Publication (SP) 800-119, “Guidelines for the Secure Deployment of IPv6.” These reference documents, found at the following URIs, provide real-world deployment guidance on the IPv6 packet types that should and must be dropped or allowed on WAN or LAN interfaces:
https://www.ietf.org/rfc/rfc4890.txt
http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf
Capabilities of IPv6 ACLs
Even though IPv6 shares many commonalities with IPv4, there are subtle protocol differences that must be understood prior to configuring an IPv6 ACL. The way that IPv4 and IPv6 operate on a LAN is different. IPv4 utilizes LAN broadcast packets with Address Resolution Protocol (ARP). IPv6 uses multicast ICMPv6 messages with NDP. The IPv6 header includes fields such as the flow label and IPv6 uses extension headers for optional packet header functionality. This is different than IPv4’s header structure.
Because ACLs are configured to match various elements of a packet header, IPv6 ACLs have their own capabilities that should be understood. The following mentions some values that IPv6 ACLs on IOS routers can match in an IPv6 packet:
Traffic class (e.g., DSCP, 0 to 63)
Flow label (0 to 1048575)
IPv6 Next Header field indicating extension header type/number
Source and destination 128-bit IPv6 addresses
Upper-layer header details: TCP or UDP port numbers, TCP flags SYN, ACK, FIN, PUSH, URG, RST
ICMPv6 type and code
IPv6 extension header value and type (hop-by-hop headers, routing headers, fragmentation headers, IPsec, destination options, among others)
Limitations of IPv6 ACLs
There are several limitations of ACLs that you should take into consideration when planning and designing the router configurations. As mentioned previously, there are subtle nuances to how IPv6 is different than IPv4 that may affect how IPv6-enabled routers are configured. Following are the key limitations of IPv6 ACLs that you should be aware of and take into consideration when creating your filtering policy.
Matching Tunneled Traffic
IPv6 networks have a tendency to have more tunnels in use than in IPv4 networks. There are situations where IPv6 packets are being transported over IPv4 networks. For instance, these packets are carried within generic routing encapsulation (GRE). However, today, native IPv6 connectivity is more ubiquitous, so tunnels are not needed to join islands of IPv6 over an ocean of IPv4. Regardless, IPv6 ACLs are unable to filter based on the details of the IPv6 packets tunneled in IPv4 packets. The limitations of filtering based on the encapsulated traffic within any type of encapsulated or tunneled traffic has always been a limitation of ACLs.
IPv4 Wildcard Mask and IPv6 Prefix Length
IPv4 ACLs use a mask for the wildcard for the IPv4 subnet that is matched. Typically an IPv4 access list might look like the following entry that matches packets destined to the 10.1.1.0/24 subnet:
access-list 10 permit 10.1.1.0 0.0.0.255
However, those IPv4 wildcard mask bits do not have to be contiguous. It is possible, although not common, to have an IPv4 ACL that matches the IPv4 source or destination address using a noncontiguous wildcard mask.
With IPv6, you create an IPv6 ACL with a prefix length number value that indicates the number of contiguous prefix mask bits. In an IPv6 ACL, the prefix length number represents the number of contiguous bits that will be matched for that IPv6 address prefix. The syntax uses “slash” notation where the number after the slash indicates the number of bits of the prefix length. Therefore, you are only able to match on IPv6 address prefix and not use discontiguous masks with IPv6 ACLs. Furthermore, it is very common to have prefix lengths that are evenly divisible by 4 (e.g., /48, /52, /56, /60, /64) and nonstandard to have a prefix length that does not fall on a hex digit boundary.
ACL Logging Impact
It is important to remember that excessive logging can negatively impact router performance. The router’s CPU is involved when a log entry is created. Therefore, any ACL entry that uses the log parameter and matches many packets per second could consume CPU resources on the router.
In this chapter there are IPv6 ACL examples that use the log keyword. This is for demonstration purposes only, to validate that IPv6 packets match specific IPv6 ACL entries. Although this may be a useful practice as the ACL is being created and tested, it may not be desirable to have a production ACL logging continuously.
With IPv6 ACLs, the log messages are generated for the first packet that matches that ACL entry. Subsequent ACL entry matches that are logged are generated on a 5-minute interval. This helps reduce the CPU impact, but is something to be aware of nonetheless.
Router Originated Packets
IPv6 ACLs, like IPv4 ACLs, have the ability to match and permit or deny packets traversing a router’s interface in the data plane. However, there are limitations to ACLs matching router-originated traffic. IPv6 and IPv4 ACLs applied to interfaces in the inbound direction will block packets entering the router. However, outbound ACLs will not match packets that the router is originating.
The idea of routers bypassing outbound ACLs for router-generated packets is the same concept discussed in some depth in Chapter 17, “Advanced IPv4 Access Control Lists,” in the section “ACL Interactions with Router-Generated Packets.”
Configuring Standard IPv6 ACLs
This section will show how to begin creating and testing simple examples of IPv6 ACLs. Demonstrations of this configuration process will use a network topology with two routers configured for IPv6 and two hosts connected to each of the router’s LAN segments. Figure 25-1 will be used for the subsequent configuration examples in this chapter, so you may find yourself referring back to this topology frequently while reading examples.
The first thing you will notice when you first learn the syntax differences between IPv4 ACLs and IPv6 ACLs is that IPv6 does not use any numbered ACLs. All IPv6 ACLs are named. As always, named ACLs allow you to use descriptive names that help you remember the ACL’s intended purpose. To begin creating an IPv6 ACL, we need to enter the first command to name the ACL. After entering the first command and the ACL name, we then proceed with creating the access control entries, sometimes referred to as ACEs. Example 25-1 shows the syntax to create an ACL.
Example 25-1 Configuring a Simple ACL
R1# configure terminal
R1(config)# ipv6 access-list ?
WORD User selected string identifying this access list
log-update Control access list log updates
R1(config)# ipv6 access-list V6_ACL_IN
R1(config-ipv6-acl)# ?
IPv6 Access List configuration commands:
default Set a command to its defaults
deny Specify packets to reject
evaluate Evaluate an access list
exit Exit from access-list configuration mode
no Negate a command or set its defaults
permit Specify packets to forward
remark Access list entry comment
sequence Sequence number for this entry
Example 25-1 shows the creation of an IPv6 ACL with the name V6_ACL_IN. When the ? is entered at the ACL configuration prompt, the router shows all the possible commands within an ACL. The permit and deny commands are the most common, but you could also use remark statements to help document the ACLs. The sequence command allows you to create or modify an ACL entry with a specific number whereby the ACL filtering is performed in order from the lowest sequence number to the highest sequence number. The no command can be used to remove a specific ACL entry.
Following is the syntax for standard IPv6 ACL permit and deny statements. IPv6 supports both standard and extended ACLs, although the configuration does not identify an ACL as one or the other. IPv6 standard ACLs can match the source and destination IPv6 address fields, but no other parts of an IPv6 packet.
[permit | deny] ipv6 {source-ipv6-prefix/prefix-length | any | host source-ipv6-
address} {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-
address} [log]
The permit and deny commands in an IPv6 ACL have many similar concepts compared to a named IPv4 ACL’s permit or deny commands, just with some slight variations. From this generic IPv6 permit command, you can see
The ipv6 parameter is one example of the protocol keyword, and means that the ACL will match all IPv6 packets. Other options match a subset of IPv6 packets and include tcp, udp, and icmp. These keywords mirror the ip, tcp, udp, and icmp keywords used in IPv4 ACLs.
The source and destination IP address fields, followed by a prefix length, define the IPv6 prefix, much like an IPv4 ACL’s combined subnet and wildcard mask field defines an IPv4 address range.
The operator port-number parameters refer to the matching items such as the TCP and UDP port numbers (for example, eq 80 to match the well-known port for HTTP), with many of the same parameter keywords and values as used with IPv4. Note that as with IPv4, IPv6 ACLs require a protocol keyword of tcp or udp to allow the use of the operator keyword to match the TCP and UDP ports numbers used.
The host address values (both source and destination) match a specific single IPv6 address, much like the host address option used in IPv4 ACLs.
Example 25-2 continues Example 25-1, in which the IPv6 ACL with the name V6_ACL_IN was created, proceeding to create the ACL entries. This ACL is going to have a single permit statement that allows any IPv6 node to send IPv6 packets to R2’s LAN that contains host B (2001:db8:1111:2::/64). All other IPv6 packets will be implicitly dropped by this ACL. Once the ACL is created, then this ACL is applied to an IPv6-enabled interface in the specific direction.
R1(config-ipv6-acl)# permit ipv6 any 2001:db8:1111:2::/64
R1(config-ipv6-acl)# interface GigabitEthernet 0/2
R1(config-if)# ipv6 traffic-filter V6_ACL_IN in
IPv6 ACLs use the ipv6 traffic-filter command to apply the ACL to a router interface in a specific direction. This is a different syntax than the familiar IPv4 ACL ip access-group command that is used to apply an IPv4 ACL to a router interface.
Now it is a good idea to verify that the IPv6 ACL was created in the configuration and properly applied to the interface. Example 25-3 demonstrates the show commands that will be used to inspect the configuration steps performed.
Example 25-3 Validating Simple ACL Configuration
R1# show running-config
Building configuration...
! lines omitted for brevity
hostname R1
! lines omitted for brevity
interface GigabitEthernet0/2
ipv6 address 2001:DB8:1111:1::1/64
ipv6 traffic-filter V6_ACL_IN in
! lines omitted for brevity
ipv6 access-list V6_ACL_IN
permit ipv6 any 2001:DB8:1111:2::/64
! lines omitted for brevity
R1# show ipv6 interface GigabitEthernet 0/2
GigabitEthernet0/2 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::F816:3EFF:FEC0:21D
No Virtual link-local address(es):
Global unicast address(es):
2001:DB8:1111:1::1, subnet is 2001:DB8:1111:1::/64
! lines omitted for brevity
Input features: Access List
Inbound access list V6_ACL_IN
! lines omitted for brevity
R1# show ipv6 interface | include line|list
GigabitEthernet0/1 is up, line protocol is up
GigabitEthernet0/2 is up, line protocol is up
Inbound access list V6_ACL_IN
R1# show ipv6 access-list
IPv6 access list V6_ACL_IN
permit ipv6 any 2001:DB8:1111:2::/64 sequence 10
The Example 25-3 command output shows that the commands are now within the global configuration and the IPv6 ACL is applied to GigabitEthernet 0/2 in the inbound interface. The router’s interfaces are up and operational and the ACL has its one permit statement.
The next step in the process is to test sending IPv6 traffic through the ACL. Using a simple ping6 command from host A to host B will validate that the packets are being allowed. Example 25-4 shows the output from host A successfully executing the ping6 command.
Example 25-4 Validating ping Command’s Packets Are Permitted by the ACL
cisco@HostA:~$ ping6 2001:db8:1111:2:f816:3eff:fe9a:c89f
PING 2001:db8:1111:2:f816:3eff:fe9a:c89f(2001:db8:1111:2:f816:3eff:fe9a:c89f) 56 data
bytes
64 bytes from 2001:db8:1111:2:f816:3eff:fe9a:c89f: icmp_seq=1 ttl=62 time=8.63 ms
64 bytes from 2001:db8:1111:2:f816:3eff:fe9a:c89f: icmp_seq=2 ttl=62 time=8.71 ms
64 bytes from 2001:db8:1111:2:f816:3eff:fe9a:c89f: icmp_seq=3 ttl=62 time=6.25 ms
^C
--- 2001:db8:1111:2:f816:3eff:fe9a:c89f ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 6.257/7.869/8.712/1.142 ms
cisco@HostA:~$
Three ICMPv6 Echo Request messages were sent and it appears that they were successfully received and three ICMPv6 Echo Reply messages were returned. The next step is to check the IPv6 ACL on R1 and see how many packets have matched its single permit ACL entry. Example 25-5 shows the IPv6 ACL and shows that three packets have matched this ACL entry.
Example 25-5 Finding Counters of Packets That Matched the ACL
R1# show ipv6 access-list
IPv6 access list V6_ACL_IN
permit ipv6 any 2001:DB8:1111:2::/64 (3 matches) sequence 10
R1#
To clear the IPv6 ACL traffic counters, use the following command:
clear access-list counters V6_ACL_IN
Configuring Extended IPv6 ACLs
The previous section covered a simplified syntax for a standard IPv6 ACL. This section will review the additional types of packets that extended IPv6 ACLs can match and the syntax for ACL configuration. Extended IPv6 ACLs can match on many more IPv6 header fields as well as ICMPv6 messages, TCP and UDP port numbers, and other IPv6 header items like IPv6 extension headers. Following is the complete syntax of an IPv6 ACL entry.
[permit | deny] protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-
address} [operator [port-number]] {destination-ipv6-prefix/prefix-length | any | host
destination-ipv6-address} [operator [port-number]] [dest-option-type [doh-number |
doh-type]] [dscp value] [flow-label value] [fragments] [log] [log-input] [mobility]
[mobility-type [mh-number | mh-type]] [reflect name [timeout value]] [routing]
[routing-type routing-number] [sequence value] [time-range name]
Note
The next few pages show many details of IPv6 ACL syntax so that you can see the large number of options. The upcoming Figure 25-2 reduces the complexity down to a few key values, similar to those used with IPv4 ACLs, more useful for preparing for the exam.
The generic permit and deny command shows the syntax for an extended IPv6 ACL. With IPv6, the difference between standard and extended ACLs is subtle. There is no keyword that distinguishes an IPv6 ACL as either standard or extended. Instead, an extended IPv6 ACL simply uses more than the source and destination IPv6 address fields when matching.
IPv6 extended ACLs can match on many of the values within the IPv6 header. IPv6 ACLs can match on the DSCP value for QoS marking, the flow label, and the source and destination IPv6 address. IPv6 extended ACLs have the ability to match not only on the source and destination IP addresses, but also on upper-layer protocol information. The next-header value in the IPv6 header indicates the number of the type of header that immediately follows the IPv6 header. In many cases, this would be either a TCP or UDP header where the protocol value would be tcp or udp, respectively. However, it could also be an ICMPv6 packet or it could be an extension header that has been added between the IPv6 header and the upper-layer header. IPv6 extended ACLs can match on destination option headers, fragmentation headers, routing headers, and Mobile IPv6 (MIPv6) headers. (To extend your learning about additional IPv6 extension header types, search for and read a copy of IETF RFC 2460.)
Besides matching IPv6 packets, IPv6 ACLs can also match ICMPv6 packets. ICMPv6 packets are IPv6 packets that also include an ICMPv6 header. By specifying icmp as the protocol keyword in the IPv6 ACL entry, the command matches the subset of IPv6 packets that also have an ICMPv6 header. Using the icmp keyword also enables many filtering options for ICMPv6 packets. For IPv6 ACL entries that match on ICMPv6 message headers, the following syntax defines how these ACL entries are configured:
[permit | deny] icmp { source-ipv6-prefix/prefix-length | any | host source-ipv6-
address | auth } [ operator [port-number] ] { destination-ipv6-prefix/prefix-length
| any | host destination-ipv6-address | auth } [ operator [port-number] ] [ icmp-
type [icmp-code] | icmp-message ] [ dest-option-type [ doh-number | doh-type ] ] [
dscp value ] [ flow-label value ] [fragments] [hbh] [log] [log-input] [mobility] [
mobility-type [ mh-number | mh-type ] ] [routing] [ routing-type routing-number ] [
sequence value ] [ time-range name ]
ICMPv6 ACLs can match on the source and destination IPv6 addresses, but also the ICMPv6 type and code values. ICMPv6 ACLs can also match on many other IPv6 extension headers like IPv6 extended ACLs.
It is possible to create an IPv6 ACL that matches TCP header values including source and destination port numbers. It is possible, although uncommon, for an ACL to match on TCP flags such as ACK, FIN, PSH, RST, SYN, and URG. TCP IPv6 ACLs can also match the other IPv6 extension header values. Following is the syntax for an IPv6 ACL that uses the tcp value for the protocol allowing this ACL to permit or deny a TCP packet:
[permit | deny] tcp { source-ipv6-prefix/prefix-length | any | host source-ipv6-
address | auth } [ operator [port-number] ] { destination-ipv6-prefix/prefix-length
| any | host destination-ipv6-address | auth } [ operator [port-number] ] [ack] [
dest-option-type [ doh-number | doh-type ] ] [ dscp value ] [established] [fin] [
flow-label value ] [fragments] [hbh] [log] [log-input] [mobility] [ mobility-type [
mh-number | mh-type ] ] [ neq { port | protocol } ] [psh] [ range { port | protocol }
] [ reflect name [ timeout value ] ] [routing] [ routing-type routing-number ] [rst]
[ sequence value ] [syn] [ time-range name ] [urg]
IPv6 ACLs also have the ability to match UDP packets. UDP packets do not have any of the flow-control flags used in TCP packets, and as a result, the ACL syntax is simpler. However, UDP IPv6 ACLs can still match on IPv6 extension header values. When the udp protocol value is used in an IPv6 ACL, the following syntax applies when creating an IPv6 ACL that can permit or deny a UDP packet:
[permit | deny] udp { source-ipv6-prefix/prefix-length | any | host source-ipv6-
address | auth } [ operator [port-number] ] { destination-ipv6-prefix/prefix-
length | any | host destination-ipv6-address | auth } [ operator [port-number] ]
[ dest-option-type [ doh-number | doh-type ] ] [ dscp value ] [ flow-label value ]
[fragments] [hbh] [log] [log-input] [mobility] [ mobility-type [ mh-number | mh-type
] ] [ neq { port | protocol } ] [ range { port | protocol } ] [ reflect name [
timeout value ] ] [routing] [ routing-type routing-number ] [ sequence value ] [
time-range name ]
When creating an IPv6 ACL that permits or denies TCP or UDP packets based on port numbers, IPv6 packets use the same port numbers as IPv4 packets. Therefore, an IPv6 ACL that blocks Telnet services using TCP destination port 23 would use the same port number as the functionally equivalent IPv4 ACL. Look to Table 17-3 in Chapter 17 for a list of most of the more common TCP and UDP port numbers.
Figure 25-2 points out some of the more common matching options specific to IPv6 extended ACL permit and deny commands when using the tcp, udp, and icmp keywords. When using any protocol keyword other than ipv6, the permit or deny command then matches a subset of IPv6 packets. For instance, using the tcp keyword as the protocol matches all IPv6 packets with a TCP header. Additionally, as with IPv4 ACLs, to match TCP port numbers, you must use the tcp keyword in the permit or deny command. Likewise, the command must use the udp keyword to match UDP port numbers, and the icmp keyword to then match ICMP message types.
Examples of Extended IPv6 ACLs
Configuring an extended IPv6 ACL is similar to configuring a standard IPv6 ACL, but the ACL syntax is more complex, allowing matching of more types of packets.
This example will use the same network topology as in the previous standard IPv6 ACL example, repeated here as Figure 25-3. Example 25-6 will demonstrate the creation of an IPv6 ACL that filters packets entering R2’s G0/1 interface. Example 25-6 shows an IPv6 extended ACL that
Permits a custom application running on TCP port 51234
Permits SSH running on TCP port 22
Permits ICMv6 Echo Request packets
Example 25-6 Configuring Extended ACL
R2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# ipv6 access-list V6_APPS_ACL
R2(config-ipv6-acl)# permit tcp 2001:db8:1111:1::/64 2001:db8:1111:2::/64 eq 51234 log
R2(config-ipv6-acl)# permit tcp 2001:db8:1111:1::/64 2001:db8:1111:2::/64 eq 22 log
R2(config-ipv6-acl)# permit icmp 2001:db8:1111:1::/64 2001:db8:1111:2::/64
echo-request log
R2(config-ipv6-acl)# interface GigabitEthernet0/1
R2(config-if)# ipv6 traffic-filter V6_APPS_ACL in
R2(config-if)# end
R2# show ipv6 access-list
IPv6 access list V6_APPS_ACL
permit tcp 2001:DB8:1111:1::/64 2001:DB8:1111:2::/64 eq 51234 log sequence 10
permit tcp 2001:DB8:1111:1::/64 2001:DB8:1111:2::/64 eq 22 log sequence 20
permit icmp 2001:DB8:1111:1::/64 2001:DB8:1111:2::/64 echo-request log sequence 30
R2# show ipv6 interface | include line|list
GigabitEthernet0/1 is up, line protocol is up
Inbound access list V6_APPS_ACL
GigabitEthernet0/2 is up, line protocol is up
R2#
Configuring this IPv6 ACL named V6_APPS_ACL starts with the creation of the ACL and its name, followed by the two permit statements for the two TCP applications and the ICMP Echo Request permit statement. Then the ACL is applied inbound to the specific R2 router interface. It is visible that the ACL is applied to the GigabitEthernet 0/1 interface in the inbound direction.
The next step is to test the IPv6 ACL by creating connections from host A to host B using these two specific TCP applications. The next step will be to test performing an IPv6 ping from host A to host B, which should succeed because ICMPv6 Echo Request messages are permitted by this ACL and should be replied to with ICMPv6 Echo Reply messages. The two TCP connections were completed successfully as well. After generating these connections on the hosts, the output in Example 25-7 was observed on R2, first with log messages, then with the show ipv6 access-lists command.
Example 25-7 Check Counters on Extended ACL
*Mar 6 21:59:12.230: %IPV6_ACL-6-ACCESSLOGP: list V6_APPS_ACL/10 permitted tcp
2001:DB8:1111:1:F816:3EFF:FEF6:7296(52239) -> 2001:DB8:1111:2:F816:3EFF:FEE1:
5CF5(51234), 1 packet
*Mar 6 21:59:16.069: %IPV6_ACL-6-ACCESSLOGP: list V6_APPS_ACL/10 permitted tcp
2001:DB8:1111:1:F816:3EFF:FEF6:7296(52240) -> 2001:DB8:1111:2:F816:3EFF:FEE1:
5CF5(51234), 1 packet
*Mar 6 21:59:17.798: %IPV6_ACL-6-ACCESSLOGP: list V6_APPS_ACL/10 permitted tcp
2001:DB8:1111:1:F816:3EFF:FEF6:7296(52241) -> 2001:DB8:1111:2:F816:3EFF:FEE1:
5CF5(51234), 1 packet
*Mar 6 21:59:49.769: %IPV6_ACL-6-ACCESSLOGP: list V6_APPS_ACL/20 permitted tcp
2001:DB8:1111:1:F816:3EFF:FEF6:7296(57199) -> 2001:DB8:1111:2:F816:3EFF:FEE1:
5CF5(22), 1 packet
*Mar 6 22:13:07.326: %IPV6_ACL-6-ACCESSLOGDP: list V6_APPS_ACL/40 permitted icmpv6
2001:DB8:1111:1:F816:3EFF:FEF6:7296 -> 2001:DB8:1111:2:F816:3EFF:FEE1:5CF5 (128/0),
1 packet
R2# show ipv6 access-list
IPv6 access list V6_APPS_ACL
permit tcp 2001:DB8:1111:1::/64 2001:DB8:1111:2::/64 eq 51234 log (15 matches)
sequence 10
permit tcp 2001:DB8:1111:1::/64 2001:DB8:1111:2::/64 eq 22 log (34 matches)
sequence 20
permit icmp 2001:DB8:1111:1::/64 2001:DB8:1111:2::/64 echo-request log (3 matches)
sequence 30
R2#
Because both entries of the IPv6 extended ACL are using the log keyword, R2 observes via console-level logging that connections were made on both TCP port 51234 and port 22 and that the ping worked. When the IPv6 ACL is checked on R2, the log messages and show command counters show that there are matches on all three ACL entries. Therefore, this extended IPv6 ACL is behaving as expected and as desired.
Practice Building ipv6 access-list Commands
In this section, practice getting comfortable with the syntax of the ipv6 access-list permit or deny ACL entry, particularly with choosing the correct matching logic. First, the following list summarizes some important tips to consider when choosing matching parameters to any ipv6 access-list permit or deny ACL entries:
To match a specific address, just list the address after the host keyword.
To match any and all addresses, use the any keyword.
To match based only on the IPv6 prefix, use the “slash” notation to designate the number of bits in the prefix length. For example, a /64 prefix length matches the first 64 bits of the 128-bit IPv6 address, and any Interface Identifier (IID) within the least-significant 64 bits of that address falls within that prefix range.
Table 25-2 lists the criteria for several practice problems. Your job: Create a one-line standard ACL that matches the packets. The answers are listed in the final section of this chapter, “Answers to Earlier Practice Problems.”
Other IPv6 ACL Topics
This last major section of the chapter discusses two topics that apply to both standard and extended IPv6 ACLs. First, IPv6 ACLs apply several implicit rules at the end of each ACL. The first topic in this section discusses the protocols matched by those rules and then shows what those implicit rules are. The second topic examines how to use IPv6 ACLs to control access to a router using IPv6 Telnet and SSH.
Implicit IPv6 ACL Rules
Every ACL has the default fail-safe stance whereby any packet that is not permitted is implicitly dropped. At the end of each IPv6 ACL is an implicit deny ipv6 any any statement that catches any packet that falls through the list unmatched, much like the implicit deny ip any any found at the end of IPv4 ACLs.
IPv6 requires the use of ICMPv6 to properly function, and multicast is a necessary forwarding method on each IPv6-enabled LAN. Unfortunately, that implicit deny all at the end of IPv6 ACLs would otherwise filter those ICMPv6 and multicast packets.
By way of review, the Neighbor Discovery Protocol (NDP) is a part of ICMPv6. As introduced in the ICND1 100-105 Cert Guide, Chapter 31, NDP includes neighbor discovery with the NDP Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages, as well as the Router Solicitation (RS) and Router Advertisement (RA) messages. Therefore, network engineers are unable to be overly aggressive with IPv6 ACLs to block ICMPv6 and multicast connections. However, in previous IPv6 ACL examples, the configuration did not explicitly allow IPv6 NDP messages to flow through the IPv6 ACLs configured earlier in this chapter. This section works through understanding what IOS does to make sure those ICMP messages flow correctly.
An Example of Filtering ICMPv6 NDP and the Negative Effects
To get a better understanding, let’s try a little experiment to test this. Instead of relying on the implicit statements at the end of an IPv6 ACL, what would happen if an IPv6 ACL explicitly blocked all ICMPv6 and blocked all IPv6 multicast? The next three examples answer that question. Examples 25-8 and 25-9 show the background, with no ACLs used at all, showing the information learned by ICMPv6’s NDP protocols. Example 25-10 then shows an ACL that blocks all ICMPv6 and all IPv6 multicast packets, to see how that filtering affects a network.
This series of examples uses the network topology shown in Figure 25-4, which is the same topology shown previously in this chapter in Figures 25-1 and 25-3. Example 25-8 validates that Router R1 has a properly discovered IPv6 NDP neighbor cache. It also shows that R1’s GigabitEthernet 0/1 interface is functioning properly with multicast and it is receiving RA messages from Router R2.
Example 25-8 Check IPv6 NDP on R1
R1# show ipv6 interface GigabitEthernet 0/1
GigabitEthernet0/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::F816:3EFF:FE25:563A
No Virtual link-local address(es):
Global unicast address(es):
2001:DB8:1111:12::1, subnet is 2001:DB8:1111:12::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF00:1
FF02::1:FF25:563A
! lines omitted for brevity
R1# show ipv6 neighbors GigabitEthernet0/1
IPv6 Address Age Link-layer Addr State Interface
2001:DB8:1111:12::2 11 fa16.3eed.95b8 STALE Gi0/1
FE80::F816:3EFF:FEED:95B8 11 fa16.3eed.95b8 STALE Gi0/1
R1# show ipv6 routers
Router FE80::F816:3EFF:FEED:95B8 on GigabitEthernet0/1, last update 2 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:1111:12::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Example 25-8 reveals that R1 knows two IPv6 neighbor addresses in its neighbor cache, both of which are Router R2. One address is the global unicast address of R2’s GigabitEthernet 0/1 interface and one is R2’s GigabitEthernet 0/1 interface. The show ipv6 routers command output confirms that R1 has learned of one other IPv6 router (also R2). This command lists information learned by NDP, in this case confirming that R1 is receiving the RA messages that R2 is sending out from its GigabitEthernet 0/1 interface. Therefore, R2 can reach R1 perfectly.
In Example 25-9, the same checks are performed on Router R2.
Example 25-9 Check IPv6 NDP on R2
R2# show ipv6 interface GigabitEthernet 0/1
GigabitEthernet0/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::F816:3EFF:FEED:95B8
No Virtual link-local address(es):
Global unicast address(es):
2001:DB8:1111:12::2, subnet is 2001:DB8:1111:12::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF00:2
FF02::1:FFED:95B8
! lines omitted for brevity
R2# show ipv6 neighbors GigabitEthernet0/1
IPv6 Address Age Link-layer Addr State Interface
2001:DB8:1111:12::1 11 fa16.3e25.563a STALE Gi0/1
FE80::F816:3EFF:FE25:563A 11 fa16.3e25.563a STALE Gi0/1
R2# show ipv6 routers
Router FE80::F816:3EFF:FE25:563A on GigabitEthernet0/1, last update 1 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:1111:12::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Example 25-9 reveals that R2 learns R1’s two addresses (global unicast and link local), as well as learning about R1 as a router. The show ipv6 neighbors command lists R1’s global unicast and link-local addresses, both of which Router R2 would have learned by receiving ICMPv6 NDP NA messages. The show ipv6 routers command output confirms that R2 has learned about R1, with R2 learning this information by receiving an ICMPv6 NDP RA message.
Example 25-10 shows the addition of an IPv6 ACL that prevents the two routers from learning from each other using ICMPv6 NDP. The example shows the configuration of an IPv6 ACL will block ICMPv6 packets and block all multicast traffic, but allow all other IPv6 packets. This extended IPv6 ACL will be applied inbound on R1’s GigabitEthernet 0/1 interface and inbound on R2’s GigabitEthernet 0/1 interface. After the ACLs are configured, the ACL will be checked that they are in the running configuration and operational. Following is the configuration on R1. R2’s configuration is identical to R1’s.
Example 25-10 Configuring IPv6 Blocking ACL on R1
R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# ipv6 access-list BLOCKV6
R1(config-ipv6-acl)# deny icmp any any
R1(config-ipv6-acl)# deny ipv6 ff00::/8 any
R1(config-ipv6-acl)# deny ipv6 any ff00::/8
R1(config-ipv6-acl)# permit ipv6 any any
R1(config-ipv6-acl)# interface GigabitEthernet0/1
R1(config-if)# ipv6 traffic-filter BLOCKV6 in
R1(config-if)# end
R1#
R1# show ipv6 access-list
IPv6 access list BLOCKV6
deny icmp any any sequence 10
deny ipv6 FF00::/8 any sequence 20
deny ipv6 any FF00::/8 sequence 30
permit ipv6 any any sequence 40
R1# show ipv6 interface | include line|list
GigabitEthernet0/1 is up, line protocol is up
Inbound access list BLOCKV6
The IPv6 ACL shown in Example 25-10 will filter Router Advertisement (RA) ICMPv6 messages for a couple of reasons. NDP RA and RS messages are part of ICMPv6, so those messages match the first line of the ACL. Even if they had not, NDP RA messages are sent to the all-nodes multicast group address (FF02::1). Routers periodically send RA messages, typically every 200 seconds, to inform nodes on the network about the local network characteristics and about the method for IPv6 address allocation. Router Solicitation (RS) ICMPv6 messages are sent to the all-routers multicast group address (FF02::2). When a node boots up or joins the network, it immediately sends an RS message to the local router to find out about the network and to determine the method it should use to acquire its IPv6 address. The deny commands that list address FF00::/8 would match all multicast addresses.
Note that blocking all multicast IPv6 packets, as is done with the ACL in Example 25-10, can have a big negative impact on router operation. If the BLOCKV6 ACL is blocking multicast packets, then it will inadvertently block other link-local multicasts such as: OSPFv3 (FF02::5, FF02::6), RIPng (FF02::9), EIGRP for IPv6 (FF02::A), and DHCPv6 (FF02::1:2, FF05::1:3). To further explore other well-known registered IPv6 multicast addresses, you can extend your learning and refer to the IANA IPv6 Multicast Address Space Registry at the following URI. (Or refer to the ICND1 Cert Guide’s Chapter 30, section “Local Scope Multicast Addresses.”)
http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
The sample BLOCKV6 ACL will also prevent the two routers from learning each other’s IPv6 addresses, which actually prevents the two routers from successfully forwarding packets to each other. The first line in the ACL will prevent all ICMPv6 messages, including all NDP NS and NA messages. Even without the deny icmp any any command, the ACL would filter NS and NA based on the addresses used. NS ICMPv6 messages are sent to the solicited node multicast address (FF02:0:0:0:0:1:FF00::/104) of the destination node on the LAN. (NA ICMPv6 messages are sent back, typically to the unicast address of the node that sent the original NS packet.)
Now that this ACL is applied, it will block all ICMPv6 and multicast packets on this interface. After waiting for over 5 minutes, the neighbor cache and the router cache on the two routers can be inspected, as shown in Example 25-11. The observation shows that the neighbor cache entries on the interface have timed out and the RA cache is very old. In fact, now host A and host B are unable to ping each other because the connectivity between R1 and R2 has been disrupted by these two IPv6 ACLs.
Example 25-11 Checking IPv6 Blocking ACL on R1
R1# show ipv6 neighbors GigabitEthernet 0/1
R1# show ipv6 routers
Router FE80::F816:3EFF:FEED:95B8 on GigabitEthernet0/1, last update 17 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:1111:12::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Example 25-12 shows the output from R2 validating the contents of the neighbor cache and the router cache.
Example 25-12 Checking IPv6 Blocking ACL on R2
R2# show ipv6 neighbors GigabitEthernet 0/1
R2# show ipv6 routers
Router FE80::F816:3EFF:FE25:563A on GigabitEthernet0/1, last update 15 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:1111:12::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
How to Avoid Filtering ICMPv6 NDP Messages
Network administrators must be careful when creating IPv6 ACLs that are filtering ICMPv6 messages and multicast packets so that the ACLs are not inadvertently stopping NDP from functioning properly. This is why it is important, on any interface, to permit NDP to operate. In other words, you should not filter ICMPv6 and multicast on a wholesale level.
For this very reason, Cisco IOS IPv6 ACLs have three implicit rules at the bottom of each ACL. These are invisible, but they are included at the end of each IPv6 ACL so as to implicitly permit NA and NS messages. The final implicit IPv6 ACL statement is the default deny that is commonly expected. The three implicit IPv6 ACL rules at the bottom of every ACL are shown in Example 25-13.
Example 25-13 Implicit IPv6 ACL Entries
permit icmp any any nd-na
permit icmp any any nd-ns
deny ipv6 any any
Note that these defaults do permit NDP NS and NA messages, but do not include an implicit permit of NDP RS and RA messages. If you wanted to add explicit statements to an ACL to match RS and RA messages, you could use commands like permit icmp any any router-advertisement and permit icmp any any router-solicitation.
Note
Even though CCNA R&S does not get into Cisco’s IOS XE and NX-OS operating systems, on a practical note, they do use slightly different defaults. IOS-XE has no default permit of NS/NA packets, so you would need to add explicit permit commands at the end of each IPv6 ACL so as to not inadvertently affect NDP functionality. NX-OS has five implicit IPv6 ACL statements: one for NA messages, one for NS messages, one for RA messages, one for RS messages, and the final implicit default deny rule.
Because of these implicit IPv6 ACL rules allowing NA/NS messages, it is important to remember to change our ACLs if required to use a deny-log at the end of the policy. Therefore, if the desire is to create an ACL that logs all denied IPv6 packets, the IPv6 ACL would need to be configured like Example 25-14.
Example 25-14 Explicitly Allowing NDP in IPv6 ACL
R1(config)# ipv6 access-list MY_IPV6_ACL
R1(config-ipv6-acl)# permit ipv6 any 2001:db8:1111:1::/64
R1(config-ipv6-acl)# permit ipv6 any 2001:db8:1111:2::/64
R1(config-ipv6-acl)# permit icmp any any nd-na
R1(config-ipv6-acl)# permit icmp any any nd-ns
R1(config-ipv6-acl)# deny ipv6 any any log
In Example 25-14, this IPv6 ACL has explicit entries to permit NA and NS messages. Even though it does not explicitly permit RA messages, this ACL, if applied in the outbound direction, will not block the sending of RA messages because they are originated by the router. Similar to IPv4 ACLs, packets originating from the router will not be affected by an outbound interface IPv6 ACL. However, if this ACL is applied in the inbound direction, it will block RA messages from being received on this router’s interface.
IPv6 ACL Implicit Filtering Summary
There are many ways that IPv6 packets can be used. Basic IPv6 ACLs can be used simply to filter communications between specific IPv6 hosts or IPv6 address prefixes. Extended IPv6 ACLs have the ability to match ICMPv6, TCP, UDP, or other IPv6 header fields and extension headers.
It is important to remember that IPv6 operations are different from IPv4 operations across a WAN or the Internet and that ACLs should not be overly aggressive at filtering ICMPv6 messages. It is also important to remember that ICMPv6 is critical to LAN connectivity and that ACLs should not block NDP messages to access nodes or between directly connected routers. There are implicit rules in IPv6 ACLs that can help us remember to permit these important IPv6 packet types.
IPv6 Management Control ACLs
IPv6 ACLs can be used for security purposes other than filtering data-plane traffic that passes through the router. ACLs can also be used to help harden the router from a security perspective and control the management-plane communications to the router.
Seldom do routers have fully out-of-band management network access, and frequently routers are configured in-band. To limit the exposure and restrict the management and configuration interaction with a router, ACLs can be used to filter these connections.
IPv6 ACLs can be applied to many other management functions of a router. IPv6 ACLs can be used to restrict SNMP communications, RADIUS, TACACS+, HTTP/HTTPS access, NTP, and Telnet/SSH CLI access. An example of how an IPv6 ACL can be used to restrict management access is when it is used with an IPv6 access class. This is when an ACL is used to filter IPv6 Telnet and/or SSH login connections.
In Example 25-15, the IPv6 ACL is created to restrict the IPv6 addresses of the authorized management workstations on R1’s LAN. This ACL will be applied to the VTY ports on R1 and R2 using the ipv6 access-class command. This is similar to the familiar IPv4 command ip access-class. Example 25-15 shows the configuration that is applied to R2, but R1’s configuration is identical.
Example 25-15 Configuring IPv6 Access ACL on R2
R2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# ipv6 access-list V6ACCESS
R2(config-ipv6-acl)# permit tcp 2001:db8:1111:1::/64 any eq 23
R2(config-ipv6-acl)# permit tcp 2001:db8:1111:1::/64 any eq 22
R2(config-ipv6-acl)# deny ipv6 any any log
R2(config-ipv6-acl)# line vty 0 4
R2(config-line)# login
R2(config-line)# password cisco
R2(config-line)# transport input telnet ssh
R2(config-line)# ipv6 access-class V6ACCESS in
R2(config-line)# end
In Example 25-15, the IPv6 ACL is configured and applied to the VTY ports. At this point, it is time to test this ACL. It is now possible to telnet from host A to both R1 and R2, but host B is disallowed from connecting to either router with Telnet.
Example 25-16 shows the attempt of host B to Telnet to R1, which failed as shown in the log message. The example also shows that the IPv6 ACL had matches for the connections from host A.
Example 25-16 Checking IPv6 Access ACL on R1
*Mar 6 23:31:19.926: %IPV6_ACL-6-ACCESSLOGP: list V6ACCESS/30 denied tcp 2001:DB8:111
1:2:F816:3EFF:FEE1:5CF5(34474) -> 2001:DB8:1111:1::1(23), 1 packet
R1# show ipv6 access-list
IPv6 access list V6ACCESS
permit tcp 2001:DB8:1111:1::/64 any eq telnet (2 matches) sequence 10
permit tcp 2001:DB8:1111:1::/64 any eq 22 sequence 20
deny ipv6 any any log (1 match) sequence 30
Chapter Review
One key to doing well on the exams is to perform repetitive spaced review sessions. Review this chapter’s material using either the tools in the book, DVD, or interactive tools for the same material found on the book’s companion website. Refer to the “Your Study Plan” element for more details. Table 25-3 outlines the key review elements and where you can find them. To better track your study progress, record when you completed these activities in the second column.
Review All the Key Topics
Key Terms You Should Know
Neighbor Discovery Protocol (NDP)
Command References
Tables 25-5 and 25-6 list configuration and verification commands used in this chapter. As an easy review exercise, cover the left column in a table, read the right column, and try to recall the command without looking. Then repeat the exercise, covering the right column, and try to recall what the command does.
Table 25-5 Chapter 25 Configuration Command Reference
Table 25-6 Chapter 25 EXEC Command Reference
Answers to Earlier Practice Problems
Table 25-7 lists the answers to the problems listed earlier in Table 25-2.
