4.1.1 What is an ACL?

Routers make routing decisions based on information in the packet header.

Traffic entering a router interface is routed solely based on information within
the routing table. The router compares the destination IP address with routes
in the routing table to find the best match and then forwards the packet
based on the best match route. That same process can be used to filter
traffic using an access control list (ACL).

An ACL is a series of IOS commands that are used to filter packets based on
information found in the packet header. By default, a router does not have
any ACLs configured. However, when an ACL is applied to an interface, the
router performs the additional task of evaluating all network packets as they
pass through the interface to determine if the packet can be forwarded.

An ACL uses a sequential list of permit or deny statements, known as access

control entries (ACEs).

Note: ACEs are also commonly called ACL statements.

When network traffic passes through an interface configured with an ACL,

the router compares the information within the packet against each ACE, in
sequential order, to determine if the packet matches one of the ACEs. This
process is called packet filtering.

Several tasks performed by routers require the use of ACLs to identify traffic.
The table lists some of these tasks with examples.

Limit network traffic to increase network performance

 A corporate policy prohibits video traffic on the network to reduce the

network load.

 A policy can be enforced using ACLs to block video traffic.

Provide traffic flow control

 A corporate policy requires that routing protocol traffic be limited to

certain links only.

 A policy can be implemented using ACLs to restrict the delivery of

routing updates to only those that come from a known source.

Provide a basic level of security for network access

 Corporate policy demands that access to the Human Resources

network be restricted to authorized users only.
  A policy can be enforced using ACLs to limit access to specified
networks.

Filter traffic based on traffic type

 Corporate policy requires that email traffic be permitted into a

network, but that Telnet access be denied.

 A policy can be implemented using ACLs to filter traffic by type.

Screen hosts to permit or deny access to network services

 Corporate policy requires that access to some file types (e.g., FTP or
HTTP) be limited to user groups.

 A policy can be implemented using ACLs to filter user access to

services.

Provide priority to certain classes of network traffic

 Corporate traffic specifies that voice traffic be forwarded as fast as

possible to avoid any interruption.

 A policy can be implemented using ACLs and QoS services to identify

voice traffic and process it immediately.

4.1.2 Packet Filtering

Packet filtering controls access to a network by analyzing the incoming
and/or outgoing packets and forwarding them or discarding them based on
given criteria. Packet filtering can occur at Layer 3 or Layer 4, as shown in
the figure.
Cisco routers support two types of ACLs:

 Standard ACLs - ACLs only filter at Layer 3 using the source IPv4
address only.

 Extended ACLs - ACLs filter at Layer 3 using the source and / or

destination IPv4 address. They can also filter at Layer 4 using TCP, UDP
ports, and optional protocol type information for finer control.

4.1.3 Numbered and Named ACLs

Numbered ACLs

ACLs number 1 to 99, or 1300 to 1999 are standard ACLs while ACLs number
100 to 199, or 2000 to 2699 are extended ACLs, as shown in the output.

Named ACLs
 Named ACLs is the preferred method to use when configuring ACLs.
Specifically, standard and extended ACLs can be named to provide
information about the purpose of the ACL. For example, naming an
extended ACL FTP-FILTER is far better than having a numbered ACL 100.

The ip access-list global configuration command is used to create a

named ACL, as shown in the following example.

The following summarizes the rules to follow for named ACLs:

 Assign a name to identify the purpose of the ACL.

 Names can contain alphanumeric characters.

 Names cannot contain spaces or punctuation.

 It is suggested that the name be written in CAPITAL LETTERS.

 Entries can be added or deleted within the ACL.

4.1.4 ACL Operation

ACLs define the set of rules that give added control for packets that enter
inbound interfaces, packets that relay through the router, and packets that
exit outbound interfaces of the router.
ACLs can be configured to apply to inbound traffic and outbound traffic, as
shown in the figure.

Note: ACLs do not act on packets that originate from the router itself.
An inbound ACL filters packets before they are routed to the outbound
interface. An inbound ACL is efficient because it saves the overhead of
routing lookups if the packet is discarded. If the packet is permitted by the
ACL, it is then processed for routing. Inbound ACLs are best used to filter
packets when the network attached to an inbound interface is the only
source of packets that need to be examined.
An outbound ACL filters packets after being routed, regardless of the inbound
interface. Incoming packets are routed to the outbound interface and then
they are processed through the outbound ACL. Outbound ACLs are best used
when the same filter will be applied to packets coming from multiple inbound
interfaces before exiting the same outbound interface.
When an ACL is applied to an interface, it follows a specific operating
procedure. For example, here are the operational steps used when traffic has
entered a router interface with an inbound standard IPv4 ACL configured:
1. The router extracts the source IPv4 address from the packet header.

2. The router starts at the top of the ACL and compares the source IPv4
address to each ACE in a sequential order.

3. When a match is made, the router carries out the instruction, either
permitting or denying the packet, and the remaining ACEs in the ACL, if
any, are not analyzed.

4. If the source IPv4 address does not match any ACEs in the ACL, the
packet is discarded because there is an implicit deny ACE
automatically applied to all ACLs.

The last ACE statement of an ACL is always an implicit deny that blocks all
traffic. By default, this statement is automatically implied at the end of an
ACL even though it is hidden and not displayed in the configuration.
Note: An ACL must have at least one permit statement otherwise all traffic
will be denied due to the implicit deny ACE statement.

4.2.1 Wildcard Mask Overview

In the previous topic, you learned about the purpose of ACLs. This topic
explains how ACLs use wildcard masks. An IPv4 ACE uses a 32-bit wildcard
mask to determine which bits of the address to examine for a match.
Wildcard masks are also used by the Open Shortest Path First (OSPF) routing
protocol.
A wildcard mask is similar to a subnet mask in that it uses the ANDing
process to identify which bits in an IPv4 address to match. However, they
differ in the way they match binary 1s and 0s. Unlike a subnet mask, in
which binary 1 is equal to a match and binary 0 is not a match, in a wildcard
mask, the reverse is true.
Wildcard masks use the following rules to match binary 1s and 0s:
 Wildcard mask bit 0 - Match the corresponding bit value in the
address
 Wildcard mask bit 1 - Ignore the corresponding bit value in the
address
The table lists some examples of wildcard masks and what they would
identify.
Wildcard Mask Last Octet (in Binary) Meaning (0- match, 1 - ignore)
0.0.0.0 00000000 Match all octets
0.0.0.63 00111111 >Match the first three octets
>Match the two left most bits of the
last octet
>Ignore the last 6 bits

0.0.0.15 00001111 >Match the first three octets

>Match the two left most bits of the
last octet
>Ignore the last 6 bits

0.0.0.252 11111100 >Match the first three octets

>Match the two left most bits of the
last octet
>Ignore the last 6 bits

0.0.0.255 11111111 >Match the first three octets

>Ignore the last octet
4.2.2 Wildcard Mask Types
Using wildcard masks will take some practice. Refer to the examples to learn
how the wildcard mask is used to filter traffic for one host, one subnet, and a
range of IPv4 addresses.
see how the wildcard mask is used in ACLs.??

>>Wildcard to Match a Host

In this example, the wildcard mask is used to match a specific host IPv4
address. Assume ACL 10 needs an ACE that only permits the host with IPv4
address 192.168.1.1. Recall that “0” equals a match and “1” equals ignore.
To match a specific host IPv4 address, a wildcard mask consisting of all
zeroes (i.e., 0.0.0.0) is required.
The table lists in binary, the host IPv4 address, the wildcard mask, and the
permitted IPv4 address.
The 0.0.0.0 wildcard mask stipulates that every bit must match exactly.
Therefore, when the ACE is processed, the wildcard mask will permit only the
192.168.1.1 address. The resulting ACE in ACL 10 would be access-list 10
permit 192.168.1.1 0.0.0.0

Decimal Binary

IPv4 address 192.168.1.1 11000000.10101000.00000001.0000000

1
Wildcard Mask 0.0.0.0 00000000.00000000.00000000.0000000
0
Permitted IPv4 Address 192.168.1.1 11000000.10101000.00000001.0000000
1

Wildcard Mask to Match an IPv4 Subnet

In this example, ACL 10 needs an ACE that permits all hosts in the
192.168.1.0/24 network. The wildcard mask 0.0.0.255 stipulates that the
very first three octets must match exactly but the fourth octet does not.
The table lists in binary, the host IPv4 address, the wildcard mask, and the
permitted IPv4 addresses.
When processed, the wildcard mask 0.0.0.255 permits all hosts in the
192.168.1.0/24 network. The resulting ACE in ACL 10 would be access-list
10 permit 192.168.1.0 0.0.0.255.

Decimal Binary

IPv4 address 192.168.1.1 11000000.10101000.00000001.0000000

1
Wildcard Mask 0.0.0.255 00000000.00000000.00000000.1111111
1
Permitted IPv4 Address 192.168.1.1 11000000.10101000.00000001.0000000
To 1
192.168.1.25
4 11000000.10101000.00000001.1111111
1

Wildcard Mask to Match an IPv4 Address Range

In this example, ACL 10 needs an ACE that permits all hosts in the
192.168.16.0/24, 192.168.17.0/24, …, 192.168.31.0/24 networks. The
wildcard mask 0.0.15.255 would correctly filter that range of addresses.
The table lists in binary the host IPv4 address, the wildcard mask, and the
permitted IPv4 addresses.
The highlighted wildcard mask bits identify which bits of the IPv4 address
must match. When processed, the wildcard mask 0.0.15.255 permits all
hosts in the 192.168.16.0/24 to 192.168.31.0/24 networks. The resulting ACE
in ACL 10 would be access-list 10 permit 192.168.16.0 0.0.15.255
 Decimal Binary

IPv4 address 192.168.16.0 11000000.10101000.00010000.0000000

1
Wildcard Mask 0.0.1.255 00000000.00000000.00001111.1111111
1
Permitted IPv4 Address 192.168.16.1 11000000.10101000.00010000.0000000
To 1
192.168.1.25
4 11000000.10101000.00011111.1111111
1

4.2.3 Wildcard Mask Calculation

Calculating wildcard masks can be challenging. One shortcut method is to
subtract the subnet mask from 255.255.255.255. Refer to the examples to
learn how to calculate the wildcard mask using the subnet mask.

how to calculate each wildcard mask.??

Example 1
Assume you wanted an ACE in ACL 10 to permit access to all users in the
192.168.3.0/24 network. To calculate the wildcard mask, subtract the subnet
mask (i.e., 255.255.255.0) from 255.255.255.255, as shown in the table.
The solution produces the wildcard mask 0.0.0.255. Therefore, the ACE would
be access-list 10 permit 192.168.3.0 0.0.0.255.

Starting value 255.255.255.255

Substract the subnet mask -255.255.255.0
Resulting wildcard mask 0.0.0.255

Example 2
In this example, assume you wanted an ACE in ACL 10 to permit network
access for the 14 users in the subnet 192.168.3.32/28. Subtract the subnet
(i.e., 255.255.255.240) from 255.255.255.255, as shown in the table.
This solution produces the wildcard mask 0.0.0.15. Therefore, the ACE would
be access-list 10 permit 192.168.3.32 0.0.0.15.

Starting value 255.255.255.255

Substract the subnet mask -255.255.255.240
Resulting wildcard mask 0.0.0.15
Example 3
In this example, assume you needed an ACE in ACL 10 to permit only
networks 192.168.10.0 and 192.168.11.0. These two networks could be
summarized as 192.168.10.0/23 which is a subnet mask of 255.255.254.0.
Again, you subtract 255.255.254.0 subnet mask from 255.255.255.255, as
shown in the table.
This solution produces the wildcard mask 0.0.1.255. Therefore, the ACE
would be access-list 10 permit 192.168.10.0 0.0.1.255

Starting value 255.255.255.255

Substract the subnet mask -255.255.254.0
Resulting wildcard mask 0.0.1.255

Example 4
Consider an example in which you need an ACL number 10 to match
networks in the range between 192.168.16.0/24 to 192.168.31.0/24. This
network range could be summarized as 192.168.16.0/20 which is a subnet
mask of 255.255.240.0. Therefore, subtract 255.255.240.0 subnet mask from
255.255.255.255, as shown in the table.
This solution produces the wildcard mask 0.0.15.255. Therefore, the ACE
would be access-list 10 permit 192.168.16.0 0.0.15.255.

Example 4
Consider an example in which you need an ACL number 10 to match
networks in the range between 192.168.16.0/24 to 192.168.31.0/24. This
network range could be summarized as 192.168.16.0/20 which is a subnet
mask of 255.255.240.0. Therefore, subtract 255.255.240.0 subnet mask from
255.255.255.255, as shown in the table.
This solution produces the wildcard mask 0.0.15.255. Therefore, the ACE
would be access-list 10 permit 192.168.16.0 0.0.15.255.
Starting value 255.255.255.255
Substract the subnet mask -255.255.240.0
Resulting wildcard mask 0.0.15.255

