Now that IPv6 is being actively deployed around the world, security is more and more a growing concern. Unfortunately, there are still a large number of myths that plague the IPv6 security world. These are things that people state as fact but simply aren’t true.

While traveling the world, talking to the people who’ve already deployed IPv6, I’ve identified what I believe are the ten most common IPv6 security myths. This is the first post in a ten (10) part series that will debunk them each in turn and provide a quick introduction to IPv6 security along the way. Ten parts!?! Don’t worry! That’s how we keep each one short and to the point! =)

Myth: I’m Not Running IPv6 so I Don’t Have to Worry
Reality: Your Devices are Using IPv6

Systems running Linux, BSD, Mac OS X, and newer versions of Microsoft Windows, iOS, and Android all come with IPv6 support built in. Often, IPv6 is enabled by default. In many cases IPv6 is preferred over IPv4. Meaning that communication is always attempted on IPv6 first and then the device falls back to IPv4 only if IPv6 communication fails.

This means that even in a network where no one has intentionally deployed IPv6, it is quite likely that devices are sending IPv6 packets and have IPv6 sockets open. This, in turn, means that a potentially major security flaw exists on all of those devices. Someone, maybe you, has probably spent time installing, deploying, and tuning firewalls on your network. If they are all focused on IPv4 only, you’ve just allowed a major back door to exist within your network!

The fact is that devices on your network are most likely already using IPv6 and need to be protected, now.

Myth: I’m Not Running IPv6 so I Don’t Have to Worry
Reality: Your Users are Using IPv6

In addition to having IPv6 support enabled by default, several major operating system versions also include support for IPv6 “auto-tunneling.” The most common automatic (also called dynamic) tunneling mechanisms are 6in4 and Teredo. In both cases the device automatically creates an IPv6-in-IPv4 tunnel across the IPv4 network. The intention was virtuous: Allowing IPv6 communication between IPv6 capable nodes over a legacy IPv4-only network. The practical result is often more nefarious: Allowing IPv6 communication to pass through IPv4 firewalls, even when that communication violates your policy!

Note: While 6in4 and Toredo are the most common automatic tunneling mechanisms, many other tunneling protocols can also allow users or attackers to bypass your network security. 6in4, 6to4, 6in6, ISATAP, Toredo, 6rd, and DS-Lite all need to be taken into consideration.

A final consideration with regard to the “I’m Not Running IPv6 so I Don’t Have to Worry” myth is mobility. When your devices and your users are out on the road, away from the office, what networks are they connecting to? The fact is that it’s very likely they will, at some point, connect to a dual-stack (IPv4 and IPv6) network. In fact, several major wireless operators are now deploying IPv6-centric LTE networks, which means that any smart phone on one of those networks will use IPv6. Now you potentially have a device you thought was protected using an unsecured protocol to communicate on an unknown network…

Of course, the best way to prevent all of this is to intentionally deploy IPv6, and conduct a full security audit as part of the process. It’s no myth that turning on and protecting IPv6 now could save you lots of heartache later.

This post was originally published on the Deploy360 blog; also on the Deploy360 website you can find our IPv6 security page.