IPv6 and the Security Implications You Don’t Want to Miss

October 18, 2012 - 2 Comments

In a previous blog, I discussed questions you should ask before peering with your SP and possible configuration options.  Since the Internet edge is where this peering occurs, it should also be the first point where you start to apply your organization’s security policies.  Security is a critical part of IPv6 integration because IPv6 opens up another transport path into your network.

Analysis of Current Capabilities

The first step in dealing with security at the Internet edge is to develop a policy around what can happen at this place in the network.  The Internet edge is the point where your organization offers services to external, Internet users, and it is also the point where internal users access Internet-based services.  With this in mind, it is likely that the policy for IPv6 at your Internet edge will mirror the policy for IPv4.  The services that you allow into and out of your network are not going to change.  They will simply be using an alternative network layer transport protocol, so your security architecture must accommodate this new transport protocol.

As with any place in your network where you are going to implement a new feature, an assessment of current capabilities needs to take place.  Because we are talking security specifics in this case, a thorough analysis of current security features should happen before you implement new features.  Questions such as the following should be addressed:

  • Do all of my IPv4 security features have an IPv6 counterpart?
  • Are there IPv6 security features that are needed that are not there for IPv4?
  • Are IPv6 security features processed in hardware for this platform?
  • What about NAT?

The answers to these questions will help to define how IPv6 will fit into the security architecture.  They will point to possible gaps and where specific attention is needed to cover those gaps.

The last question posed above is one that I constantly come across – “What about NAT for IPv6?”  There are a couple of translation methods that have been defined for IPv6:

  1. NAT64 is used to provide a means of translating between IPv6 only and IPv4 only systems so that they can communicate.  This type of NAT has proven to be very useful in allowing Internet edge connectivity. 
  2. Network Prefix Translation (NPTv6) has also been defined.  It provides a stateless one-to-one mapping of internal and external IPv6 prefixes.  There is a great blog post from Fred Baker that discusses NPTv6 and how it might be used..

Ultimately though, the “What about NAT for IPv6?” question comes down to the stateful 1:n NAT that everyone knows and uses today.  NAT has become so pervasive in today’s network operations that most people have just taken it for granted that NAT will be implemented and stopped asking “Why am I using NAT?”  With the limitation on the number of addresses effectively removed, we need to start asking that question again and get down to the reasons why NAT was implemented in the first place for that point in the network.  Was NAT applied to expand the available address space?  Is NAT being used to “hide” the internal network?  Was NAT used to provide connectivity between overlapping address space?  The answers to these questions will guide the security architecture and design for IPv6 integration.  They will provide a basis for how the security policies should be updated and how to dapply IPv6 features to support that policy.

IPv6 Security Features

IPv6 has many features available that would typically be deployed at the Internet edge.  Features such as Access Control Lists (ACL), unicast Reverse Path Forwarding (uRPF), routing protocol authentication and netflow are all available to support IPv6 security and monitoring.  For routers, the IPv6 features roadmap  can be used to help identify where features are supported.  For other security-specific devices, such as firewalls and intrusion prevention systems, the release notes are a great resource for discovering information about new IPv6 features.  ASA release notes  and IPs  release notes provide a great resource for finding when new features are introduced.

To answer some of the more detailed security features and implementation questions, a great series of IPv6 security blog posts by Earl Carter is available. Another great resource is the Cisco Press book “IPv6 Security” by Eric Vyncke and Scott Hogg, which has guidance on how to deploy IPv6 security into your organization. Also, don’t forget that Cisco professional services can help you with both security assessments and IPv6 transition needs.

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. In order to have IPv6 enabled through whole world there should be services given over just IPv6 so that there will be a demand from clients for IPv6, then there will be more serious incidents.

  2. In fact many of providers around the world are not able to deal with ipV6, the security assessments and IPv6 transition needs to be acelerated..