4.2.4 Wildcard Mask Keywords

Working with decimal representations of binary wildcard mask bits can be
tedious. To simplify this task, the Cisco IOS provides two keywords to identify
the most common uses of wildcard masking. Keywords reduce ACL
keystrokes but more importantly, keywords make it easier to read the ACE.
The two keywords are:
 host - This keyword substitutes for the 0.0.0.0 mask. This mask states
that all IPv4 address bits must match to filter just one host address.
  any - This keyword substitutes for the 255.255.255.255 mask. This
mask says to ignore the entire IPv4 address or to accept any
addresses.
For example, in the command output, two ACLs are configured. The ACL 10
ACE permits only the 192.168.10.10 host and the ACL 11 ACE permits all
hosts.

Alternatively, the keywords host and any could have been used to replace
the highlighted output.
The following commands accomplish the same task as the previous
commands.

4.3.1 Create an ACL

In a previous topic, you learned about what an ACL does and why it is
important. In this topic, you will learn about creating ACLs.
All access control lists (ACLs) must be planned. However, this is especially
true for ACLs requiring multiple access control entries (ACEs).
When configuring a complex ACL, it is suggested that you:
 Use a text editor and write out the specifics of the policy to be
implemented.
 Add the IOS configuration commands to accomplish those tasks.
 Include remarks to document the ACL.
 Copy and paste the commands onto the device.
 Always thoroughly test an ACL to ensure that it correctly applies the
desired policy.
These recommendations enable you to create the ACL thoughtfully without
impacting the traffic on the network.

4.3.2 Numbered Standard IPv4 ACL Syntax

To create a numbered standard ACL, use the following global configuration
command:
Use the no access-list access-list-number global configuration command to
remove a numbered standard ACL.
The table provides a detailed explanation of the syntax for a standard ACL.

Parameter Description
access-list- >This is the decimal number of the ACL.
number >Standard ACL number range is 1 to 99 or 1300 to
1999.
Deny This denies access if the condition is matched
Permit This permits access if the condition is matched
remark text >(Optional) This adds a text entry for documentation
purposes.
>Remarks are extremely useful, especially in longer or
more complex ACLs.
>Each remark is limited to 100 characters.
Source >This identifies the source network or host address to
filter.
>Use the any keyword to specify all networks.
>Use the host ip-address keyword or simply enter an
ip-address (without the host keyword) to
identify a specific IP address.
source-wildcard (Optional) This is a 32-bit wildcard mask that is applied
to the source. If omitted, a default 0.0.0.0 mask is
assumed.
log >(Optional) This keyword generates an informational
message whenever the ACE is matched.
>Message includes ACL number, matched condition
(i.e., permitted or denied), source address, and number
of packets.
>This message is generated for the first matched
packet.
>Unfortunately, ACL logging can be CPU intensive and
can negatively affect other functions therefore
it should only be implemented for troubleshooting or
security reasons
4.3.3 Named Standard IPv4 ACL Syntax
Naming an ACL makes it easier to understand its function. To create a named
standard ACL, use the following global configuration command:
Router(config)# ip access-list standard access-list-name
This command enters the named standard configuration mode where you
configure the ACL ACEs.
ACL names are alphanumeric, case sensitive, and must be unique.
Capitalizing ACL names is not required but makes them stand out when
viewing the running-config output. It also makes it less likely that you will
accidentally create two different ACLs with the same name but with different
uses of capitalization.
Note: Use the no ip access-list standard access-list-name global
configuration command to remove a named standard IPv4 ACL.
In the example, a named standard IPv4 ACL called NO-ACCESS is created.
Notice that the prompt changes to named standard ACL configuration mode.
ACE statements are entered in the named standard ACL sub configuration
mode. Use the help facility to view all the named standard ACL ACE options.
The three highlighted options are configured similar to the numbered
standard ACL. Unlike the numbered ACL method, there is no need to repeat
the initial ip access-list command for each ACE
R1(config)# ip access-list standard NO-ACCESS
R1(config-std-nacl)# ?
Standard Access List configuration commands:
<1-2147483647> Sequence Number
default Set a command to its defaults
deny Specify packets to reject
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
R1(config-std-nacl)#

4.3.4 Numbered Extended IPv4 ACL Syntax

The procedural steps for configuring extended ACLs are the same as for
standard ACLs. The extended ACL is first configured, and then it is activated
on an interface. However, the command syntax and parameters are more
complex to support the additional features provided by extended ACLs.
To create a numbered extended ACL, use the following global configuration
command:

Router(config)# access-list access-list-number {deny | permit | remark

text} protocol source source-wildcard [ operator {port}] destination
destination-wildcard [operator {port}] [established] [log]

Use the no access-list access-list-number global configuration command to

remove an extended ACL.
Although there are many keywords and parameters for extended ACLs, it is
not necessary to use all of them when configuring an extended ACL. The
table provides a detailed explanation of the syntax for an extended ACL.

Parameter Description
access-list- >This is the decimal number of the ACL.
number >Extended ACL number range is 100 to 199 and 2000 to
2699.
Deny This denies access if the condition is matched
Permit This permits access if the condition is matched.
remark text >(Optional) This adds a text entry for documentation
purposes.
>Each remark is limited to 100 characters
Protocol >Name or number of an internet protocol.
>Common keywords include ip, tcp, udp, and icmp.
>The ip keyword matches all IP protocols
Source >This identifies the source network or host address to
filter.
>Use the any keyword to specify all networks.
>Use the host ip-address keyword or simply enter an ip-
address (without the host keyword) to
identify a specific IP address.
source- Optional) This is a 32-bit wildcard mask that is applied to
wildcard the source.
destination- (Optional) This is a 32-bit wildcard mask that is applied to
wildcard the destination.
Destination >This identifies the destination network or host address to
filter.
>Use the any keyword to specify all networks.
>Use the host ip-address keyword or ip-address.
Established >(Optional) For the TCP protocol only.
>This is a 1st generation firewall feature..
Port Optional) The decimal number or name of a TCP or UDP
port
Operator >(Optional) This compares source or destination ports.
>Some operators include It (less than), gt (greater than),
eq (equal), and neq (not equal)
Log >(Optional) This keyword generates an informational
message whenever the ACE is matched.
>Message includes ACL number, matched condition (i.e.,
permitted or denied), source address, and number of
packets.
>This message includes ACL number, matched condition
(i.e., permitted or denied), source address, and number of
packets.
 >This message is generated for the first matched packet.
>This keyword should only be implemented for
troubleshooting or security reasons.

