IPv6 Network Administration

Deploying IPv6

At this stage, we have looked at a good deal of the background information and deployment techniques relevant to IPv6. With this knowledge under our belt, it's time to start thinking about applying it to your own situation. As with any process, deciding what to do is half the battle—and executing on those decisions is the other.

The first question to consider during the planning process is the motivation for the change. You're thinking about enabling IPv6 in your network—why? Perhaps you have been handed a business requirement to support it by a certain date. Perhaps the standards for your specific network mandate it. Is there a technology trial planned? Or maybe you are an ISP who needs to deliver native IPv6 routing services to its edge networks. Indeed, perhaps customers are even asking for it!

Whatever the motivation is, it will help to establish what the important parts of the implementation are by identifying which areas of the network need attention. (For example, if you are converting your desktop network, the important parts are the desktop network itself, its path to the outside world, and its path to internal services.) You may be required to be more or less formal, depending on your organizational environment, but we would strongly recommend the production of some kind of document listing the existing network elements, describing their ability to support IPv6, and identifying of which parts will need to run IPv6 in the future. This allows you to prioritize your rollout correctly. You will come back to this document many times during the deployment, so keep it safe.

With your network document in hand, you can then begin to construct a deployment schedule, keeping in mind your original motivation for the change. A deployment schedule is, at its simplest, a list of things to change and a time to change them. For organizations with change request procedures, the schedule should probably be submitted as one request, since while there may be many distinct changes in the plan, the motivation behind them all is the same. The change request system should hopefully take care of communicating what is being done and why within your organization.

For example, perhaps you have a requirement to IPv6-ify your desktop network. It might be that your desktop network is highly segregated—perhaps on it's own VLAN. Modulo operating system support, the more segregated the network, the easier it is to turn on IPv6 for that specific piece of it. Conversely, for large flat networks, enabling IPv6 is a much larger job, purely because it's much more of an all-or-nothing proposition, and incremental deploy-then-test methods are not applicable. An example deployment schedule for such a segregated VLAN might be as simple as "Switch over desktops to IPv6 capable stack on evening of 21st; allow one week to settle. Switch over main router to dual stack on evening of 28th; test outgoing and incoming IPv4 and IPv6 connectivity." It should also have a section for fall-back, or reverting to the previous state of affairs if there is some kind of catastrophic failure.

The above raises some important general points. Any sufficiently large organization will have more than one person affected by what you are going to do. It is your responsibility to communicate about these changes, either through the change management process when that is appropriate, but directly to the stakeholders where necessary. Communication is a key element of any deployment plan, and IPv6 is no different. Tell everyone you can about what you're doing, why you're doing it, and when you expect it to be finished. Furthermore, a deployment plan for any new service, not just IPv6, should also have an operational component to it. How does this new service interact with what the help desk does already? To whom should calls or emails about it be directed? And so on. This final component of the generic IPv6 rollout we call an Operational plan, and it should list who will have to look after what you've done, and support it. The deployer should try to plan for the indefinite period of IPv4-IPv6 coexistence!

So, to reiterate: Decide why you are doing an IPv6 deployment. Identify what you need to change, and make sure everyone who cares knows what you're doing, and when. Schedule, perform, and test those changes. Tell the operations folks what's been done, and if you have network development and security folks, they need to know too. If caution dictates, do this as an incremental process so you can fully absorb the impact on your network. Always have a reversion plan in the highly unlikely event something goes very wrong. Finally, note that all of the above implies an already existing organization and an already existing network. For "green-field" setups, things are slightly different—we talk about those later.

Of course, this is a sadly generic deployment plan; you could use it for almost any big change. But that doesn't make it any less valid as a framework; however, it is the details of each network, and the details of actually configuring a particular desktop or router to do IPv6 that would most readily cause a deployment to fail. We describe how to do the most common IPv6-relevant operations in Chapters Chapter 5, Chapter 6, and Chapter 7, which will hopefully be useful input into your plans. (But for those looking for more concrete details of individual configurations at this stage, we recommend skipping ahead to the Section 4.7 later in this chapter, where we present three important model deployments.)