Will the world end? Will the Internet grind to a screeching halt? Will your computer systems disintegrate into a pile of bits and bytes? In short, no. At least not yet. But you may want to consider a few things.
ISPs aren't stupid enough to cut off IPv4 access as they begin rolling out . If they did, only a tiny fraction of websites on the Internet would be accessible at this time because most content providers haven't yet connected their Internet-accessible systems to the IPv6 Internet. The ISP's subscribers would revolt, flood the ISP with service calls, and take their business elsewhere.
But this presents an interesting dilemma for ISPs. If the reports of IPv4 shortages are true (and they are), how does a service provider continue to expand its subscriber base? This problem is most acute in Asia where the growing middle class is coming online and ISPs are starting to run out of IPv4 space. America and Europe aren't far behind.
ISPs in this situation are starting to deploy IPv4 and IPv6 in a dual-stack configuration for their customers. The IPv6 addresses are globally unique, but the IPv4 address is shared by multiple customers. This sharing of IPv4 addresses is a band-aid for IPv4 address depletion. How does it work? By adding another layer of Network Address Translation (NAT).
Take a look at Figure 1 below. Think of how your broadband connection at home works. You have a cable or DSL modem that connects to your service provider and probably acts as a access point, enabling your laptop, , or PlayStation to connect simultaneously to the Internet. Your wireless is assigned a single publicly routable, globally-unique IPv4 address (D in the diagram) by your ISP, and all devices inside your house use private addresses (A, B, and C) to communicate locally.
The router translates A, B, and C to D when your devices are communicating with other computers on the Internet using NAT.
The problem for ISPs is the fact that there aren't enough globally-unique IPv4 addresses (D in the diagram) to assign to every new customer, so they are adding another layer of NAT (see Figure 2).
As you can see in the diagram, two layers of NAT are taking place for IPv4. In the first layer, the home router translates the private IPv4 addresses (A, B, and C) to an IPv4 address assigned by the ISP (D for customer 1, F for customer 2, and G for customer 3), just like in Figure 1. However, instead of D, F, and G being globally-unique, they are private addresses, and are themselves translated to E. This technology is known by multiple names, such as carrier-grade NAT (CG-NAT), large-scale NAT (LSN), or NAT444.
The obvious benefit to this type of solution is the fact that a single IPv4 address can support thousands of customer subscribers, drastically increasing the usable life of IPv4. So what's the problem? If ISPs are ensuring their IPv6 subscribers will still have IPv4 connectivity for the foreseeable future through this dual-stack scheme using shared IPv4 addresses, why do you need to get your organization's content on the IPv6 Internet anytime soon?
To answer that question, we have to look more closely at this LSN technology and ask ourselves if it will introduce problems as clients try to connect to your systems. And, indeed, in many circumstances we see this is the case. These problems can be broken down into three categories:
1. Functional: there is no guarantee that ISPs LSN solutions will work with your application. And the fact that each ISP may deploy different LSN solutions from different vendors means that you have no reasonable way of testing every possible technology. The result could be your application not working properly with potentially large swaths of the world population.
2. Performance: LSN solutions, just like traditional NAT solutions, maintain a state table for flows that traverse the device. Every packet that flows through the device triggers a lookup in the state table. Do you see a problem here? In fact there are several.
First, this has the potential of introducing a bottleneck, causing your website to load more slowly in the user's browser or worse, causing connections to be dropped by the LSN device. As the load on LSN devices increases, the problem will be compounded. And second, since all traffic in both directions for a given session must flow through the LSN device, your traffic has only one way into and out of the ISPs network. Think of the Golden Gate Bridge...all traffic must take a single path to the other side.
3. Reliability: LSN devices potentially introduce a single point of failure in the ISP network. The Internet was designed so that traffic can take any number of paths to reach its destination, but since LSN requires all packets in a flow to take the same path through the LSN device as we discussed above, an LSN failure can isolate the ISPs customers from the IPv4 Internet. Continuing with the Golden Gate Bridge analogy, imagine if the bridge was closed for repair, or worse, collapsed.
Now you may be thinking, "These are the ISPs' problems, not mine." And you would be right. However, the ISPs' problems become your problems when the result is your Web site not being accessible to your clients and customers.
So as we can see, even though ISPs are planning on providing a mechanism for maintaining IPv4 connectivity to their IPv6 subscriber base, the effects may be undesirable. To put it bluntly, you simply can't rely on someone else (in this case, ISPs) to do the heavy lifting for you. Only you can ensure your application is accessible to your customer base, whether the customers are on IPv4 or IPv6. And the way to do that is to ensure your application is accessible via IPv4 or IPv6.
So, the world isn't going to end if you don't deploy IPv6 today, but the writing is on the wall. So, where to begin? If you haven't begun your organization's IPv6 transition, don't panic, there are out there to help. And here are a few pointers to help get you started.
1. First, focus on the big picture. You (or whoever the IPv6 "transition manager" will be) needs to stay out of the weeds. There are tons of small tasks that need to be done to get to IPv6, and it is easy to get sucked in. Someone needs to direct activities across the entire organization, and that person simply will not have time to be making configuration changes on routers and servers. Make sure you are seeing the forest and not getting lost in the trees.
2. Second, don't go it alone. If you will be focused on the big picture, who will do all the actual work of transitioning the organization to IPv6 (such as software upgrades, hardware upgrades, routing changes, OS changes, firewall policies, etc.). This is where the concept of "Transition Areas" comes into play. The basic idea is to break down the organization into functional groups and to spread the load around the entire organization, using slices of time from nearly everyone to do small tasks. This not only takes the burden off of a small number of individuals, but also achieves another critical goal - introducing IPv6 into the culture and getting everyone thinking about it.
3. And third, prioritize. You don't need to do a forklift upgrade or replace every IPv4 address with an IPv6 address across the entire organization all at once. Rather, focus on one goal at a time. The most important piece is your Internet-facing (primarily Web and email). You'll want to make sure you don't lose your Internet presence as IPv6 users come online across the globe. Next, engage your organization's desktop team to ensure internal user workstations are transitioned to IPv6 so they can access the Internet and business partners over IPv6. Once these two milestones are complete, you will be in good shape and can slowly but surely transition the rest of the infrastructure and internal applications to IPv6 at your convenience.
So, will the sky fall if we don't deploy IPv6 today? Probably not. But, the longer you wait to get your content on the IPv6 Internet, the more you risk your customers losing access. Start planning for the transition now to ensure uninterrupted delivery of content to your customers.
in Network World's LAN & WAN section.