The command to apply an extended IPv4 ACL to an interface is the same as

the command
used for standard IPv4 ACLs.

Router(config-if)# ip access-group {access-list-number | access-list-

name} {in | out}

To remove an ACL from an interface, first enter the no ip access-

group interface configuration command. To remove the ACL from the router,
use the no access-list global configuration command.
Note: The internal logic applied to the ordering of standard ACL statements
does not apply to extended ACLs. The order in which the statements are
entered during configuration is the order they are displayed and processed.

4.3.5 Protocols and Port Numbers

Extended ACLs can filter on many different types of internet
protocols and ports. Click each button for more information about
the internet protocols and ports on which extended ACLs can filter.

Protocol Options
The four highlighted protocols are the most popular options.
Note: Use the ? to get help when entering a complex ACE.
Note: If an internet protocol is not listed, then the IP protocol number could
be specified. For instance, the ICMP protocol number 1, TCP is 6, and UDP is
17.
R1(config)# access-list 100 permit ?
<0-255> An IP protocol number
ahp Authentication Header Protocol
dvmrp dvmrp
eigrp Cisco's EIGRP routing protocol
esp Encapsulation Security Payload
gre Cisco's GRE tunneling
icmp Internet Control Message Protocol
igmp Internet Gateway Message Protocol
ip Any Internet Protocol
ipinip IP in IP tunneling
nos KA9Q NOS compatible IP over IP tunneling
object-group Service object group
ospf OSPF routing protocol
pcp Payload Compression Protocol
pim Protocol Independent Multicast
tcp Transmission Control Protocol
udp User Datagram Protocol
R1(config)# access-list 100 permit

Port Keyword Options

Selecting a protocol influences port options. For instance, selecting the:
 tcp protocol would provide TCP related ports options
 udp protocol would provide UDP specific ports options
 icmp protocol would provide ICMP related ports (i.e., message) options
Again, notice how many TCP port options are available. The highlighted ports
are popular options.
Port names or number can be specified. However, port names make it easier
to understand the purpose of an ACE. Notice how some common ports
names (e.g., SSH and HTTPS) are not listed. For these protocols, port
numbers will have to be specified.

R1(config)# access-list 100 permit tcp any any eq ?

<0-65535> Port number
bgp Border Gateway Protocol (179)
chargen Character generator (19)
cmd Remote commands (rcmd, 514)
daytime Daytime (13)
discard Discard (9)
domain Domain Name Service (53)
echo Echo (7)
exec Exec (rsh, 512)
finger Finger (79)
ftp File Transfer Protocol (21)
ftp-data FTP data connections (20)
gopher Gopher (70)
hostname NIC hostname server (101)
ident Ident Protocol (113)
irc Internet Relay Chat (194)
klogin Kerberos login (543)
kshell Kerberos shell (544)
login Login (rlogin, 513)
lpd Printer service (515)
msrpc MS Remote Procedure Call (135)
nntp Network News Transport Protocol (119)
onep-plain Onep Cleartext (15001)
onep-tls Onep TLS (15002)
pim-auto-rp PIM Auto-RP (496)
pop2 Post Office Protocol v2 (109)
pop3 Post Office Protocol v3 (110)
smtp Simple Mail Transport Protocol (25)
sunrpc Sun Remote Procedure Call (111)
syslog Syslog (514) (111)
tacacs TAC Access Control System (49)
talk Talk (517)
telnet Telnet (23)
time Time (37)
uucp Unix-to-Unix Copy Program (540)
whois Nicname (43)
www World Wide Web (HTTP, 80)

4.3.6 Protocols and Port Numbers Configuration Examples

Extended ACLs can filter on different port number and port name options.
This example configures an extended ACL 100 to filter HTTP traffic. The first
ACE uses the www port name. The second ACE uses the port number 80.
Both ACEs achieve exactly the same result.
R1(config)# access-list 100 permit tcp any any eq www
R1(config)# !or...
R1(config)# access-list 100 permit tcp any any eq 80

Configuring the port number is required when there is not a specific protocol
name listed such as SSH (port number 22) or an HTTPS (port number 443),
as shown in the next example.
R1(config)# access-list 100 permit tcp any any eq 22
R1(config)# access-list 100 permit tcp any any eq 443
R1(config)#

4.3.7 TCP Established Extended ACL

TCP can also perform basic stateful firewall services using the
TCP established keyword. The keyword enables inside traffic to exit the
inside private network and permits the returning reply traffic to enter the
inside private network, as shown in the figure.
However, TCP traffic generated by an outside host and attempting to
communicate with an inside host is denied.
The established keyword can be used to permit only the return HTTP traffic
from requested websites, while denying all other traffic.
In the topology, the design for this example shows that ACL 110, which was
previously configured, will filter traffic from the inside private network. ACL
120, using the established keyword, will filter traffic coming into the inside
private network from the outside public network.

In the example, ACL 120 is configured to only permit returning web traffic to
the inside hosts. The new ACL is then applied outbound on the R1 G0/0/0
interface. The show access-lists command displays both ACLs. Notice from
the match statistics that inside hosts have been accessing the secure web
resources from the internet.
R1(config)# access-list 120 permit tcp any 192.168.10.0 0.0.0.255
established
R1(config)# interface g0/0/0
R1(config-if)# ip access-group 120 out
R1(config-if)# end
R1# show access-lists
Extended IP access list 110
10 permit tcp 192.168.10.0 0.0.0.255 any eq www
20 permit tcp 192.168.10.0 0.0.0.255 any eq 443 (657 matches)
Extended IP access list 120
10 permit tcp any 192.168.10.0 0.0.0.255 established (1166 matches)
R1#

Notice that the permit secure HTTPS counters (i.e., eq 443) in ACL 110 and
the return established counters in ACL 120 have increased.
The established parameter allows only responses to traffic that originates
from the 192.168.10.0/24 network to return to that network. Specifically, a
match occurs if the returning TCP segment has the ACK or reset (RST) flag
bits set. This indicates that the packet belongs to an existing connection.
Without the established parameter in the ACL statement, clients could send
traffic to a web server, and receive traffic returning from the web server. All
traffic would be permitted.

4.3.8 Named Extended IPv4 ACL Syntax

Naming an ACL makes it easier to understand its function. To create a named
extended ACL, use the following global configuration command:

Router(config)# ip access-list extended access-list-name

This command enters the named extended configuration mode. Recall that
ACL names are alphanumeric, case sensitive, and must be unique.
In the example, a named extended ACL called NO-FTP-ACCESS is created and
the prompt changed to named extended ACL configuration mode. ACE
statements are entered in the
named extended ACL sub configuration mode.

