Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

IPv6 transition framework for the enterprise

Brian Heder, Network World | June 9, 2011
If all the excitement about IPv6 has finally convinced you to take a serious look at what's involved in the transition, you'll want to start with this framework.

● communications infrastructure

servers and operating systems

● IPv6 address space

● tools



● people and processes

Each TA is assigned a lead (ideally a senior-level SME in his functional area) and a number of contributors. There should be a large number of contributors, for reasons that will become apparent below. For larger or more complex TAs, a multi-level hierarchy may be desirable.

The benefits are numerous:

● Activities are divided into manageable, definable chunks. This is critical because the IPv6 transition touches so many aspects of your organization.

● The work is spread around. The IPv6 transition is too much for any one person. The idea is to use only a small slice of many people's time as opposed to all of a few people's time.

● You might get hit by a bus, so you don't want to be a single point of failure.

● Everyone gets involved. IPv6 is more than just a transition of technology. By getting everyone involved, there is a sense of collective ownership, and everyone starts thinking and learning about IPv6.

● The collective knowledge and skills of a wide variety of people are effectively utilized.

● Nothing gets missed.

The actual activities of the TAs will be outlined next, but before we get to that, one note: When assigning TA leads, be sure the individuals are reliable and excited about IPv6. You will be leaning on them a lot throughout the transition, so choose them carefully.


Now that the basic strategy is laid out, and the TA team structure is in place, it's time to get to work.

Before you can "flip the switch" and start running IPv6, you first need to assess the IPv6 readiness of your systems. Therefore the first task for your TA teams will be a reconnaissance mission. The TA leads will define a list of all the components within the scope of their TA, and assign one information gathering worksheet per component to a TA team contributor.

What exactly defines a "component" may differ depending on the TA, but a component should be a measurable, definable unit. For example, if one of your TAs is Communications Infrastructure, a component could be a particular router (for example, a Cisco ASR 1013, or a Juniper MX480). If one of your TAs is Processes, a unit might be one process (for example, a subnet request process).

For the technical TAs, components can typically be broken down into two types:


Previous Page  1  2  3  4  5  6  7  Next Page 

Sign up for Computerworld eNewsletters.