Security considerations for IPv6 launch day
by Carl Herberger - VP Security, Radware - Thursday, 24 May 2012.
In case you haven’t been glued to the Internet Society (ISOC) website, there soon will be some rather large changes to the Internet as the much anticipated World IPv6 Launch day arrives on June 6. I see this as much more hype than operationally a change.

While many large organizations have hooked their plans on change over to the ISOC launch date, legions of companies have already been leveraging IPv6 WAN connectivity. Most mobile providers who have adopted LTE 4G infrastructures have built around this networking principle already with mobile devices, by default, connecting to the Internet via IPv6 assignments.

It’s well known, however, that a 4G phone must also be 3G compatible and must also be able to regress to IPv4 published websites as not to upset the end-user community. Thus all we really have done, and much to the chagrin of the initial designers, is somehow weave IPv6 into the existing IPv4 Internet.

Bottom line: Because IPv4 is not going away and many estimate that it will take 10 years (or longer) for the natural death of IPv4 to occur, we will essentially live in perpetuity with both designs.

A new dawn? Or the beginning of the end? To be honest, it’s neither. The interoperability issues between IPv4 and IPv6, however, opens a Pandora’s Box of opportunity for those of the nefarious persuasion. Much has been written about this including from my colleague Ron Meyran who addresses specific IPv6 vulnerabilities that will remain and are likely to be with us indefinitely.

So, what are the three main takeaways from this event?

Take away #1: IPv6 will first be implemented on the WAN, IPv4 will continue to remain in the LAN for years to come

OK, so the ‘big boys’ – Google, Facebook, DNS and CDN providers – are all moving to IPv6 default systems via WAN connectivity. And many, if not most ISP’s are following fast or already there. However, nearly no one has made the transition to IPv6 for LAN. There are many reasons for this, but probably the most notable is that there really is no concept for IPv6 NATing, which would mean that most companies would need to go back to the drawing board for their LAN to transition to IPv6.

Realizing that IPv6 will be adopted at an ever-increasing rate on the Internet WAN operations, and it will be very slow to take hold for LAN operations, that means this will wreak havoc on perimeter security!

If we go back to Ron’s blog post we find out that there really is a huge problem associated with IPv4 and IPv6 cohabitating. The problem is twofold:

Problem #1 – There is no good security detection or mitigation for encapsulated traffic.

Problem #2 – All of yesterday’s exploits, in theory, can be tunneled through the perimeter if someone knows how to properly package the exploit in today’s new transmission transition packaging.

Take away #2: IPv6 & IPv4 don’t cohabitate well

As I mentioned earlier, IPv6 and IPv4 make insecure bedfellows. There have been no predefined standards in the way to handle the facilitation of the cohabitation of IPv4 with IPv6 so there has been shortage of ‘transition mechanisms’ which have popped up and have been, in most part, widely adopted.

Once again, these transition mechanisms facilitate the transitioning of the Internet from its initial IPv4 infrastructure to IPv6. As IPv4 and IPv6 networks are not directly interoperable, these technologies are designed to permit hosts on either network to participate in networking with the opposing network.

The Internet Engineering Task Force (IETF) conducts working groups and discussions through the IETF Internet Drafts and Requests for Comments processes to develop these methods. Some basic IPv6 transition mechanisms have been defined; however nothing has yet emerged as a proposed uniform standard. As such, the world is awash with the mechanisms, which are all over the map but are largely defined in the following categories:


Critical bug found in Cisco ASA products, attackers are scanning for affected devices

Several Cisco ASA products - appliances, firewalls, switches, routers, and security modules - have been found sporting a flaw that can ultimately lead to remote code execution by attackers.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.

Fri, Feb 12th