R1(config)# ip access-list extended NO-FTP-ACCESS

R1(config-ext-nacl)#

4.3.9 Named Extended IPv4 ACL Example

Named extended ACLs are created in essentially the same way that named
standard ACLs are created.
The topology in the figure is used to demonstrate configuring and applying
two named extended IPv4 ACLs to an interface:
 SURFING - This will permit inside HTTP and HTTPS traffic to exit to the
internet.
 BROWSING - This will only permit returning web traffic to the inside
hosts while all other traffic exiting the R1 G0/0/0 interface is implicitly
denied.

The example shows the configuration for the inbound SURFING ACL and the
outbound BROWSING ACL.
The SURFING ACL permits HTTP and HTTPS traffic from inside users to exit
the G0/0/1 interface connected to the internet. Web traffic returning from the
internet is permitted back into the inside private network by the BROWSING
ACL.
The SURFING ACL is applied inbound and the BROWSING ACL applied
outbound on the R1 G0/0/0 interface, as shown in the output.
Inside hosts have been accessing the secure web resources from the
internet. The show access-lists command is used to verify the ACL
statistics. Notice that the permit secure HTTPS counters (i.e., eq 443) in the
SURFING ACL and the return established counters in the BROWSING ACL
have increased.

R1(config)# ip access-list extended SURFING

R1(config-ext-nacl)# Remark Permits inside HTTP and HTTPS traffic
R1(config-ext-nacl)# permit tcp 192.168.10.0 0.0.0.255 any eq 80
R1(config-ext-nacl)# permit tcp 192.168.10.0 0.0.0.255 any eq 443
R1(config-ext-nacl)# exit
R1(config)#
R1(config)# ip access-list extended BROWSING
R1(config-ext-nacl)# Remark Only permit returning HTTP and HTTPS
traffic
R1(config-ext-nacl)# permit tcp any 192.168.10.0 0.0.0.255
established
R1(config-ext-nacl)# exit
R1(config)# interface g0/0/0
R1(config-if)# ip access-group SURFING in
R1(config-if)# ip access-group BROWSING out
R1(config-if)# end
R1# show access-lists
Extended IP access list SURFING
10 permit tcp 192.168.10.0 0.0.0.255 any eq www
20 permit tcp 192.168.10.0 0.0.0.255 any eq 443 (124 matches)
Extended IP access list BROWSING
10 permit tcp any 192.168.10.0 0.0.0.255 established (369 matches)
R1#

4.4 Named Standard IPv4 ACL Syntax

4.4.1 Two Methods to Modify an ACL
After an ACL is configured, it may need to be modified. ACLs with multiple
ACEs can be complex to configure. Sometimes the configured ACE does not
yield the expected behaviors. For these reasons, ACLs may initially require a
bit of trial and error to achieve the desired filtering result.
This section will discuss two methods to use when modifying an ACL:
 Use a Text Editor
 Use Sequence Numbers

4.4.2 Text Editor Method

ACLs with multiple ACEs should be created in a text editor. This allows you to
plan the required ACEs, create the ACL, and then paste it into the router
interface. It also simplifies the tasks to edit and fix an ACL.
For example, assume ACL 1 was entered incorrectly using 19 instead
of 192 for the first octet, as shown in the running configuration.

R1# show run | section access-list

access-list 1 deny 19.168.10.10
access-list 1 permit 192.168.10.0 0.0.0.255
R1#

In the example, the first ACE should have been to deny the host at
192.168.10.10. However, the ACE was incorrectly entered.
To correct the error:
 Copy the ACL from the running configuration and paste it into the text
editor.
 Make the necessary changes.
 Remove the previously configured ACL on the router. Otherwise,
pasting the edited ACL commands will only append (i.e., add) to the
existing ACL ACEs on the router.
 Copy and paste the edited ACL back to the router.
Assume that ACL 1 has now been corrected. Therefore, the incorrect ACL
must be deleted, and the corrected ACL 1 statements must be pasted in
global configuration mode, as shown in the output.
R1(config)# no access-list 1
R1(config)#
R1(config)# access-list 1 deny 19.168.10.10
R1(config)# access-list 1 permit 192.168.10.0 0.0.0.255
R1(config)#

4.4.3 Sequence Number Method

An ACL ACE can also be deleted or added using the ACL sequence numbers.
Sequence numbers are automatically assigned when an ACE is entered.
These numbers are listed in the show access-lists command. The show
running-config command does not display sequence numbers.
In the previous example, the incorrect ACE for ACL 1 is using sequence
number 10, as shown in the example.

R1# show access-lists

Standard IP access list 1
10 deny 19.168.10.10
20 permit 192.168.10.0, wildcard bits 0.0.0.255
R1#

Use the ip access-list standard command to edit an ACL. Statements

cannot be overwritten using the same sequence number as an existing
statement. Therefore, the current statement must be deleted first with
the no 10 command. Then the correct ACE can be added using sequence
number 10 is configured. Verify the changes using the show access-
lists command, as shown in the example.

R1# conf t
R1(config)# ip access-list standard 1
R1(config-std-nacl)# no 10
R1(config-std-nacl)# 10 deny host 192.168.10.10
R1(config-std-nacl)# end
R1# show access-lists
Standard IP access list 1
10 deny 192.168.10.10
20 permit 192.168.10.0, wildcard bits 0.0.0.255
R1#

4.4.4 Syntax Checker - Modify IPv4 ACLs

Modify an ACL using sequence numbers.

Use the show access-lists command to verify the configured ACLs.

R1#show access-lists
Standard IP access list 1
10 deny 19.168.10.10
20 permit 192.168.10.0, wildcard bits 0.0.0.255
You notice that ACE 10 is incorrect and needs to be edited. Enter global
configuration mode and use the ip access-list standard command for
ACL 1.
R1#configure terminal
R1(config)#ip access-list standard 1
An incorrect ACE must be deleted and then re-entered. Remove the ACE
with sequence number 10.
R1(config-std-nacl)#no 10
Next, re-enter the correct ACE using sequence number 10 to deny the host
with the IP address 192.168.10.10 access outside of LAN 1 and return to
privileged EXEC mode using the end command.
R1(config-std-nacl)#10 deny host 192.168.10.10
R1(config-std-nacl)#end
Verify the new entry using the show access-lists command.
R1#show access-lists
Standard IP access list 1
10 deny 192.168.10.10
20 permit 192.168.10.0, wildcard bits 0.0.0.255
You have successfully modified an IPv4 numbered ACL on R1.

