The business case for IPv6 in service provider networks – particularly broadband service provider networks – is all about the address supply, and you know the routine well: The IANA IPv4 address pool is gone, the APNIC, ARIN, and RIPE pools will be gone before the end of the year, yadda yadda yadda…
(LACNIC and AfriNIC IPv4 pools will last a bit longer, but they’re on their way to depletion also.)
So if you are a broadband service provider and you want to keep growing your customer base, you had better be well on your way to supporting new customers with IPv6.
But if you run an enterprise network, IPv6 is probably not on your radar at all. Why should it be? Your network is warm and happy behind NAT44, RFC 1918 addresses will easily support projected growth for the foreseeable future, and your public IPv4 addresses are more than enough for your public-facing servers.
Sure, there will be vast herds of new IPv6 users on the Internet in the coming years now that IPv4 is used up. But broadband providers are taking measures to insure that their new IPv6-enabled customers can still reach IPv4-only content through large-scale NAT solutions like NAT444 and DS-Lite. So what’s to worry about?
Well, those LSN-based transitional services are what’s to worry about. As I wrote in a previous article, LSN is a necessary but problematic solution for connecting users to IPv4 content in a post-IPv4 world. It allows service providers to use private IPv4 addresses for the IPv4 side of dual-stacked customers, centralizing their limited pools of public IPv4 addresses where they can be efficiently shared among thousands of users.
But LSNs come with a long list of difficulties. For example:
· Many applications that have been adapted to work though a single NAT44 will break when crossing a double-NAT architecture like NAT444
· Services that identify a user by IP address will have problems when an address on the outside of an LSN is shared by thousands of users
· The stateful address mapping and heavy logging requirements in an LSN may present a performance bottleneck
· LSNs can be a single point of failure, and are an attractive target for CPU depletion or address pool depletion attacks
As an enterprise network operator, is this really your problem? LSNs are in the service provider network, after all.
The effects of LSNs could certainly be your problem. The great majority of end users don’t know how the Internet works, and don’t care how it works. In fact if we do our jobs well, the network should be transparent to them. End users only care about the services they are using. And there’s the rub: If a service is not working correctly, the user is going to blame the provider of that service.
Let’s say you operate a bank’s network. If one of your customers cannot use his online banking services, he is not going to care whether it is his broadband provider’s LSN that is causing the problem. He is going to blame the bank.
And that’s the case for IPv6 in the enterprise. Or more accurately, at the enterprise edge.
You can remain warm and happy behind your NAT44, for now. There’s not much of a case for IPv6 there yet. But do you run applications accessible by the public? E-commerce? Customer account management? Content provisioning? Perhaps, even, a simple news service where subscribers are allowed to post comments? (Are you listening, Network World?)
The problems of LSN become your problems. And the way to bypass those problems is to bypass LSNs: Make your public services accessible directly over IPv6.