Some recent Network World articles have been written about the fact that organizations have IPv6 traffic on them even though they have not explicitly enabled IPv6 on their hosts or network devices. I don't want you to overreact to this news or to unnecessarily spread fear-uncertainty-and-doubt about IPv6. As far as the protocol goes, it is not drastically different than IPv4. There are steps you can take to protect your organization while preparing for your migration to IPv6.
If you got your print copy of Network World July 6-13, Volume 26, Number 23 you would see an article on the front cover titled "Hidden IPv6 traffic poses risk" by Carolyn Duffy Marsan. If you read the online version of Network World you might have read the same article titled "Invisible IPv6 traffic poses serious network threat" also by Carolyn Duffy Marsan. Carolyn also wrote another Network World online article titled "Five of the biggest IPv6-based threats facing CIOs".
These articles cover the fact that many organizations have some form of IPv6 traffic on their network and they do not even realize it. Because many modern operating systems come with IPv6 enabled by default and configured to be the preferred protocol these computers may be able to communicate using IPv6 even when on an IPv4-only network. The tunneling transition mechanisms 6to4, Teredo, and ISATAP may permit an IPv4-only host to gain access to other IPv6-capable systems when the user is on an IPv4-only access network. Therefore, if a DNS response contains an IPv6 AAAA resource record an IPv6-capable host will try to establish a connection to that IPv6 host. If the user does not have native IPv6 connectivity then their computer may try to tunnel the IPv6 packets inside an IPv4 packet, depending on the operating system and host settings.
The issue of network administrator's lack of understanding of the traffic traversing their networks is not new. For decades network administrators have been so busy that they don't typically have time to dig deep into the data traffic on their networks. The fact that the network works at all is a blessing. A simple ping is used to test and then it is off to the next fire-drill. This IPv6 traffic tunneled in other types of IPv4 packets is also not easily detected. As mentioned in the article, the IPv6 packets could be tunneled inside IPv4 protocol 41, IPv4/UDP port 3544, or even inside higher layer protocols. Many firewalls and IPSs do not look at the tunneled IPv6 traffic. Therefore, the perimeter is ill-equipped to spot these outbound connections. Therefore, we have to give the network administrators credit in the fact that these IPv6 packets are not easily identifiable. Most network management tools have far more IPv4 features that their manufacturers haven't developed the required IPv6 monitoring functions.
Don't be alarmed but rather understand the traffic that is traversing your networks. You simply need to perform some packet captures and be more attentive to traffic entering and exiting your perimeter. Before you run off and start blocking all tunneled IPv6 traffic you should know how the current tunneled IPv6 traffic fits into your IPv6 migration strategy. If you disable it today there is a good chance that you will need to remove those filters when you decide to formalize your transition to IPv6.
You may also not need to fear rogue IPv6 devices on your network. Many computer operating systems have both IPv4 and IPv6 protocol stacks enabled by default. However, most network devices need to have IPv6 explicitly configured. You should start to worry if you find that someone has enabled IPv6 on your network devices without your knowledge or if an end-user computer is sending ICMPv6 Router Advertisement (RA) messages as it if was a router.
Several years ago there was a lot of emphasis on IPv6's Type 0 routing header (RH0). RH0 has been deprecated since RFC 5095 was standardized in December of 2007. Older network devices that forward RH0 packets by default and end-nodes that process RH0 packets simply need to have this feature disabled with filtering or in software. Any newer device will not forward or process these packets and configuration settings exist to completely disable processing and forwarding of packets containing RH0. You do not need to be concerned with this unless you are deploying IPv6 today.
There is also no need to be afraid of the ICMPv6 protocol or the fact that IPv6 makes extensive use of multicast. While these improvements in IPv6 allow for autoconfiguration, neighbor discovery, Path MTU Discovery (PMTUD), fragmentation, and efficient packet forwarding, they are not evil. Rather it is how these protocols could be used by an attacker that causes concern.
I suggest that you use a protocol analyzer and see if you can find any of this traffic on your network. Pay particular attention at the perimeter of your network. Look just inside your firewall and right on the outside of your firewall. What you find may be enlightening. I would encourage you to learn more about IPv6 and the unique characteristics of the protocol that are different than the version of IP you are most familiar with. There are methods to secure your networks from these IPv6-specific threats. Most of them are detailed in our book on IPv6 Security. Through your understanding of the protocol you will know how to put the threats into perspective. With education of IPv6 comes the ability to create an effective strategy to help mitigate the IPv6 security vulnerabilities.
Scott