4.5.1 ACL Configuration Guidelines

An ACL is made up of one or more access control entries (ACEs) or
statements. When configuring and applying an ACL, be aware of the
guidelines summarized in this list:
 Create an ACL globally and then apply it.
 Ensure the last statement is an implicit deny any or deny ip any
any.
 Remember that statement order is important because ACLs are
processed top-down.
 As soon as a statement is matched the ACL is exited.
 Always filter from the most specific to the most generic. For example,
deny a specific host and then permit all other hosts.
 Remember that only one ACL is allowed per interface, per protocol, per
direction.
 Remember that new statements for an existing ACL are added to the
bottom of the ACL by default.
 Remember that router-generated packets are not filtered by outbound
ACLs.
 Place standard ACLs as close to the destination as possible.
 Place extended ACLs as close to the source as possible.

4.5.2 Apply an ACL

After creating an ACL, the administrator can apply it in a number of different
ways. The following shows the command syntax to apply an ACL to an
interface or to the vty lines.

Router(config-if)# ip access-group {acl-# | name} {in | out}

Router(config-line)# ip access-class {acl-# | name} {in | out}
The figure below shows a named standard ACL applied to outbound
traffic.

R1(config)# ip access-list standard NO_ACCESS

R1(config-std-nacl)# deny host 192.168.11.10
R1(config-std-nacl)# permit any
R1(config-std-nacl)# exit
R1(config)# interface g0/0
R1(config-if)# ip access-group NO_ACCESS out

This figure shows two named extended ACLs. The SURFING ACL is applied to
inbound traffic and the BROWSING ACL is applied to outbound traffic.
Named Extended ACL Example
R1(config)# ip access-list extended SURFING
R1(config-ext-nacl)# permit tcp 192.168.10.0 0.0.0.255 any eq 80
R1(config-ext-nacl)# permit tcp 192.168.10.0 0.0.0.255 any eq 443
R1(config-ext-nacl)# exit
R1(config)# ip access-list extended BROWSING
R1(config-ext-nacl)# permit tcp any 192.168.10.0 0.0.0.255
established
R1(config-ext-nacl)# exit
R1(config)# interface g0/0
R1(config-if)# ip access-group SURFING in
R1(config-if)# ip access-group BROWSING out

Named ACL on VTY Lines with Logging

Enabling the log parameter on a Cisco router or switch seriously affects the
performance of that device. The log parameter should only be used when the
network is under attack, and an administrator is trying to determine who the
attacker is.

Applying ACLs to interfaces and lines is just one of their many possible uses.
ACLs are also an integral part of other security configurations, such as
network address translation (NAT), zone-based firewalls, and virtual private
networks.

R1(config)# ip access-list standard VTY_ACCESS

R1(config-std-nacl)# permit 192.168.10.10 log
R1(config-std-nacl)# deny any
R1(config-std-nacl)# exit
R1(config)# line vty 0 4
R1(config-line)# access-class VTY_ACCESS in
R1(config-line)# end
R1#
R1# !The administrator accesses the vty lines from 192.168.10.10
R1#
*Feb 26 18:58:30.579: %SEC-6-IPACCESSLOGNP: list VTY_ACCESS
permitted 0
192.168.10.10 -> 0.0.0.0, 5 packets
R1# show access-lists
Standard IP access list VTY_ACCESS
10 permit 192.168.10.10 log (6 matches)
20 deny any

To remove an ACL from an interface, first enter the no ip access-group

interface configuration command. However, the ACL will still be configured
on the router. To remove the ACL from the router, use the no access-list
global configuration command.

4.5.3 Where to Place ACLs

Every ACL should be placed where it is the most efficient.
The figure illustrates where standard and extended ACLs should be located in
an enterprise network. Assume the objective is to prevent traffic that
originates in the 192.168.10.0/24 network from reaching the
192.168.30.0/24 network.
<Extended ACLs are usually placed near the source.
>Extended ACLs are usually placed near the source.
Extended ACLs should be located as close as possible to the source
of the traffic to be filtered. This way, undesirable traffic is denied
close to the source network without crossing the network
infrastructure.
Standard ACLs should be located as close to the destination as
possible. If a standard ACL was placed at the source of the traffic,
the 'permit' or 'deny' will occur based on the given source address
no matter where the traffic is destined.
Placement of the ACL and therefore, the type of ACL used, may also
depend on a variety of factors as listed in the table.

Factors Influencing ACL Explanation

Placement
The extent of organizational Placement of the ACL can depend on
control whether or not the organization has
control of both the source and
destination networks
Bandwidth of the networks It may be desirable to filter
involved unwanted traffic at the source
to prevent transmission of
bandwidth-consuming traffic
Ease of configuration >It may be easier to implement
 an ACL at the destination, but
traffic will use bandwidth
unnecessarily.
>An extended ACL could be
used on each router where the
traffic originated. This would
save bandwidth by filtering the
traffic at the source, but it
would require creating extended
ACLs on multiple routers.

4.5.4 Standard ACL Placement Example

Following the guidelines for ACL placement, standard ACLs should be located
as close to the destination as possible.
In the figure, the administrator wants to prevent traffic originating in the
192.168.10.0/24 network from reaching the 192.168.30.0/24 network.
Block all traffic from 192.168.10.0/24 to 192.168.30.0/24.

Filters traffic from 192.168.10.0/24 to all destinations reachable by

R3

Filters traffic from 192.168.10.0/24 only to 192.168.30.0/24.

Following the basic placement guidelines, the administrator would place a

standard ACL on router R3. There are two possible interfaces on R3 to apply
the standard ACL:
 R3 S0/1/1 interface (inbound) - The standard ACL can be applied
inbound on the R3 S0/1/1 interface to deny traffic from .10 network.
However, it would also filter .10 traffic to the 192.168.31.0/24 (.31 in
this example) network. Therefore, the standard ACL should not be
applied to this interface.
 R3 G0/0/0 interface (outbound) - The standard ACL can be applied
outbound on the R3 G0/0/0 interface. This will not affect other
networks that are reachable by R3. Packets from .10 network will still
be able to reach the .31 network. This is the best interface to place the
standard ACL to meet the traffic requirements.

4.5.7 Extended ACL Placement Example

Extended ACLs should be located as close to the source as possible. This
prevents unwanted traffic from being sent across multiple networks only to
be denied when it reaches its destination.
However, the organization can only place ACLs on devices that they control.
Therefore, the extended ACL placement must be determined in the context
of where organizational control extends.
In the figure, for example, Company A wants to deny Telnet and FTP traffic to
Company B’s 192.168.30.0/24 network from their 192.168.11.0/24 network
while permitting all other traffic.
  Examines all traffic before exiting R1 S0/1/0.

 Block FTP and Telnet traffic from 192.168.11.0/24 to

192.168.30.0/24.

 Examines traffic only from 192.168.11.0/24.

There are several ways to accomplish these goals. An extended ACL on R3

would accomplish the task, but the administrator does not control R3. In
addition, this solution allows unwanted traffic to cross the entire network,
only to be blocked at the destination. This affects overall network efficiency.
The solution is to place an extended ACL on R1 that specifies both source
and destination addresses.
There are two possible interfaces on R1 to apply the extended ACL:
R1 S0/1/0 interface (outbound) - The extended ACL can be applied
outbound on the S0/1/0 interface. However, this solution will process all
packets leaving R1 including packets from 192.168.10.0/24.
R1 G0/0/1 interface (inbound) - The extended ACL can be applied
inbound on the G0/0/1 so that only packets from the 192.168.11.0/24
network are subject to ACL processing on R1. Because the filter is to be
limited to only those packets leaving the 192.168.11.0/24 network, applying
the extended ACL to G0/0/1 is the best solution.

4.6.1 Mitigate Spoofing Attacks

ACLs can be used to mitigate many network threats, such as IP address
spoofing and denial of service (DoS) attacks. Most DoS attacks use some
type of spoofing. IP address spoofing overrides the normal packet creation
process by inserting a custom IP header with a different source IP address.
Attackers can hide their identity by spoofing the source IP address.
There are many well-known classes of IP addresses that should never be
seen as source IP addresses for traffic entering an organization’s network.
For example, in the figure the S0/0/0 interface is attached to the internet and
should never accept inbound packets from the following addresses:
 All zeros addresses
 Broadcast addresses
 Local host addresses (127.0.0.0/8)
 Automatic Private IP Addressing (APIPA) addresses (169.254.0.0/16)
 Reserved private addresses (RFC 1918)
 IP multicast address range (224.0.0.0/4)
The 192.168.1.0/24 network is attached to the R1 G0/0 interface. This
interface should only allow inbound packets with a source address from that
network. The ACL for G0/0 shown in the figure will only permit inbound
packets from the 192.168.1.0/24 network. All others will be discarded.

Inbound on S0/0/0:
R1(config)# access-list 150 deny ip host 0.0.0.0 any
R1(config)# access-list 150 deny ip 10.0.0.0 0.255.255.255 any
R1(config)# access-list 150 deny ip 127.0.0.0 0.255.255.255 any
R1(config)# access-list 150 deny ip 172.16.0.0 0.15.255.255 any
R1(config)# access-list 150 deny ip 192.168.0.0 0.0.255.255 any
R1(config)# access-list 150 deny ip 224.0.0.0 15.255.255.255 any
R1(config)# access-list 150 deny ip host 255.255.255.255 any

…….
Inbound on G0/0:

R1(config)# access-list 105 permit ip 192.168.1.0 0.0.0.255 any

4.6.2 Permit Necessary Traffic through a Firewall

An effective strategy for mitigating attacks is to explicitly permit only certain
types of traffic through a firewall. For example, Domain Name System (DNS),
Simple Mail Transfer Protocol (SMTP), and File Transfer Protocol (FTP) are
services that often must be allowed through a firewall. It is also common to
configure a firewall so that it permits administrators remote access through
the firewall. Secure Shell (SSH), syslog, and Simple Network Management
Protocol (SNMP) are examples of services that a router may need to include.
While many of these services are useful, they should be controlled and
monitored. Exploitation of these services leads to security vulnerabilities.

The figure shows an example topology with ACL configurations to permit

specific services on the Serial 0/0/0 interface.

Inbound on S0/0/0:
R1(config)# access-list 180 permit udp any host 192.168.20.2 eq
domain
R1(config)# access-list 180 permit tcp any host 192.168.20.2 eq
smtp
R1(config)# access-list 180 permit tcp any host 192.168.20.2 eq ftp
R1(config)# access-list 180 permit tcp host 200.5.5.5 host 10.0.1.1
eq 22
R1(config)# access-list 180 permit udp host 200.5.5.5 host 10.0.1.1
eq syslog
R1(config)# access-list 180 permit udp host 200.5.5.5 host 10.0.1.1
eq snmptrap

4.6.3 Mitigate ICMP Attacks

Hackers can use Internet Control Message Protocol (ICMP) echo packets
(pings) to discover subnets and hosts on a protected network and to
generate DoS flood attacks. Hackers can use ICMP redirect messages to alter
host routing tables. Both ICMP echo and redirect messages should be blocked
inbound by the router.
Several ICMP messages are recommended for proper network operation and
should be allowed into the internal network:
 Echo reply - Allows users to ping external hosts.
 Source quench - Requests that the sender decrease the traffic rate of
messages.
 Unreachable - Generated for packets that are administratively denied by
an ACL.
Several ICMP messages are required for proper network operation and should
be allowed to exit the network:
 Echo - Allows users to ping external hosts.
 Parameter problem - Informs the host of packet header problems.
 Packet too big - Enables packet maximum transmission unit (MTU)
discovery.
 Source quench - Throttles down traffic when necessary.
As a rule, block all other ICMP message types outbound.
ACLs are used to block IP address spoofing, selectively permit specific
services through a firewall, and to allow only required ICMP messages. The
figure shows a sample topology and possible ACL configurations to permit
specific ICMP services on the G0/0 and S0/0/0 interfaces.

Inbound on S0/0/0:
R1(config)# access-list 112 permit icmp any any echo-reply
R1(config)# access-list 112 permit icmp any any source-quench
R1(config)# access-list 112 permit icmp any any unreachable
R1(config)# access-list 112 deny icmp any any
R1(config)# access-list 112 permit ip any any

---------------------
Inbound on S0/0/0:

R1(config)# access-list 114 permit icmp 192.168.1.0 0.0.0.255 any

echo
R1(config)# access-list 114 permit icmp 192.168.1.0 0.0.0.255 any
parameter-problem

4.6.4 Mitigate SNMP Attacks

Management protocols, such as SNMP, are useful for remote monitoring and
management of networked devices. However, they can still be exploited. If
SNMP is necessary, exploitation of SNMP vulnerabilities can be mitigated by
applying interface ACLs to filter SNMP packets from non-authorized systems.
An exploit may still be possible if the SNMP packet is sourced from an
address that has been spoofed and is permitted by the ACL.

