Answers: IPv6 Extended ACLs 1

By Chris October 7, 2016 09:10

This latest lab breaks the config lab mold just a tad, but for a good reason. It looks like a straightforward config lab, requiring just 10 minutes or so to do on paper. But it sets you up for one of the most common mistakes with IPv6 ACLs. Do the lab for yourself to see if the extra unstated bit of work is trigger in your brain, and then check here when you’re done.


Figure 1: Two Router ROAS Topology for IPv6 ACL Lab


Example 5: R1 Config



This lab asked you to create extended IPv6 ACLs. The difference between IPv6 standard and extended ACLs is subtle in that the configuration commands do not give any obvious clues about whether the ACL is standard or extended. If the ACL matches only the source and destination IPv6 address fields, it is a standard IPv6 ACL; otherwise, it is an extended IPv6 ACL.

Next, the lab gave two requirements for permitting traffic, but based on the topology, some of those packets enter R1’s G0/2.1 subinterface only, with the other traffic entering R1’s G0/2.2 subinterface. As a result, you could match the first permit requirement in a different ACL, enabled inbound on R1’s G0/2.1 subinterface, and match the second permit requirement in a second ACL, enabled inbound on R1’s G0/2.2 subinterface. The solution does just that. The ACLs use the following action for those permit requirements:

ACL ExtACL01-sub1: two permit statements, one for Telnet and one for SSH as the source TCP port.

ACL ExtACL01-sub2: one permit statements for all ICMPv6 messages

The requirements also ask you configure the ACL(s) so that all remaining packets are denied, and those matches are counted, and log messages are issued. Those requirements mean that you must explicitly match the remaining packets with an explicit deny command, with the log option, as shown at the end of the ACL with the deny ipv6 any any log ACL subcommand. And while correct, this command creates the one mistake that can be easily overlooked with IPv6 ACLs: the need to also then permit other types of ICMP messages, like NDP Neighbor Advertisement (NA) and Neighbor Solicitation (NS) messages.

The answers show the matching (with a permit) of four separate ICMPv6 messages that would otherwise be permitted by an inbound IPv6 ACL’s deny ipv6 any any command. In succession, each command permits ICMPv6 neighbor solicitation (NS), neighbor advertisement (NA), router solicitation (RS) and router advertisement (RA). Without these, hosts on the subnets would not discover the existence of the router nor learn the router’s MAC address.

