Five years ago (July 2017), the Internet Engineering Task Force (IETF) declared the ‘new’ Internet Protocol IPv6 in RFC 8200 as an Internet standard. But the story stretches back much further.
The draft standard of IPv6 (RFC 2460) dates back to 1998. Its main motivation: To solve the problem of limited IPv4 address space. The approximate 4 billion IPv4 addresses stood no chance of coping with the rapid increase in the number of Internet-capable devices, something that was already foreseeable at that time.
Today, almost a quarter of a century later, the migration to IPv6 is far from complete, as large parts of the Internet still run on IPv4, and the problem of insufficient address space still hasn’t been rectified. Network Address Translation (NAT), initially conceived as a temporary workaround, has provided some relief to the latter of these issues, by enabling an IP address to be divided among many devices. It works well, as long as you only use these devices to surf the net. Problems arise, however, when it comes to decentralized communication between devices, something that is quite common in the Internet of Things (IoT) in a ‘digitalized’ world.
Read: The trouble with NAT
In a ‘NAT-based’ IPv4 network, complex workarounds must be created to meet these requirements. Digitalization applications need to be designed around the existing restrictions, instead of being based on a modern end-to-end-capable network.
In the corporate network, IPv6 is often unmanaged
According to Google, around 40% of Internet users have IPv6 connectivity. Five years ago, this figure stood at 17%. Many IT managers are still clinging to IPv4 and are willing to pay around USD 50 per IP address (USD 15, five years ago) for additional addresses given that Regional Internet Registries (RIRs) have exhausted their allocations. There are various reasons for this, including the perceived security benefits of IPv4 compared to IPv6.
Many people assume that there is no need to worry about security in IPv6. That’s the wrong conclusion to draw for many reasons.
Because many organizations are running IPv6 in their networks, latent and unmanaged, they are vulnerable to attacks. Operating systems have long been equipped with IPv6 and can be activated externally via auto-configuration (SLAAC). Devices without IPv6 connectivity in the network can establish this themselves via tunnel mechanisms and potentially bypass firewalls and security monitoring to exfiltrate data or establish back-door access to company networks.
Read: How IoT devices can endanger your IPv6 privacy
Consciously or unconsciously, new services may be provided via both protocols such as in the cloud, but without having the same security features installed for both. For example, access control lists and blocklists that have been properly maintained for IPv4 may potentially be bypassed via IPv6. In some cases, security features are only installed for IPv4. Distributed Denial-of-Service (DDoS) protection is one example.
Further, scanning one’s resources only takes place via IPv4, and vulnerabilities via IPv6 are often overlooked. For example, the Shadowserver Foundation recently found 1.4 million open SQL servers via IPv6.
Below are three comprehensive and freely available sources on IPv6 security:
- NIST: Guidelines for the Secure Deployment of IPv6
- RFC 9099: Operational Security Considerations for IPv6 Networks
- FIRST Education: IPv6 Security Training Material
An IPv4 mindset is risky in the long run
These examples highlight the challenges of a multi-protocol environment. An IPv4 mindset from the past will only make things worse going forward.
With the steady rise in IPv6 users, current and future digitalization requirements and imminent security problems on the horizon, companies will be increasingly exposed to risks if they continue to ignore IPv6. Instead, I recommend:
1. Establishing the topic properly within your organization
Deploying IPv6 requires the input of your whole IT department, not just those who look after your network, to ensure future-oriented, secure, and efficient IT management. A good idea is to appoint an ‘IPv6 officer’, someone with an overview of IPv6 aspects within all IT projects, regardless of whether we are talking about a new data centre, cloud provider, SOC outsourcing, firewall project, or tool requirements.
2. Developing knowledge and expertise
Which individuals require which level of IPv6 knowledge within your organization? There’s no simple answer. Training plans are useful, but you only really learn the ropes during manageable implementation projects. It’s also a good idea to network with others and compare notes. Get active!
3. Performing security gap analysis
You should actively analyse potential attack targets in your network and work to mitigate these vulnerabilities.
4. Defining requirements for new products and projects
Use the life cycle of new applications and products to make these IPv6-ready. Otherwise, you will be importing new legacy issues, which will then accompany you over the years and only get worse over time, making business operations much more expensive.
5. Getting the support of management
All the above points need support from management. Here, it is vital to create understanding (see point 1) by sitting down together with all the stakeholders to make firm and fundamental decisions. These can then create the basis for all detailed decisions, for example, in the form of a company policy.
Frank Herberg has been working for SWITCH since 2012.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.