 |
posted on Monday, November 09, 2009 6:00 AM
For decades now there have been warnings - some dire, some simply informational - that the depletion of IPv4 address is imminent. We’ve (meaning IT) known about this eventuality for a long time but now it’s starting to hit the mainstream media and of course the sky is falling. These dire warnings of peril continue to surface more frequently as the actual ticking of the IPv4 timebomb grows louder and louder. Some comments on articles related to this topic dismiss the urgency, claiming that because we (meaning IT, of course) have known about this problem for so long that it’s not really a problem. If that were true then the deployment of IPv6 support would be more extensive today, wouldn’t it? But it is not, because it isn’t just “throwing a switch”. We can’t just turn off a data center, change all the addresses, and then turn it back on. Applications need to be available, infrastructure needs to be running, and processes need to keep moving. The change to support IPv6 needs to occur as transparently as possible, with as little disruption to the business as possible. This is actually more possible than it first appears because the need to support IPv6 is really external, not internal, so the gradual migration on the inside can occur as necessary without the same level of urgency as external support. That, for applications at least, may be a lot easier than you think. 
F5 BIG-IP IPv6 Gateway can be deployed on most existing F5 BIG-IP platforms and provides nearly instantaneous support for IPv6 externally. The IPv6 Gateway module provides translation between existing IPv4-enabled infrastructure and applications internally and IPv6 addresses externally, giving organizations more time to address the time and resource consuming process requires to migrate internal architecture and applications to IPv6. Using an IPv6 Gateway enables organizations to make IPv6 support for applications and infrastructure a part of upgrade and new release cycles rather than as a separate, dedicated project. This means projects can absorb the costs associated with migration as they are upgraded, patched, or new versions are released. Employing a gateway approach further limits the impact on IT. Initiating a full-scale IPv4 –> IPv6 migration internally would consume the time and efforts of nearly all IT staff, prohibiting them from spending time necessary on other important and perhaps business critical projects and tasks. IPv4 address depletion is, as we all know, a fact of life. It’s not a surprise, it’s not that we are ignoring the problem, it’s just that addressing it – especially for large data centers – is an unwieldy task that is not so simply undertaken. By employing an IPv6 Gateway, however, the immediate risks associated with the depletion of IPv4 address is mitigated and IT can continue to address the problem internally, on its own terms, without risk to the business. Basic IPv6 support is free of charge. In versions prior to v10 we traditionally charged for the IPv6 Proxy capability – the ability to run IPv4 on one side of your network and IPv6 on the other, and the BIG-IP would make those networks interoperate seamlessly. With the introduction of v10, we have decided to incorporate that functionality as part of our base offering so you can now upgrade to v10 and get this valuable functionality for free – this is available on the 1500, 1600, 3400, 3600, 3900, 6400, 6800, 6900, 8400, 8800, 8900, and VIPRION. So if you haven’t considered how you’re going to stop the sky from falling on your particular piece of the Internet (or at least want to stop the cries of those within your organization who think it is falling) give the IPv6 Gateway a look. Related Resources:
|
|
