I am not a number, I am a free man! – "The Prisoner", sampled by Iron Maiden (edited because geeks are picky and well, they're right even though I always think of Maiden and Eddie first before getting to the actual origins)

eddie

We, meaning everyone who deals with technology for a living, know that the move to IPv6 is inevitable. We simply must migrate in order to maintain the scalability of the Internet and its infrastructure. Well, we could continue to use technologies like NAT and SNAT in order to conserve IPv4 addresses, but really that’s just not practical in the long run. Eventually even doing that we are likely to “run out” of IP addresses, so it’s about time we started doing something about it.

The migration has already begun, quietly, but as more consumer facing services begin to make the move expect to see more coverage and analysis of IPv6 in general, such as is the case with Comcast’s recent announcement it was beginning the transition.

Comcast is making a move to IPv6, making IPv6 transit services available to its wholesale customers.

This a significant development because in less than two years, the IPv4 address space will be exhausted, but it doesn't mean there won't be any more Internet addresses. IPv4 has a 32-bit address size, allowing for only 4.3 billion addresses. In contrast, IPv6 is a 128-bit address space allowing for a staggering 340,282,366,920,938,463,463,374,607,431,768,211,456 possible addresses.

Staggering, indeed. Remember not too recently we looked at statistics regarding the number of Internet users across the globe, with the estimates from Nielsen coming in around 1,596,270,108. That number, while large, seems incredibly insignificant next to the number of addresses possible with IPv6.

So what are we going to do with all those addresses?


CONGRATULATIONS, MR & MRS CUSTOMER! YOU ARE NOW THE PROUD PARENTS OF… AN IP ADDRESS

The number of IPv6 addresses available makes it possible, and probable, that every device – mobile, fixed, dynamic – connected to the Internet could have its own IPv6 address. This would, of course, solve all sorts of problems with IPv4 and NAT (Network Address Translation) that has to worked around every day just so things on the Internet work as expected.

Along with this possibility comes another possibility; one that is both promising and petrifying at the same time: individually assigned IP addresses.

Think about it – if every person had an IP address assigned to them for their personal use, security would get a whole lot easier. Tracking down an attacker would be a simple case of looking up the IP address in a database. The Internet would, possibly, become a much nicer place, too, as the “anonymity” assumed by many would immediately disappear. If I know your IP address, I know who you are, Mr. Internet Tough Guy, and it would be simple to call you on your rude behavior. Assigning individual IP addresses could, ostensibly, solve some of the economic issues with publication and media. Advertising rates on the web are abysmal primarily because of the lack of qualification of visitors. If a site knows who you are and what you do for a living, it can actually charge a premium for advertising of products and solutions targeted toward specific audiences if it can prove a high enough percentage of its visitors are qualified and not just random teenagers out looking for elf porn.

The technical necessity of IPv6 could drastically change a lot of behavior and markets, whether individuals were assigned IPv6 addresses or not. Given the plethora of addresses available, ISPs can assign static addresses to each customer rather than leasing out IPv4 addresses. That IPv6 address being tied to your Internet activity is priceless in its value to marketing and advertisers.


THE GOOD SIDE

But let’s look at the good side of IPv6 for a minute. If there are infinitely more IP addresses available, the costs of obtaining one or even a few of them should certainly decrease – dramatically. IP addresses will no longer be a “precious resource” for which customers must pay a high premium to obtain. Cloud providers, too, should be able to more freely hand out IP addresses without charging (as much) for their use and can actually manage them more effectively.

Remember that sharing of IP addresses could be detrimental to the availability of applications in the cloud. And even if that’s not the case, there’s still the little issue of IP address/domain propagation across the Internet. Getting an IP address associated with a host and domain is easy. Propagating that information such that customers and users can access the application takes time, and that time varies based on the configuration of a long chain of servers across the Internet over which you, as a cloud customer, have no control.

Being able to assign “fresh” IP addresses to cloud-based applications should solve this problem. If providers have a pool of IP addresses that have effectively “timed out” of cached DNS across the Internet, they can reassign them and get around all the little niggling problems that could crop up today.

As for Mr. & Mrs. Customer, hey, there’s good for you too. If an IP address was tied to an identity, wouldn’t it be possible to get rid of login and identity verification systems? Couldn’t we just leave a comment on a blog or a post in a forum and not have to remember which of our 30 passwords goes with the site (you do have more than one password on the Internet, right?).


REALITY

None of the above is likely to happen (at least any time soon). The technical challenges inherent in having an IP address follow a user around the Internet are not insurmountable, but they would put unnecessary strain on the infrastructure. The security risks of making every device a consumer might own accessible via the Internet (cause that’s one of the potential results of everything IPv6) certainly outweighs the potential that we can more easily track attackers. Routing tables are big enough, and trying to dynamically modify them because a user moved from point A to point B is just not feasible, nor are the “benefits” tangible enough to entice someone to try. It’s an interesting exercise in exploring the possibilities that’s fun but not very helpful in terms of figuring out what a move to IPv6 means for organizations.

The reality is that even though ISPs and service providers may be moving to IPv6, inside the enterprise data center it is likely to remain IPv4 for quite some time. In some cases, that’s because of the cost of replacing legacy equipment not capable of supporting IPv6 – older routers, switches, servers, operating systems, mainframes, etc… – would be prohibitive, particularly today, and without much benefit internally, where there is no lack of IP addresses stemming from the use of IPv4.

Also prohibitive internally would be the need to rewrite hundreds or thousands of security and access policies based on IP addresses and networks and subnets. Testing such a massive change alone would require hundreds of man hours and, in the process, likely render the network and the applications it delivers unavailable.

What’s going to be necessary, at least in the short term, is a way to insulate internal architectures from external changes catalyzed by a migration to IPv6. An IPv6 <—> IPv4 gateway, for example, allows organizations to retain their internal IPv4 based architectures while supporting the external move to IPv6. Such technology will be necessary for some time while providers move to IPv6 and organizations can formulate a rational, sane strategy for moving its internal architectures to IPv6 without “rebooting” their data center.

Devices that typically reside at the “edge” of the network: routers, firewalls, application delivery, WAN optimization, need to support both IPv6 and IPv4. Initially they’ll need to present IPv6 externally and support IPv4 internally, but one day that, too, will move to full IPv6 support. When you’re out looking at solutions today, then, it’s important that IPv6 support end up higher on the list than perhaps it was yesterday.

 

Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share