In 2012, it won't be the the end of the Mayan Long Count that preoccupies the global technology industry -- it will be running out of TCP/IP version 4 addresses.
I love old school, big budget disaster movies. Nothing is cooler than watching huge meteors impact the earth and reign fire and terror upon the land and destroying familiar landmarks, like in 1998's Deep Impact (a landmark film in that it featured the first Black American president, Morgan Freeman) or Armageddon, Jerry Bruckheimer's trashy masterpiece that included a Top 40 Aerosmith soundtrack.
[EDIT: Yeah, I know The Fifth Element (1997) has a Black president of its Earth Planetary Federation whatchamacallit and preceded Deep Impact by one year, and James Earl Jones became President in 1972, but indulge me, okay?]
I can't think of better ways to waste a summer evening.
Last year's 2012, which was written, directed and produced by Roland Emmerlich had plenty of expensive CGI mass destruction porn, and met the apocalyptic film requirement of having a Black president (Danny Glover, who unfortunately never uttered the lines "I'm getting too old for this $h1t" anytime during the film) but in my opinion, didn't have that special something to make it into a truly iconic end-of-the-world movie.
What all of the great disaster porn movies do have in common, however, is that in virtually all of the plots, they usually don't discover the immensely huge problem facing the world (insert big bad asteroid, global cooling, solar neutrino emissions heating up the world's core, solar flares are going to roast the planet, the core has cooled down, the earth's magnetic field has inverted, the moon's been hit by a neutron star fragment and has altered the planetary orbit, et cetera) until it's almost too late.
The poor, disheveled-looking scientists typically start throwing huge reams of paper with empirical data around at the clean-shaven government officials like a bunch of crazy people and then are told to go back into their dimly-lit rooms and shut up. That is, until a volcano blows a gasket or a shopping mall falls into a crevasse. Or a tidal wave hits and takes out a big coastal city, et cetera.
In true disaster porn style, the hero(es) must launch a huge, multinational, mega-expensive last-ditch suicide mission utilizing whatever bleeding-edge technology we have at our disposal, usually resulting in several important characters dying on the way or towards the end of the film in selfless acts of heroism, in order to deliver the "patch" or "solution" -- typically in the form of a really big nuclear bomb -- to "stop" or "destroy" whatever is coming.
Throw in a dysfunctional romance or a strained relationship or two between a few of the lead characters and the "unlikely hero" aspect from the Campbellian monomyth and you've got the basis for the next summer or holiday season blockbuster epic.
Another thing happened in 1998 besides Deep Impact and Armageddon, though. It was the publishing of RFC 2460 by the Internet Engineering Task Force (it sounds like something from one of those movies, right?) which describes the Internet Protocol version 6 (IPv6), the successor to the IPv4 protocol that we've been using since the early 1980s.
And in true Hollywood disaster flick form, the early warnings from the computer scientists went largely unnoticed and ignored. They were told to go back to their dimly lit rooms and eat their Hot Pockets.
Despite a solid foundation and compelling reasons to move to IPv6, which is a large enough address pool that we could easily give every person on earth their own block of addresses the size of the current IPv4 pool, we continued to use IPv4, because the idea that we could run out anytime soon was largely scoffed at by the industry at large.
The problem of running out was at least a decade or more away. There was more than enough time to figure it all out. Instead, they looked into band-aid type solutions such as Classless Inter-Domain Routing (CIDR) which is now quickly outliving its usefulness and practicality.
The current estimate is that IPv4 addresses in the public address blocks will run out completely sometime in the middle of 2011 or early 2012. And with that depletion will inevitably cause some degree of disruption, which will be far more greater than the disruption that was predicted with the Y2K remediation efforts of the 1990s.
In the last several years, two key things have happened which have vastly accelerated the depletion of IPv4 addresses. One of which is the global rise of consumer home broadband, and the other the global rise and use of smartphones like the iPhone, the BlackBerry and handsets which use Google's Android, which are being activated on the order of many hundreds of thousands per day.
Unfortunately, the lion's share of these are using addresses within the public address blocks, and not the private IP blocks such as the 192.168.x.x, 172.16.x.x, 10.x.x.x which could be externally routed using technologies such as Network Address Translation (NAT) gateways.
The answer of course is, why not switch these two big albatrosses over to IPv6 immediately? Well, the problem is much more complicated and painful than it looks.
In the case of consumer broadband, home and small business networks could continue to run with IPv4 192.168.x.x class C blocks indefinitely without impacting the public address space. And enterprises could continue to run with 10.x.x.x and 172.x.x.x class B blocks for the very same reasons.
The problems arise, however, is when these networks have endpoints that touch the public Internet, which use addresses that are managed by the Internet Service Providers (ISPs) themselves that have to be requested from the Internet Assigned Numbers Authority (IANA).
In North America, requests for address space are further delegated to ARIN, the American Registry for Internet Numbers. These endpoint addresses are handed out to Internet routers connected to ISPs which provide NAT gateway services to the consumer as well as to enterprises.
As a private end-user with residential broadband, you typically see the endpoint to the public Internet as your Cable or DSL modem attached to an inexpensive SOHO router such as a Linksys or a NETGEAR. As a mobile wireless user on 3G/4G and on future technologies such as WiMax and LTE, it's the IP address used by the mobile device itself.
Many of the newer SOHO routers made in the last few years are capable of firmware upgrades that could easily support an IPv6 transition and could be used for tunneling or NATing IPv4 traffic. But in most cases, it would require human intervention and end-users would have to know how to deploy the patch.
Most end-users have never patched their firmware on their routers even for security-related patches. There are also a lot of SOHO routers in use which are not easily firmware upgradeable, and will almost certainly require complete replacement.
In the case of smartphones, the three predominant platforms in use, iPhone, BlackBerry and Android are all patchable with the appropriate new IPv6 stacks and could be automatically updated by the wireless provider with Over the Air (OTA) update with little human intervention on the customer side besides clicking on "Accept Update" when prompted.
But there are also a lot of other IP-connected mobile devices in circulation that cannot be easily updated to a modern IPv6 stack.
There is also the issue of OS-level compatibility of the IPv6 stack itself, for those organizations that may end up having to deploy the protocol internally on their own networks.
Windows Vista, Windows 7, Windows 2008 R2 Server, UNIX, most mid-range systems, mainframes, and all modern versions of Linux and the Mac support IPv6 natively, but Windows XP's and Windows 2003 Server's support is widely considered to be "Experimental" and requires bringing the OSes up to the most current patch levels. They also lack the GUI management tools of what is used to manage IPv4.
And as we all know, a very large percentage of PCs in the wild running Windows are still using XP. Either Microsoft is going to have to consider an SP4 for Windows XP to address the most current implementation of IPv6 with all the support tools required in the enterprise for large-scale deployments, or there's going to be a great deal of scrambling within enterprises to NATify and tunnel their IPv4 networks to connect to the new IPv6 Internet.
Alternatively, there will have to be a concerted effort to migrate environments to Windows 7 or Linux-based desktops/thin clients running on native IPv6 to cope with the global problem.
In addition to the OSes, which would have to be patched or reconfigured to support end-to-end IPv6, there is also the issue of legacy applications which may have hard coded IP addresses in them that point to internal or external networks which will almost certainly end up getting re-mapped.
Since IPv6 will be highly reliant upon DNS and not the new-fangled 128-bit hexadecimal IP address scheme to resolve host connectivity, this chasing down addresses in configuration files and legacy application code and changing them as required is going to be a monumental effort in and of itself, not unlike the Y2K effort of the 1990s. And the consequences for not re-mediating these types of things could be enormous, particularly if they are apps that have any impact on our national infrastructure.
Beyond the device, operating system-level and application-level patching, there is also the immediately pressing issue that most ISP's haven't even begun the process of requesting their IPv6 address blocks from the IANA, and their respective transition strategies of re-mapping their networks to deal with migration issues are in their infancy.
Implementing IPv6 will be a Herculean effort on the part of the technology industry in 2011 and 2012. But it doesn't have to play out like a Bruckheimer-esque or Emmerlichian disaster film. What is your organization doing to prepare for the IPv6 transition? Talk Back and Let Me Know.