The capabilities IPv6 provides will enhance online security, but the shift to the new Internet address scheme may also present risks if not properly managed. Previously, Internet security was largely an after-thought for the early Internet, as its primary purpose was to facilitate open, end-to-end, any-to-any communications and information exchange for bridging and accelerating research efforts. Today, we have a much more complex online ecosystem that spans billions of users across the globe and serves not only as an engine for e-commerce, but as an engine for all commerce.

The Internet protocol suite has become the de facto standard for global Internet services and consumers, but it also serves as a near ubiquitous substrate for running critical network infrastructure and business critical applications. Transportation, financial systems, emergency services, utilities, and government applications are just a few examples of services that need absolute availability and robust security. But having robust security is only one part of the solution.

At the micro level, the migration of personally identifiable information and proprietary intellectual property online has influenced IPv6 protocol architects to bake additional security into the stack. For example, IPSec is mandatory to implement in IPv6 compliant protocol stacks, while secure neighbour discovery capabilities, privacy addresses, and unique local addresses (ULA) all provide additional security enhancements.

While these additional security measures are good for end users, they can present some real challenges for network administraators. For example, one of the biggest—but arguably easiest-to-remedy—pitfalls is that today most networking equipment and end systems are shipped with IPv6 enabled by default. This is ideal to foster IPv6 deployment, but puts the onus on network administrators to have a plan in place to proactively manage IPv6, as leaving IPv6 turned on by default can create security holes if not properly managed.

In an Internet environment with no bad actors it is perfectly reasonable and even requisite to enable IPv6 by default in order to rapidly deploy. However, if network managers aren’t ready for IPv6 in their operating environments, meaning full functional parity from a security and operational perspective, then they really need to disable IPv6 entirely and deploy new devices and hardware in a very calculated manner.

With IPv6 usage on the rise, it is critical that networks, equipment, and systems are implemented appropriately to help securely enable its full potential and prevent the creation of inadvertent security issues. Some such issues that have been observed include IPv6 being used to compromise systems “under the radar” of IPv4-only sensors and IPv6 being expressly enabled by miscreants in order to exfiltrate data, facilitate malware propagation, and enable botnet C&C infrastructure and distributed denial of service attacks.

Other considerations for securely implementing IPv6 include the following:

Translating IPv4 to IPv6 (because it will take some time before all systems are running on v6, and some may never run IPv6) itself can be a pitfall. This is because IPv4 and IPv6 are not “bits on the wire” compatible; translating traffic from IPv4 to IPv6 will inevitably result in middle boxes mediating transactions as packets move through the network. Like a mail sorter at a post office transfer facility, transferring payloads from IPv4 to IPv6 packets creates an opportunity for a poor implementation or a bad actor to exploit a potential vulnerability.

Unlike IPv4’s variable header size, IPv6 has a 40-byte fixed header, but introduces add-on “extension headers” that may be chained and require complex processing by various systems that handle the packet. These chains could overwhelm firewalls and security gateways. They could even introduce router forwarding performance degradation and be a potential vector for distributed denial of service and other attacks.

During a long period of “transitional coexistence,” IPv6 adoption may require large network address translation protocol translation (NAT-PT) devices, end system or intermediate translation devices and protocols. But these devices complicate the network and could break useful functions like geo-location or tools that security administrators use to identify and mitigate malicious network behaviours, including blacklists (e.g., spam and phishing) and traffic filters.

Because of IPv6’s sparse address space, active scanning of infrastructure for unauthorized or vulnerable systems is much more complex than with IPv4. These capabilities need to be augmented with network access controls and active measurement systems that trigger vulnerability scanning.

Have any other considerations to share in the comments section below?