Network providers and enterprises need to consider the very high probability of heavy rationing of IPv4 addresses before the end of this year. Despite the plentiful predictions and warnings for some time that this point is approaching, some will undoubtedly be caught by surprise.
Global IPv4 allocations are handled by IANA, which allocates /8 blocks of approximately 16 million addresses to the five regional internet registries (RIRs), which make further delegations of smaller blocks to ISPs and other organizations within their respective regions.
At the time of writing,IANA has only seven /8 blocks left (~2.7% of the total), and once two more blocks have been allocated to the RIRs, the last five blocks are allocated, one to each of the RIRs. Based on recent trends, this event is likely to occur around February 19.
APNIC (the RIR for Asia Pacific) will switch to a rationing policy for their final /8 worth of unallocated addresses to maximize the period that small allocations of IPv4 addresses are available for new networks. Under this policy, each APNIC account holder can receive only one minimum size block (a /22 which consists of only 1024 IPv4 addresses). It is expected that this policy will come into effect mid to late 2011.
The obvious advantage of IPv6 to IPv4 is the substantially expanded address range. Every one of the current world population of 6.9 billion people could be assigned an address range 19 orders of magnitude greater than the entire IPv4 address range. Even with an explosion of machine-to-machine communications and assigning globally unique addresses to real world objects, this should suffice until we are well into deploying an interstellar internet.
The inevitable exhaustion of the IPv4 address range has been heroically delayed with DHCP and Network Address Translators (NATs) that allow sharing of public IP addresses among a pool of users. Unfortunately, NATs break the end-to-end communications principle of the internet, causing many complications for developers, particularly for services such as VoIP, video conferencing and P2P. Aside from removing the NAT complexity, IPv6 also allows for simplified network configuration with provision for automatic address assignment and network renumbering.
For mobile devices, IPv6 allows the possibility to provide globally unique addresses. With mobile IP, these devices can move between networks while maintaining the same IPv6 address. IPSec is built into IPv6, so all IPv6 devices will support network layer authentication and encryption. Likewise for multicasting, being built into IPv6 rather than optional as for IPv4 means that multicasting of video in IPv6 networks will be universally supported, allowing more efficient support of increasingly popular video services.
Despite first being deployed in 1999, the reason IPv6 is not ubiquitous today is that it is not backward compatible with IPv4. This makes the transition difficult and it will therefore be necessary to simultaneously maintain IPv4 and IPv6 for many years and to provide solutions for interworking during the transition period.
Transition options
Customers obviously want to access the entire internet, regardless of whether the content/service is being served from an IPv4 or IPv6 network.
There are many options for providing IPv4 and IPv6 interworking. The main categories of these are:
- Dual stack - a dual stacked device is able to simultaneously support IPv4 and IPv6 and can use either to communicate depending on the other node and the network path.
- Manually configured tunnels - encapsulate either IPv4 packets in IPv6 packets or vice versa. They are ideal for interconnecting IPv6 islands across an IPv4 network.
- Automatic tunnels - can dynamically set up and tear down tunnels as required, using a means of identifying the tunnel endpoints either through servers or from information encoded in the packet headers.
- Translators - similar to the NATs used to share IPv4 addresses, translators can provide a bridge between IPv4 and IPv6 network segments, replacing the header of one protocol with the other as packets traverse the interconnection point.
In practice, a variety of solutions will need to be implemented in combination depending on local requirements and historical network architecture. The earlier that transition planning takes place, the more likely it will be successful.
Craig Skinner is a senior consultant at Ovum