IPv6 deployment comes with its own set of challenges, and security issues have been discussed at length recently. In February, Arbor Networks reported that a significant milestone had been reached in the “arms races between attackers and defenders”, arguing that DDoS attacks will gradually increase over time as IPv6 is more widely deployed.
Most security incidents are caused by human error, either as the result of a programming error or through misconfiguration. In this sense, IPv6 is no different to IPv4. The real concern is the lack of experience and training for those IT professionals dealing with IPv6, which makes these mistakes more likely.
From a technical perspective, most security breaches take place at the application level. Again, this fact means there is little difference between IPv4 and IPv6 in terms of security. So, it’s more a matter of adopting, testing and verifying procedures.
From IPv4 to IPv6: New technology
From IPv4 to IPv6: Dual stack
From IPv4 to IPv6: Real IPv6-related issues
Getting more information
Although IPv6 has been in use for many years, it has been deployed on relatively few networks. This state of affairs has two implications: first, people are less familiar with it and are therefore less likely to spot mistakes. This weakness can be easily addressed through training and gaining experience by running pilot IPv6 projects.
The second issue relates to bugs and design flaws found in new technology, which may only surface when you start to use IPv6. For example, filters or firewalls could become overwhelmed and fail when used in an IPv6 environment, allowing data traffic to pass without full inspection or resulting in an outage.
Issues such as these can be avoided as much as possible by testing conditions in a lab or by running pilots, with the rider that not everything can be replicated in a lab environment. The real challenge comes with scaling.
Most networks need to be dual-stacked. As IPv4 and IPv6 cannot communicate with each other, they will need to be deployed untilthe transition phase is complete, which could take many years. So, for the period during which you offer both IPv4 and IPv6, you have to do everything twice, including security.
In most cases, settings will not be automatically copied between IPv4 and IPv6, so whenever you make a change for one protocol you have to do it for the other, which doubles the chances of making a mistake.
Applications may also switch on IPv6 unintentionally, without it being clear to the operator. For example, while enabling web server software for IPv6, the management package in the background might also run IPv6 and enable itself. Planning is needed to ensure that either the firewall filters are in place or that the software is configured to behave correctly.
Transition techniques themselves may also become a problem. Tunnel set-ups where one protocol sits within another can “hide” content from firewalls that mistake it for regular traffic. Again, tests should be performed to ensure that everything operates correctly.
The third area of concern relates to design decisions made several years ago. IPv6 was designed in a different era when the internet was still a scientific playground and largely based on trust. At the same time, hardware capabilities were far less advanced than they are today and it was unimaginable that somebody would have the resources to exploit certain technologies.
For example, the idea used to be that the sheer size of the IPv6 address pool meant techniques such as port scanning would be almost impossible. As processor capacity and network speeds increased over time, such techniques have now moved within into the reach of the average user, and size alone no longer offers protection against this. Practices and technologies now have to be adopted to mitigate these issues.
There is very little difference in the way you secure IPv6 compared with IPv4, because the environment in which both protocols sit is the same. Mitigation against these issues comes down to training and testing.
However, the impact of human error is unavoidable, and many of the real-world IPv6 lessons will come from trial and error. To lessen the impact, it is key for the technical community to document and share best practices and experiences to limit any widespread security issues from arising.
For many years, the RIPE NCC has worked with the internet industry and technical communities to spread the message of IPv6 deployment best practice. There are several forums, such as ENOG, MENOG and RIPE, which enable the technical community to exchange their IPv6 experiences and document current best practice.
Training and education are paramount and through its APNIC, MENOG, and RIPE NCC IPv6 roadshows for government and enterprise network operators, and its IPv6 training course, the RIPE NCC is continuing to drive home the message that IPv6 deployment cannot wait. The time to deploy is now.
For more information about IPv6 deployment and IPv4 exhaustion, please see: www.IPv6ActNow.org
Axel Pawlik is managing director of the RIPE NCC, an independent not-for-profit organisation that supports the infrastructure of the internet for Europe, the Middle East and parts of central Asia. While at the University of Dortmund, Pawlik contributed to the establishment of Unix networking as a publicly available service in Germany. He also founded EUnet Deutschland GmbH, developing it into one of the strongest EUnet networks in Europe.