These security measures are helpful, but the most effective means of
exploitation prevention is to disable the SNMP server on IOS devices for
which it is not required. As shown in the figure, use the command no snmp-
server to disable SNMP services on Cisco IOS devices.

Router(config)# no snmp-server

4.7.1 IPv6 ACL Overview

In recent years, many networks have begun the transition to an IPv6

environment. Part of the need for the transition to IPv6 is because of the
inherent weaknesses in IPv4.

Unfortunately, as the migration to IPv6 continues, IPv6 attacks are becoming

more pervasive. IPv4 will not disappear overnight. IPv4 will coexist with IPv6
and then gradually be replaced by IPv6. This creates potential security holes.
An example of a security concern is threat actors leveraging IPv4 to exploit
IPv6 in dual stack environments. Dual stack is an integration method in
which a device has connectivity to both IPv4 and IPv6 networks. In a dual
stack environment devices operate with two IP protocol stacks.
Threat actor can accomplish stealth attacks that result in trust exploitation
by using dual-stacked hosts, rogue Neighbor Discovery Protocol (NDP)
messages, and tunneling techniques. Teredo tunneling, for example, is an
IPv6 transition technology that provides automatic IPv6 address assignment
when IPv4/IPv6 hosts are located behind IPv4 network address translation
(NAT) devices. It accomplishes this by embedding the IPv6 packets inside
IPv4 UDP packets. The threat actor gains a foothold in the IPv4 network. The
compromised host sends rogue router advertisements (RAs), which triggers
dual stacked hosts to obtain an IPv6 address. The threat actor can then use
this foothold to move around, or pivot, inside the network. The threat actor
can compromise additional hosts before sending traffic back out of the
network, as shown in the figure.

Sample IPv6 Exploit

> Threat actor traffic gains foothold via IPv4, sends rogue IPv6 RAs, and
pivots using IPv6 hosts

> Unknown IPv6 hosts autoconfigure their stacks silently by initiating

automatic Teredo tunnels using UDP.
>> IPv4 firewall sees and allows IPv4 UDP traffic.

It is necessary to develop and implement a strategy to mitigate attacks

against IPv6 infrastructures and protocols. This mitigation strategy should
include filtering at the edge using various techniques, such as IPv6 ACLs.
4.7.2 IPv6 ACL Syntax
The ACL functionality in IPv6 is similar to ACLs in IPv4. However, there is no
equivalent to IPv4 standard ACLs. In addition, all IPv6 ACLs must be
configured with a name. IPv6 ACLs allow filtering based on source and
destination addresses that are traveling inbound and outbound to a specific
interface. They also support traffic filtering based on IPv6 option headers and
optional, upper-layer protocol type information for finer granularity of control,
similar to extended ACLs in IPv4. To configure an IPv6 ACL, use the ipv6
access-list command to enter into IPv6 ACL configuration mode. Next, use
the syntax shown in the figure to configure each access list entry to
specifically permit or deny traffic. The syntax shown is a simplified version of
the IPv6 ACE syntax. There are additional options. It should be clear from the
provided syntax that IPv6 ACLs are considerably more flexible than IPv4
ACLs.

Apply an IPv6 ACL to an interface with the ipv6 traffic-filter command.

Router(config)# ipv6 access-list access-list-name

Router(config-ipv6-acl)# deny | permit 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]] [ dscp value ] [ fragments] [log] (log-input)
[ sequence value ] [ time-range name ]

Parameter Description
deny | permit Specifies whether to deny or permit
the packet.
Protocol Enter the name or number of an
Internet protocol, or an integer
representing an IPv6 protocol
number.
source-ipv6-prefix / The source or destination IPv6
prefix-Length network or class of networks for
destination-ipv6-address / prefix- which to set deny or permit
Length conditions.
Any Enter any as an abbreviation for the
IPv6 prefix::/0. This matches all
addresses..
host For host source-ipv6-address or
destination-ipv6-address, enter the
source or destination IPv6 host
address for which to set deny or
permit conditions.
Operator (Optional) An operand that
 compares the source or destination
ports of the specified protocol.
Operands are It (less than), gt
(greater than), eq (equal), neq (not
equal), and range.
port-number (Optional) A decimal number or the
name of a TCP or UDP port for
filtering TCP or UDP, respectively.
Dscp (Optional) Matches a differentiated
services codepoint value against the
traffic class value in the Traffic Class
field of each IPv6 packet header. The
acceptable range is from 0 to 63.
Fragments (Optional) Matches non-initial
fragmented packets where the
fragment extension header contains
a non-zero fragment offset. The
fragments keyword is an option only
if the operator [port-number]
arguments are not specified. When
this keyword is used, it also matches
when the first fragment does not
have Layer 4 information.
Log (Optional) Causes an informational
logging message about the packet
that matches the entry to be sent to
the console. (The level of messages
logged to the console is controlled
by the logging console command.)
Log input Optional) Provides the same function
as the log keyword, except that the
logging message also includes the
input interface.
sequence value Optional) Specifies the sequence
number value for the access list
statement. The acceptable range is
from 1 to 4294967295..
time-range name (Optional) Specifies the time range
that applies to the permit
statement. The name of the time
range and its restrictions are
specified by the time-range and
absolute or periodic commands,
respectively.
4.7.3 Configure IPv6 ACLs

An IPv6 ACL contains an implicit deny ipv6 any any. Each IPv6 ACL also
contains implicit permit rules to enable IPv6 neighbor discovery. The IPv6
Neighbor Discovery Protocol (NDP) requires the use of the IPv6 network layer
to send neighbor advertisements (NAs) and neighbor solicitations (NSs). If an
administrator configures the deny ipv6 any any command without
explicitly permitting neighbor discovery, then the NDP will be disabled.

In the figure, R1 is permitting inbound traffic on G0/0 from the

2001:DB8:1:1::/64 network. NA and NS packets are explicitly permitted.
Traffic sourced from any other IPv6 address is explicitly denied. If the
administrator only configured the first permit statement, the ACL would have
the same effect. However, it is a good practice to document the implicit
statements by explicitly configuring them.

R1(config)# ipv6 access-list LAN_ONLY

R1(config-ipv6-acl)# permit 2001:db8:1:1::/64 any
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
R1(config-ipv6-acl)# end
R1# show ipv6 access-list
IPv6 access list LAN_ONLY
permit ipv6 2001:DB8:1:1::/64 any sequence 10
permit icmp any any nd-na sequence 20
permit icmp any any nd-ns sequence 30
deny ipv6 any any sequence 40
R1#