IPv6 Extended ACLs 1
Multilink PPP 2
By Chris October 7, 2016 09:10
Write a comment


  1. Erjol October 8, 12:38

    Should be “traffic-filter” instead, right?

    Reply to this comment
  2. Pshko February 8, 03:36

    We are not allowed to take the exam from Iran
    SSH has no keyword in ACL replace it with 22

    Reply to this comment
  3. Gabriel Moran November 30, 03:24

    I didn’t see where you asked us to explicitly permit the ICMP NA/ND messages. Please advise.

    Reply to this comment
    • certskills January 19, 13:19

      Hi Gabriel,
      I looked, and I didn’t require it. It’s just good practice, because without it, NDP Neighbor Advertisement/Solicitation would fail. but I agree it’s not in the requirements.

      Reply to this comment
      • Dave November 4, 03:05

        Won’t the implicit permit lines at the end of the list cover NDP Neighbor Advertisement/Solicitation?

        Reply to this comment
        • certskills November 27, 10:40

          Hi Dave,
          Sorry for the delay.
          Short version is no. There is no implicit (aka not configured) permit at the end of an IPv4 or IPv6 ACL. Do you instead refer to the explicit (aka configured) permit statements in the example answer? Those do permit NDP NS and NA. Maybe your comment is just one of disagreeing about implicit/explicit?

          Reply to this comment
          • Dave November 27, 19:33

            No worries at all. 🙂 In your book CCNA Routing and Switching ICND2 200-105 Official Cert Guide it talks about the implicit permit rules at the end of IPv6 ACLs.

            “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.”

    • Ani October 12, 21:03

      also curious of this because you did say in your book at these ICMP statements were invisible extras above the implicit deny

      Reply to this comment
  4. Konstantin A April 30, 13:46

    I created the network diagram from the book at chapter 25 where are the examples based.
    Also i decided to activate EIGRPv6 between the routers. After the activation of the second extended ACL inbound at router R2, neighbour relation broke.
    I knew the implicit deny blocked the “Hello”, so i added a permit statement about all multicast.
    I was receiving an error “retry limit exceeded” which after a Google search led me to that the ACK of the “Hello” was being filtered.
    I couldn’t fix it by adding a new ACE since Packet Tracer’s IOS is old (12.1) to allow ACK.
    Isn’t there an easier way for routing protocols, since they don’t rely on TCP/UDP but they have their own protocol type ?

    Reply to this comment
    • certskills May 16, 09:07

      Hi Konstantin,
      Interesting experiment. And yes, there’s an easier way. Just use “eigrp” as the protocol name instead of ip. “access-list 101 permit eigrp any any”. Don’t know if the PT simulator supports it, but real devices have for a long time. It’s too far back in my memory to recall if it was supported in a real 12.1 IOS.

      PS ditto for protocol type “ospf”

      Reply to this comment
      • Jonathan January 13, 08:46


        I see there is a protocol type for eigrp and ospf for IPv4 access list but I do not see same options for IPv6 Access Lists. After an exhaustive search for answers I haven’t come up with a clean way to permit management packets for either routing protocol to communicate through an IPv6 Access Lists.

        What I mean by clean is that I was looking for just 1 permit command that will permit either ospf or eigrp to establish and maintain relationships and topology databases. Basically I was looking for a way to command that would allow the routing protocols to work but at the same time have the flexibility to deny or permit other traffic as necessary.

        Please advise.


        Reply to this comment
  5. Mr. David P. Hummel Jr. June 7, 04:07

    Where can we find a list of all available ICMP message type abbreviations that can be used in an ACL? I know we can use the numbers but its much better for documentation to use things like “nd-na”, “nd-ns”, “router-solicitation”, etc.

    Reply to this comment
    • certskills June 22, 10:23

      Hi David,
      Well, easiest way is to get into config mode, type the command up to that point, and type ?. That’ll reveal all the options.
      There’s always IOS doc. Maybe here, and search for “ICMP message type”. That’s where I found them.


      Reply to this comment
      • Mr. David P. Hummel Jr. June 22, 16:21

        Thank you for pointing me there. I guess checking the help and documentation should have been a first step; I just never saw the online command reference before.

        One thing I don’t like is their suggestion to, “…Refer to the current assigned numbers RFC”. I bet that thing is update more frequently than the iOS I’m running.

        In the end though, IOS changes any port number I might type in to the name ifbit has one. I suppose it’s better to be specific than to hope a name covers what you need.

        Thanks again.

        Reply to this comment
  6. barbara September 21, 09:16

    In access-list ExtACL01-sub10, shouldn’t the port numbers come after the destination addresses since they are destination ports? The source address would be associated with a random port automatically selected by the host opening the Telnet connection.

    Reply to this comment
    • certskills September 25, 09:47

      Hi Barbara,
      The requirements state that the packets are coming from (not going to) the Telnet and SSH servers in the subnets at the top of the figure – so the ACL needs to match the source ports. But I agree, the ACL should match the well known ports, whether they be the source or destination in a particular flow.

      Reply to this comment
  7. Peter September 18, 18:22

    With Packet Tracer (C2900 15.1(4)M4) here’s what I got:

    R1(config-ipv6-acl)#permit tcp host 2001:0:0:10::100 eq 22 2001:0:0:30::/64
    % Incomplete command.

    Reply to this comment
    • certskills September 25, 15:25

      Hi Peter,
      Thanks for letting me know. It looks like a difference between PT and real gear; the command is accepted on a real router. FYI.

      Reply to this comment
View comments

Write a comment

Comment; Identify w/ Social Media or Email


Subscribe to our mailing list and get interesting stuff and updates to your email inbox.

Thank you for subscribing.

Something went wrong.