Securing IPv6

April 7, 2011 - 2 Comments

In the previous installment of our series of IPv6 security posts, we covered some of the ways addressing has changed in IPv6 compared to IPv4. In this post, we’ll talk about some of the things to consider when securing IPv6 compared to IPv4. Before digging into this topic, however, it is important to remember that while IPv6 may have different security concerns than IPv4, it is not necessarily any more secure than IPv4. Furthermore, the post will focus on those aspects that are different or unique to IPv6, since many of the common best practices for IPv4 networks also apply to IPv6 networks.

Dual Stack Concerns

First off, to support the transition from IPv4 to IPv6, many systems support both IPv4 and IPv6 traffic simultaneously, in what is known as a dual stack configuration. The important thing to understand about this configuration is that IPv6 and IPv4 utilize different stacks. This means that if you have Access Control Lists (ACLs) configured for IPv4 traffic, they will not stop IPv6 traffic (since a different stack is processing the IPv6 traffic). This can be a big problem on devices, such as PCs, which have IPv6 enabled by default (since users may not even think about deploying IPv6 ACLs because they are not using IPv6). Since IPv6 supports automated neighbor discovery and address creation, interfaces can automatically generate both local and global IPv6 addresses without any user interaction. Furthermore, even if the local network does not support IPv6 traffic, an attacker can get IPv6 traffic to your host through other mechanisms. For instance, it is possible to send IPv6 traffic to a system over an IPv4 SSH connection that supports port forwarding. Therefore, it is vital to deploy appropriate IPv6 firewall rules on your internal systems.

Deploying ACLs

Using IOS ACLs has also changed slightly in IPv6. Similar to the dual stack environment, traditional IOS ACLs only apply to IPv4 traffic. So to limit which IPv6 traffic can access your network you must deploy ACLs specific to IPv6 (using the ipv6 keyword). When deploying ACLs in IPv6, however, there are some subtleties to think about. For instance, all IPv4 IOS ACLs have an implicit “deny ip any any” at the end of the ACL. With IPv6, the IOS ACLs have the following 2 implicit permit statements along with a deny statement, as shown below:

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

The permit statements are added so that Neighbor Discovery (which performs the equivalent functionality of ARP in IPv4) does not break when you apply an ACL to an interface. This can lead to problems if you like to use the log option in your ACLs, such as “deny ipv6 any any log“, because now that statement will override the implicit permits, and neighbor discovery traffic will be denied. So use the log option with care.

Transport Protocol Filtering

In IPv4, people use extended ACLs to filter a large amount of TCP and UDP traffic based on source and destination ports. You can perform this same filtering in IPv6 as well, although it is more complicated for your filtering device to locate the transport protocol in IPv6 traffic. With IPv4, it is trivial to identify the transport protocol. With IPv6, locating the transport protocol is more complicated because you must traverse the extension header chain looking for the transport (which usually comes at the very end of the extension header chain). With fragmentation, it is possible for the first fragment to not even include the transport protocol. This facilitated new filtering keywords, such as undetermined-transport, which indicates that either the transport protocol can not be identified in the packet or the packet contains an undefined extension header. It also varies the way in which the fragment keyword is interpreted depending on the location of the transport protocol header.

Filtering Extension Headers

In IPv4, the main concern was usually limiting traffic based on IP protocols (such as UDP and TCP). Limiting traffic based on IP protocols is important with IPv6, but now you also have to be concerned with filtering extension headers as well. For instance, one extension header that you should definitely deny is the Routing Header (RH) Type 0, since this is essentially the same as source routing in IPv4. Fortunately, the RH Type 0 extension header was deprecated by RFC 5095 so it should not be allowed by default on many devices (this has been the default for IOS beginning with 12.4(15)T). You may also want to deny RH Type 2 traffic, which is related to mobility, depending on the requirements of your network.

Filtering Tunneling

Besides dual stacks, various tunneling techniques have been developed to allow IPv4 and IPv6 networks to communicate with each other during the transition period. These tunnels can provide traffic paths that are not monitored or filtered by your current IPv4 security policy. Without proper filtering, users may configure these tunnels to bridge the IPv4 and IPv6 networks. Some tunnels can even be configured automatically without user interaction.This could allow traffic that is denied by your IPv4 security policy to bypass those restrictions. For instance, a teredo tunnel enables a user to encapsulate an IPv6 packet inside of a standard IPv4 UDP packet. Through that tunnel a user or attacker could establish connections that would be otherwise blocked by the existing IPv4 security restrictions.

ICMP Concerns

With IPv4, ICMP messages from other networks did not usually play a large role in the operation of your network. In many situations, you could block ICMP traffic at your perimeter (which is quite common). With the increased role of ICMP in IPv6, simply blocking all ICMP is no longer an option (as exhibited by the IOS ACLs that now have implicit permit statements). For instance, unless you allow ICMP type 2 (Packet Too Big) messages into your network, you break fragmentation. You also have to decide if you are going to allow neighbor discovery to operate at your perimeter since it also utilizes ICMP traffic. In fact, RFC 4890 – Recommendations for Filtering ICMPv6 Messages in Firewalls is solely devoted to explaining the various things you need to consider when implementing rules to limit ICMP traffic into your IPv6 network.

Elimination of NAT

With IPv4, most home firewalls implement a default configuration, which performs dynamic NAT to allow multiple internal systems to appear to be a single IP address to the external world. By default, this configuration usually only allows outbound connections from your internal network while denying any connections initiated from the Internet to your internal systems. This default configuration provides security to home networks by limiting inbound traffic, while still allowing your computers to easily access the Internet. With IPv6, however, addresses are not as limited so NAT is no longer needed. The downside to this is that the default setup for home IPv6 firewalls is likely to be much more open, to guarantee that your internal devices can access the Internet. From a security perspective, in many situations this may be similar to plugging you computer directly into your cable modem. Therefore, you must make sure that you apply ACLs to limit access into your IPv6 home network.

This has been a quick look at some of the things to consider when securing your IPv6 network (definitely nothing close to a comprehensive guide to securing your IPv6 network). Hopefully, this overview has encouraged you to start seeking out IPv6 best practice guides as they continue to evolve, so that even before you deploy IPv6 on your network you understand the risks, since many of the features of IPv6 essentially operate automatically (such as address creation and some tunnel creation). Then when you deploy IPv6 on your network, you will be able to successfully harden the network so that it is no more insecure than your current IPv4 network. Also, keep an eye out for the next post in this series where we’ll be talking about things to consider when performing security testing on IPv6 devices.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. I am a student of Networking. It’s really nice information for me. IPv6 is pretty tuff for me. Because I didn’t get opportunity to use it. Thanks for share.

  2. Very good information…many thanks