The End is Nigh (for IPv4)
Everyone is telling me that 2012 is the year of the apocalypse. The Mayan calendar is supposed to end on December 21, 2012 predicting the end of the world. In the media, all I hear about is the coming zombie apocalypse and impending doom for all of humanity. Even the Centers for Disease Control (CDC) is warning me about the coming zombie apocalypse! I like to believe that there is a little hype involved in these proclamations. People have been preaching about the Internet's version of the apocalypse for over 20 years. In the Internet, we have known that there is a problem with the number of addresses available within the IPv4 framework for quite some time. IPv4 was defined in 1981 with the publication of RFC 791. There are 32 bits allocated to each host's address, which means there are a possible maximum of 4.3 billion addresses available.
Like the number of uninfected humans in the zombie apocalypse, soon it became apparent that the number of available addresses would become an issue and we would exhaust them in short order unless measures were taken. These measures include the transition to classless IP address blocks, RFC 1519, the use of RFC 1918 private address blocks, and leveraging RFC 2131, Dynamic Host Configuration Protocol to reuse a pool of available addresses. Ultimately, it was determined that a new version of the IP protocol was necessary to support the increasing number of IP-enabled devices. IPv6 was developed and ratified in 1998 with the publication of RFC 2460. While many features were upgraded, the primary change is the expansion of the address space for hosts from 32 bits to 128 bits. This increases the potential number of hosts to 340 undecillion addresses (that's 36 additional 0's, by the way!). With IPv6, the former CIO of the United States Department of Defense states that every single entity in the military including every bullet will eventually have its own IP address.[1]
Move Along in an Orderly Fashion
Until the entire Internet has migrated to using IPv6 addresses, the communications service provider (CSP) needs to manage the support of their existing IPv4 infrastructure while migrating the network components to an IPv6 architecture. During this time, all of the components in the network will still need to be able to communicate with one another, whether they have an IPv4 or IPv6 address. The CSP will typically implement carrier grade network address translation (CGNAT) techniques during the migration to ensure connectivity between hosts in the different networks.
Doing CGNAT is not just about modifying the IP addresses in the packet header. There are a lot of application protocols that embed IP addresses in the data payload and if these are not translated as well, the application will not function properly. It is important when CGNAT is implemented that the devices that are doing the translation are aware of the applications being used. Any appropriate content needs to have the IP address translated in addition to the source and destination in the header. CGNAT solutions use Application Layer Gateways (ALG) which are processes that recognize specific applications and are able to properly identify IP addresses within the content and allow for the proper address translation.
There are ubiquitous applications that need to be handled with an ALG such as DNS and FTP. It may be necessary to convert a DNS AAAA request (IPv6) to an A record request (IPv4) and vice versa. There are protocols that are critical in a CSP environment that will need special handling as well. Session Initiation Protocol (SIP) and Real Time Streaming Protocol (RTSP) are two protocols widely seen in the CSP network that require care when there is address translation occurring. It is important to have ALG functionality for the protocols you know that need assistance, and it is also important to have a platform that can adapt to protocols you may not be aware of and protocols that do not even exist yet.
It is important to be aware of the impending doom and migrate to IPv6, but it is also important to do so in an orderly and professional manner. This means CSPs need to take care in their migration strategies and ensure that none of the applications on their network are negatively impacted by the changes. Otherwise, the prophecies become self-fulfilling and we end up creating our own apocalypse.