And the devil is six: the security consequences of the switch to IPv6

Early in 2011, ICANN handed out its last available /8s (IPv4-speak for ‘blocks of 16,777,216 IP addresses’) to the five regional Internet registries (RIRs). One can picture ICANN as the IP address factory and the RIRs as the warehouses distributing them – with the important exception that ICANN can’t simply produce more addresses when it needs to: it is limited by their 32-bit length, which means that, in theory, just over four billion of them are available; in practice there are even fewer than that.

This has not come as a surprise to anyone. Ever since the Internet outgrew its original purpose of a network for computer researchers and defence experts, we have known that the total number of possible IP addresses is significantly smaller than the world’s population – and, in fact, there is a need for many more than one IP address per person.

Even though RIRs and ISPs still had enough IP addresses available for the near future, the message last year was clear: we were running out of IP addresses and we really had to start moving towards a new protocol that allowed for a much larger address space.

Thankfully, since the late 1990s such a new protocol has been available: IPv6 (the ‘standard’ IP protocol, version 4 [1], is commonly and henceforth referred to as IPv4). Unfortunately, for a number of reasons migration to IPv6 has been rather slow, and it will probably continue to be slow for some time to come.

No matter how slowly, though, the migration to IPv6 is happening. And, with new protocols come new security issues and challenges. This article looks at some of these issues and hopes to encourage the security industry to ready itself for IPv6 – and all of the nasty side effects that may come with it.

This is not a warning against migration to IPv6. I believe this migration is a necessary step in order to keep the Internet usable in the future – and one that should probably have been taken some time ago.

This is also not an article that claims to give a complete overview of all the bad things that can happen or that are happening with IPv6. Rather, it points out some of the security issues that may occur with the switch to IPv6. Its purpose is to raise awareness of these issues as well as the many that aren’t covered.

Communication on the Internet uses several hierarchical abstraction layers [2]. At the very bottom is the physical layer (which may in fact be wireless), which is used to transport two different kinds of ‘things’ – commonly referred to as 0s and 1s – between two devices. On top of that is the link layer, which puts these 0s and 1s together in ‘frames’ to allow for a meaningful data exchange.

The internet layer comes next – this is where IPv4 and IPv6 come into play. This layer is used to send packets from one device to another over the Internet, despite there not being a direct connection between the two devices. For this reason, all devices are given an address; it is these addresses that, in the case of IPv4, we’re running out of.

On top of that, the transport layer is used to provide end-to-end communication between applications, with the most commonly used transport layer protocols being TCP and UDP. The former maintains a connection between the two devices and makes sure information spread over multiple packets can be assembled correctly; the latter is used to send small packets where speed is more important than guaranteed delivery and no connection state is maintained. Ports are part of the transport layer.

Finally, on top of the transport layer, there is the application layer, used by actual applications such as HTTP, SMTP, FTP (all of which use TCP) and DNS (which almost always uses UDP). These protocols describe the communication rules for particular applications that use the Internet.

A change in one layer does not usually affect the others: to use IPv6, one can use the same cables that are used for an IPv4 connection. In fact, IPv4 and IPv6 generally make use of the same infrastructure and as long as routers and computers are IPv6-enabled [3], IPv4 and IPv6 can be used together on the same networks. IPv6 doesn’t require changes to upper-layer protocols either: there is no HTTP-for-IPv6 or DNS-for-IPv6 – the protocols themselves are IP-agnostic.

However, in practice it is hard to think of the upper-layer protocols without seeing the IP address as part of them. While in principle, a web server will be able to serve IPv6 requests if the machine is able to make IPv6 connections, in practice without special arrangements for IPv6, at the very least the log files will start to look odd and it is possible that more serious problems will arise [4]. For mail servers (that use SMTP) the problem is much worse, as IP-based (spam)filtering is heavily embedded in most of them.

This is also something to keep in mind when designing a security application that sniffs transport or application layer traffic: such applications are likely to work for IPv6 traffic right away. However, if the application is not aware of IPv6, it is less likely to derive anything meaningful from the sniffing.

IPv6 differs in a number of ways from IPv4. Apart from the four-bit version number (which is 0110 for IPv6), there is more flexibility for using ‘extension headers’, while there is no checksum any more: it is believed that the link layer currently provides sufficient error detection. The most noticeable change, however, is the 128-bit length for IP addresses, compared to 32-bit for IPv4.

Because of the 128 bits, there are 2¹²⁸ possible IPv6 addresses – about 340 undecillion, and 2⁹⁶ times as many as there are IPv4 addresses. For comparison, the amount of spam sent every day is in the order of 2³⁶. For all practical purposes, the number of IPv6 addresses equals infinity.

While IPv4 addresses are commonly written in dot-decimal notation (e.g. 212.58.244.69), the much longer IPv6 addresses are written in hexadecimal notation, with four groups of eight digits, separated by colons – for instance, 2620:0000:1cfe:face:b00c:0000:0000:0003. To simplify notation, leading zeroes can be omitted in each group and two colons can replace one or more consecutive groups of zeros [5], so that the aforementioned address becomes 2620:0:1cfe:face:b00c::3 – indeed this is the IPv6 address used by Facebook.

The x /n notation commonly used for IPv4 blocks is also used in IPv6 to denote the block of IP addresses that are equal to x in all but the first n bits. For instance, the block 2000::/3 consists of those addresses for which the first three bits are 001. In fact, this is the block that is currently allocated for the use of publicly routable addresses. Therefore, in practice one only has to take into account 2¹²⁵ IPv6 addresses – although this is nothing but a smaller version of infinity.

In an ideal world, all ISPs, software vendors and network experts would spend the next few months making sure we were all IPv6-ready, and by the end of the year IPv4 would be added to the list that already includes gopher and ARPANET – useful once, but no longer needed. Unfortunately, the Internet is not an ideal world.

So, while it is important for organizations to become IPv6-connected, for the foreseeable future it will continue to be much more important to remain IPv4-connected. An organization that wants to increase its online presence should therefore ensure it stays IPv4-connected despite the possible lack of availability of IPv4 addresses. There are a number of ways in which an organization can do that and, from a security point of view, they can make the picture slightly more complicated.

The first is to use NAT (Network Address Translation) on a larger scale, commonly known as ‘carrier-grade NAT’ or CGN. NAT allows for multiple devices to be connected to the Internet using a single public IP address: using port-mapping, a router at the gateway makes sure that IPv4 packets received from the Internet are sent to the correct device. NAT is commonly used in households and small offices. In principle, it can be used for larger areas too: for instance, an ISP with a limited number of IPv4 addresses can put groups of customers on a NAT.

There are a number of drawbacks to being on a NAT, the lack of end-to-end connectivity probably being the most important, but for day-to-day Internet usage it generally suffices. However, from the outside world, it is usually not possible to discern from which particular device traffic from the NAT’s IP address was sent. This has important security implications.

Knowledge that a certain IP address has been used in malicious activity – commonly because it is part of a botnet – is useful in the fight against malware. Certain activity, such as sending email [6], can be denied to the IP address until it has been proven to be clean. When the IP address is, in fact, the gateway to a wider area NAT, this means that innocent users will be blocked, despite being unable to influence the activity for which the block is in place.

Similarly, for law enforcement purposes it can be very useful to know which IP address has participated in a certain activity. If the IP address is shared by a large number of users, it will provide little information without further details from the ISP. The additional information that can be provided by the ISP will be dependent on the quality of the ISP’s log files – and keeping logs of ‘good quality’ may see the ISP run into storage issues and may also conflict with privacy laws.

Other than using NAT, a company that is in need of IPv4 addresses may also find them on the ‘second-hand market’. Large chunks of IPv4 addresses (including /8s) were assigned in the 1980s and early 1990s to organizations that were large at the time. Many of these addresses have never been used and have now been given back – or, indeed, are being sold on IPv4 marketplaces.

There is nothing inherently insecure about this practice, yet it is something we ought not to ignore. For instance, a lot of applications depend on determining the geographical location of a certain IP address. As a security measure, geolocation-based restrictions are easily evaded, but they are still in place and it is good to be aware of the fact that, with chunks of IP addresses being sold, geoIP databases are likely to become outdated. Denying an Internet user access to a certain application because their IP’s location doesn’t match their physical one is thus likely to result in many false positives.

As IPv4 blocks are being sold, the global routing table is becoming bigger too. It is not unimaginable that this will lead to routing issues, which could be abused by those with malicious intentions. In one reported case, a block of IP addresses was effectively ‘stolen’ [7]. Again, it is not unimaginable that this will happen more often in the future.

Thankfully, not everyone will cling to IPv4 for as long as possible. But switching to IPv6 might not be as easy as it sounds: doing so depends on both router(s) and provider to be IPv6-ready, and many are not. Thankfully, there are a number of ways to use IPv6 over an IPv4 connection.

In the 6to4 transition mechanism, IPv6 packets are encapsulated inside IPv4 packets [8], allowing IPv6 packets to travel over an IPv4-only connection. The Teredo transition technology (and its Linux equivalent Miredo) works by encapsulating IPv6 packets inside IPv4-UDP packets: it can even be used by devices on a local network behind a NAT.

Both 6to4 and Teredo (as well as 4in6, which allows IPv6-only devices to send and receive IPv4 traffic) are useful protocols and there is nothing inherently wrong with them (certainly not from a security point of view). However, developers of network security applications ought to be aware of their existence and consider them as possibilities when sniffing network traffic. They also mean that using IPv6 is a more easily available option for botnet authors than it may at first seem. (There are many other ways to use IPv6 on an IPv4 network; I have singled these two out because they are probably the easiest to set up, which makes them more attractive for malware authors.)

It is hard to think of current spam filters without thinking of IP-based blacklists, whitelists and reputation systems. IPv4 is, in many ways, ideal for spam filters: a binary list containing a 0 or 1 for each possible IPv4 address is 0.5GB in size and fits on a small USB stick. The number of legitimate mail servers is relatively small and the vast majority of IP addresses should never send direct-to-MX emails [9] (or have a history of sending spam), making it very useful to keep a list of the legitimate senders (an IP whitelist) or, more commonly, those that send spam (an IP blacklist).

Don’t even consider trying to do the same for the 2¹²⁵ publicly routable IPv6 addresses. There will never be enough storage space for these, and there are enough addresses for every single piece of spam to be sent from a different IPv6 address.

The idea of IPv6 address assignment is for end-users and small offices to be assigned at least a /64 block of IPv6 addresses, so you could base a blacklist on the first 64 bits. Now, if indeed the Internet did behave in this ideal way (world peace is far more likely), you would ‘only’ have to consider 2⁶¹ (=2¹²⁵/2⁶⁴) possible IPv6 blocks. This number is still far too large to run a blacklist.

One solution to this problem would be to start by managing a whitelist of IPv6 addresses belonging to outbound mail servers: legitimate mailers, but possibly also spammers. Any email sent from addresses that are not on this whitelist is blocked anyway, and within the whitelist, spammers may be blacklisted or more advanced scanning techniques may be applied. This is the principle behind ipv6whitelist.eu [10], for instance.

Another possibility is to filter based on domains, rather than on IP address; DKIM, which cryptographically links a domain name to an email message, is ideal for this. As its many advocates will happily point out, DKIM is not only IP-agnostic, but it has a number of advantages over IP-based filtering that make it useful for IPv4 already.

It is, for instance, possible to have multiple DKIM signatures attached to a message (if it is sent by company A on behalf of company B). By using subdomains, DKIM also allows organizations to make a distinction between different kinds of emails they send. And organizations are less likely to change domains than they are to change IP addresses. DKIM thus has a lot of potential for IPv4 already; if it is more widely deployed by senders and filters alike, the switch to IPv6 will be a lot more seamless.

However, all of this may not be needed in the foreseeable future. As noted before, the number of mail servers is small – significantly smaller than the number of IPv4 addresses – and for the foreseeable future, despite exhausting the supply of IPv4 addresses, organizations will be able to find one or two IPv4 addresses for their mail servers. It may well be that email is the last part of the Internet to switch to IPv6, and this switch may not happen until the middle of the century or even later.

Indeed, while a number of mail servers and spam filter vendors have proudly announced that they are IPv6-ready, the amount of spam sent over IPv6 is extremely small. Those spam messages that have been sent have, without exception, been sent over IPv6 because this happened to be the default connection between the sender (usually a node on a botnet) and the recipient. There are no known examples of spam sent over IPv6 where the spammer deliberately used that connection.

Finally, it is good to look at one other way in which spammers can make use of IPv6: by including IP-based URLs. Such a URL is written as http://[ 2a00:1450:400c:c01::6a]/ – the square brackets are to distinguish the colons from the ones used to denote the port number – and a number of email programs turn such URLs into clickable links. They may not be recognized as such by spam filters.

As already mentioned, spammers have barely jumped onto the IPv6 bandwagon and the same can be said for malware authors. There is very limited evidence of malware that is either IPv6-aware (one rare example is a Zeus variant that is capable of sniffing IPv6 traffic [11]) or which uses IPv6 to communicate. However, that does not mean that IPv6 doesn’t open up new possibilities for malware authors.

To begin with, IPv6 is new and, while it has been around for quite some time, it hasn’t been used as extensively in the wild as IPv4 has. The protocol – or, more likely, implementations using it – may carry undiscovered vulnerabilities (in fact, it would be a miracle if they didn’t exist [12]). Such vulnerabilities are not always discovered by hackers with a bright white hat and even if they are, slow patching means that there will be ample opportunity for the bad guys to take advantage of them. Of course it is impossible to predict the implications of these yet undiscovered vulnerabilities, but they are likely to be serious. The least the security industry can do is to make sure it has a good understanding of IPv6 and that it is ready to act when needed.

Because it is so new, merely using IPv6 may already mean that malicious traffic is leaving the network undetected, simply because security applications aren’t aware of it. As we have seen, via Teredo, 6to4 and 4in6, IPv6 adds more possibilities to tunnel network traffic. By combining various kinds of tunnelling, a similar situation may occur as seen in the obfuscation of malicious files: it’s easy to detect if you know what is happening, but if you don’t, it might be hard to figure out what’s really going on.

We mentioned before how the increase in the use of CGNs to overcome the lack of available IPv4 addresses has security implications. However, so does doing away with NAT – which is exactly what IPv6 does.

This means that every IPv6-connected device is publicly routable and not protected by the implicit firewall present on a NAT. Any IPv6-connected device that is controlled by cybercriminals (for instance, because it is part of a botnet), and which is not protected by a properly configured firewall, can thus be used as a DNS server, a web server, a command-and-control server, etc. The fact that such devices automatically have end-to-end connectivity also makes the running of a peer-to-peer botnet a lot easier.

At the moment, it may not seem likely that this will happen. After all, the percentage of devices with IPv6 connectivity (those where the device has it enabled and the router and ISP support it) is small and the increase in ‘quality’ for such an IPv6 botnet is unlikely to weigh up against the significant decrease in quantity. However, we have seen how protocols such as Teredo/Miredo and 6to4 easily give IPv4-connected devices an IPv6 connection. It is not hard to imagine an advanced piece of malware doing exactly this.

We have seen above how the sheer size of the IPv6 address space has serious implications for spam filtering. It has consequences for malware and network filtering too.

Currently, most households and small offices use a /24 (e.g. 192.168.0.0/24) as a LAN, which gives (almost) 256 possible IPv4 addresses. Some organizations may use larger LANs or have been assigned a larger IPv4 block, but even on a /16 there are slightly less than 65,536 possible addresses. It is not difficult to run a script that checks them all.

In IPv6, most ISPs won’t assign blocks smaller than a /64. There are over 18 quintillion (18,446,744,073,709,551,616 to be precise) possible addresses in such a block. It is impossible to check them all once, let alone regularly. IPv6 addresses for hosts on a network are assigned based on both the network’s IP block and, by default, the 48-bit MAC address of the device, but the MAC address does not necessarily have to be used and there is quite a bit of freedom here.

In fact, this freedom allows for devices to encode small amounts of information inside their IPv6 addresses. For some advanced pieces of malware it would be an interesting way to hide information in plain sight.

We have seen that the Internet is nowhere near as ready for IPv6 as it should be. Thankfully, at the moment it looks like this is the case for cybercriminals as well. As with every new protocol, IPv6 opens new possibilities for them: some can easily be identified, but many others are yet to be discovered. It is the security industry’s task to protect Internet users against the former and to continue to look for the latter – and to respond quickly as new potential threats appear.

IPv6 is both necessary and exciting. Let’s make sure it continues to be in the future.

Several people have been kind enough to answer my questions and to make suggestions for writing this article. I would like to thank Ben April (Trend Micro), Dreas van Donselaar (SpamExperts, ipv6whitelist.eu), Gunter Ollmann (Damballa), Wout de Natris (De Natris Consult), Ken Simpson (Mailchannels), Joe St Sauver (University of Oregon), Morton Swimmer (Trend Micro, Virus Bulletin) and Eric Vyncke (Cisco).