Internet protocol version 6 (IPv6) is designed to succeed IPv4, the first publicly used protocol that is still in dominant use currently. IPv6 was first ratified as IPng some 14 years ago. Since then, it has had a gradual development and deployment in the Internet and in enterprise level installations, especially government. According to market watchers, the current status is that IPv6 is about to go global with a significant presence within the next three years. What are the implications for security and IT/MIS organizations?
The primary driver for Internet protocol version 6 (IPv6) is the projected exhaustion of IPv4 Class C addresses by the end of 2011. IPv6 features a vastly larger address space than IPv4, resulting from its use of a 128-bit address, whereas IPv4 uses only 32 bits.
The implicit benefit of the larger address space is that it makes "brute-force scanning" by a hacker looking for hosts on a network much harder. In fact, the time required scales from hours to thousands of years!
A secondary driver is the need to improve security in the Internet. IPv6 has native IP security (IPsec), an end-to-end security scheme operating in the Internet layer of the IP suite, built-in as an optional extension. It can be used in protecting data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-to-network), or between a security gateway and a host (network-to-host). It makes sense to deploy this in preference to IPv4, which requires VPN gateways.
Using host-to-host (TRANSPORT) encryption and/or authentication is a major advantage over the same facility in IPv4. This is because IPv4 using TRANSPORT mode is only possible within the same subnet, the problem being that it cannot traverse NAT; TUNNEL mode, on the other hand, can use NAT Traversal. IPv6 specifically does not use NAT because the address space is so large it is unnecessary, indeed, this is why the NAT protocol translation (NAT-PT, see later) standard was withdrawn. Unlike IPv4, IPv6 deploys IPsec using an option header in the IP field, which radically reduces the complexity of implementation.
From this year, you can expect to see academic and government tenders begin to state IPv6 support as a "must," from today's "optional."
The reason for the slow conversion of IPv6 has been a mix of technical issues and cost. There has been no commercial reason for companies to convert to IPv6 unless driven by government policy, or through academic research funding. Hence, in the U.K., the JANET network has been running IPv6 for some years.
The barriers to entry have been reduced by the inclusion of an IPv6 stack in Microsoft Windows by default starting with Vista. All major networking vendors have included support for many years in their routers and switches.
One of the major issues with IPv6 was that it was not designed to be backward compatible with IPv4. This means that to implement it requires a separate network running in parallel with IPv4.
The two approaches are: Run dual-stack protocols on the end devices, and then run separate networks in the cloud. Note that these are separate virtual networks running on the same physical routers. Encapsulate the end device into an IPv4 tunnel, and run that over the Internet or the company's Intranet.
A third approach was to run IPv6-to-IPv4 translation, using a protocol known as NAT-PT RFC 2766, but this has now been deprecated.
As an early-adopter position, companies will use the tunneling technique and test out deployment in their networks. In the Internet, this is more complex, with the necessity to navigate NAT devices. A protocol known as Teredo has been developed for this use, and there are ISPs that can provide it; Microsoft supports this, not as an Internet service but as native support on Vista and Windows 7.
A second proposed option for companies is to use a protocol known as intrasite automatic tunnel-addressing protocol (ISATAP) RFC 4214. As its title suggests, it is designed for use only within a company network. As with Teredo, it has native support on Vista, Windows 7 and Microsoft Server 2008; it is not recommended for use on XP and Server 2003. It works by encapsulating IPv6 packets within IPv4 on the host itself; to communicate over an IPv6 network, an ISATAP router is used which in turn connects to another ISATAP router to a remote IPv4 subnet.
By far, the best technical solution is dual stacking, as it permits the full features of IPv6 to be deployed; security, traffic engineering, end-to-end session monitoring and control. This should be the end-game strategy for any company.
Effects on Hardware and Software Design
Very few low-end devices in the market are capable of being converted to IPv6 with a simple firmware upgrade. As already indicated, most end devices will have to support both IPv4 and IPv6 in dual-stack mode. To get full support of IPv6, it is necessary to run ICMPv6 and DHCPv6 as an absolute minimum. Devices that run dual-stack mode must have sufficient processing capability. Most networks will have the ability to run IPv6, though the main concern will be the DNS, which must have "AAAA" resource records (RR) entries, in addition to the "A" RR for IPv4.
A company deploying IPv6 needs to have staff trained to understand the issues of supporting it with the necessary tools, such as NMS fault finding and monitoring as a bare minimum, change control, IP address allocation, DHCP servers with IPv6, and DNS upgrades to support "AAAA" entries. Most commercial firewalls support IPv6, but a new set of rules will have to be tried and tested.
A company intending to deploy IPv6 must first decide if it is starting the conversion at the core or the edge; this will be driven by the original business case.
It will need to decide if it is going to connect to the Internet with IPv6, and if so, it must apply for a company IPv6 address allocation (referred to as an LIR), which can be an IPv6 address from /48 to /64 bits in length. This is a global public address with the /64 address covering a single site. These are controlled as per IPv4 addresses by regional ISPs, such as BT in the U.K. In turn, Europe is controlled by RIPE, which is based in France.
The use of the allocated address needs to be carefully planed, especially if multiple sites are involved, each of which contains multiple subnets. A major task, therefore, is to plan out the address space so that it can be broken down into logical subnets. As an example, a base address 2001:abcd:1234:/48 could be deployed as 2001:abcd:1234:0001:/64 on the first site, 2001:abcd:1234:0002:/64 on the second site, 2001:abcd/1234:01:/56 on the third site, which in turn gets subnetted even further down. Although IPv6 has a massive address space, it can quickly be used up in wasteful deployments. Remember, half the address space of IPv4 was allocated to just 126 Class-A networks.
It goes without saying that project planning must include testing hardware and applications, running simulations and training sufficient staff to explain why it is being implemented, so that it gets their full support.
It is clear that IPv6 requires a major redesign of an existing network, which is the simple reason it has not yet been deployed on a larger scale. However, the reality is that IPv4 is now running out of addresses on the Internet, and IPv6 will have to take over.
Companies that are wise to this are now putting their migration strategies into place and starting to setup simple test beds to gain experience of IPv6, with a view that by the end of 2011, they will know how to implement it as and when needed.
Most carriers and ISPs are working on how to “forklift” their IPv4 infrastructure, which is running MPLS, to accommodate IPv6. Another option for ISPs is to offer VPLS as a simple Layer-2 solution. This has the advantage of allowing customers to run their own IPv6 network independent of the core network. Because it is a Layer-2 service, it has a flat address space — a single subnet across their network, thus being Layer-3 independent (IPv4 and IPv6) and routable — and subnets are not required. However, this is only scalable to limited number of hosts across the subnet, so it is restricted to a small number of remote sites with just a few hosts per site. A multisite, remote-surveillance deployment would be ideal.
Year 2011 will see a mounting wave of product announcements, as vendors make sure that they are positioned in the market place, so they are seen to be IPv6-ready. In addition, there are now cases of companies “hoarding” Class-C addresses and reusing them, as the number is reducing rapidly before drying up around the end of 2011. This can only increase the pressure for organizations to look closely at this stressed purchase. It is a tad ironic that around the time IPv4 runs out of addresses, it is nigh on 30 years to the day when the RFC outlining IPv4 was released, in October 1981.