Home / Blogs

IPv6 Security Myth #1: I’m Not Running IPv6 so I Don’t Have to Worry

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.

By Chris Grundemann, Creative|Technologist

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC


Sponsored byVerisign

New TLDs

Sponsored byRadix


Sponsored byDNIB.com

Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign