Tag Archives: ipv6 deployment

Thinking Strategically about the Benefits of IPv6

Posted on by

5

Somewhere in the C-suite

Somewhere in the C-suite

In my last blog post on how to sell IPv6 to senior managers and executives, the feedback I got from mailing list discussions was that the case for IPv6 was more of mitigating risk than some inherent benefit of IPv6 itself [1]. That is quite true depending on context. In this article, I will attempt to give more insight into the benefits of deploying IPv6.
 
In a nutshell, viewed from the traditional lens of benefit as something we know and recognise based upon experience, IPv6 has little benefit apart from the large address space. So if that is the only way you can view benefit, then you can stop here, IPv6 has no benefit beyond an increased IP address space, and in the short term, that benefit is definitely outweighed by the costs of staff training, upgrading software and equipment and assuring feature-parity with existing IPv4 solutions. So I’ll admit that in the immediate to short term, apart from mitigating the risks of IPv4 exhaustion, there isn’t a concrete traditional business case for IPv6 for most organisations particularly in IPv4-address rich countries. The realities for IPv4-address poor countries (China, India, most of Africa) can be very different.
 
Another way to look at the benefit of IPv6 is to realise that there are certain benefits that are not objectively know-able at this point in the life of IPv6 protocol. Such benefits may include but are not limited to:
  • A more valuable network resulting from more connected network nodes. (Metcalf’s & Reed’s Laws).
  • New and improved services that may result from a larger Internet where the end-to-end model is largely restored and preserved.
  • Improvements in network security resulting from the massive adoption and use of the readily available IPsec protocol in all network hosts as well as the increased visibility that an Internet with much less address translation (ideally none) will afford us. 
To get an idea of why all the benefits of IPv6 are at this point not knowable, think back to the invention of the TCP/IP suite in 1982, there was literally NO ONE that could have fathomed how valuable it would become just twenty years later. But here we are, doing almost everything from communication, learning and crime to governance, espionage and ‘war’ over the TCP/IP-based Internet. Therefore, despite the ubiquity of today’s Internet, we cannot at this time with hindsight alone confidently project how valuable or not an IPv6-based Internet would be and therefore all attempts to quantify the benefits of IPv6 based upon our experience and knowledge of IPv4 is at best grossly incomplete.
The inability to predict the future accurately based on the past is also the reason why traditional Return on Investment (RoI) is not a useful tool in the analysis of the benefits of IPv6. The tools and techniques required to think strategically about IPv6 are not those the corporate world is used to. They cannot depend on data obtained from experience (the past) because one thing we can tell for sure based upon our experience with Internet-driven IT industry is that the experiential data of the past are not always going to be good indicators of future performance or capability. If they were, then back in 2007 for example, the best technology to invest your money in might have been the PC. But as we know the iPhone happened and ushered in the era of mobile computing driven and largely dominated by smartphones and now tablets. And even these might just be waypoints to wearable computing and some other computing paradigms.
 
To conclude, I’d like to borrow from Clayton Christensen’s theories of Disruptive Innovation to explain how IPv6 could become the dominant technology used on the Internet (assuming you don’t believe that IPv4 address exhaustion is enough reason). We can look no further than the evolution of the PC itself and draw parallels. Back in the the period of 1950 – 1970s mainframe computers reigned supreme and the companies that made and sold them were the dominant players in the digital computers market. Then in 1977, the PC appeared on the scene, it too was a computing device, but it in terms of everything that mattered to the currently paying customers of mainframe computers (power, features, capabilities, reliability), the PC was worse largely regarded as being useless.  Thus, quite predictably, in accordance with everything that represents good management and thinking, all the mainframe companies chose to ignore the PC (even though they had the technology, resources and marketing organisation to design and market a great PC), all except one of them – IBM. It was also the only mainframe computer company that survived to this day. The rest is living history.
 
Drawing parallels to the above anecdote, the IPv4-based Internet is the dominant technology that provides the features that the majority of today’s Internet users want (or think they want) and are ready to pay for. IPv6 much like the PC in the 70s is the immature, apparently untested contender that might be unattractive to majority of customers today (ever wondered what all those cries of ‘lack of feature parity with IPv4′ really mean?). There are currently a few users (mostly the nerds) that want IPv6 for itself and relatively few device, application and service vendors that want to enable it because they don’t just see the benefit right now. I am willing to bet that like the PC, IPv6 will mature slowly under the radar of the naysayers and in the custody of those vendors whose processes and priorities enable them to select and start IPv6 deployment. It will then be ‘good enough’ or even surpass what IPv4 can possibly offer to the mainstream users. When this happens, users will turn en masse to adopt it, leaving any organisation that failed to deploy IPv6 in a very precarious situation – the same one Digital Corp, Wang, Control Data and the other mainframe computer businesses that failed to adopt the PC found themselves in.
 
In a nutshell, there are two kinds of organisations:
 
a) Those whose resources, processes and priorities/values are heavily IPv4-centric and who for now see nothing but risk and poor features in IPv6. These ones will squeeze every little they can get out of IPv4 and likely tend towards a Large Scale NAT (LSNAT) strategy when they are faced with the problem of IPv4 exhaustion. They will continue this strategy until the costs and complexity of IPv4 maintenance become more that they can bear and the resulting performance 
 
b) Those whose resources, processes and priorities/values enable them to prioritise deployment and testing of IPv6 despite its apparent lack of features and maturity compared to IPv4.
 
One of these types of organisation will lead the provision of devices, software and services for tomorrow’s Internet, the other type will lose relevance and then will play catch up. Just remember this: The day you see concrete data to show the benefits of IPv6, it means you are already late to the game, that data will be coming from an early mover who is already making a ‘killing’ with IPv6. So which of those companies would you own? or be working for/with?

Getting IPv6 Done: A Step-by-Step Framework for Planning an IPv6 Deployment

Posted on by

7

It often happens during one my IPv6 training courses that a participant comes up and asks (or puts it as something that was missing from the training) – “What are the specific steps for deploying IPv6?”. This often leaves me puzzled as I assume any engineer will have a framework for achieving technical projects. Then it occurred to me that not all engineers have project management experience or knowledge, hence this post.

Well the answer is that to deploy IPv6 right, you take the same project-based approach you’ll take for any project, which put simply goes like this:

  1. Define clearly what you want to achieve – the goals.
  2. Identify the list of tasks you will need to achieve each goal.
  3. For each task, identify what resources you will need – people, finances and time
  4. Get management sign-off/approval for the project
  5. Start executing the project – aka Deploying IPv6
  6. Document the project and lessons learnt.

This is a simple framework I believe anyone can follow and deliver an effective IPv6 deployment for their organisation. In the world of all effective people, frameworks and plans are everything. So let’s review each of the steps.

[A] Set Clear Goals for the IPv6 Deployment Project

If you don’t know where you are going, how are you going to know it when you arrive? This stage is the most important task you need to perform as the success or failure of the entire IPv6 deployment depends on it. I’d recommend having very clear and specific goals like:

  • Have our public facing Internet services available on IPv6 by December 2013
  • Be able to provide dual stack (IPv4 & IPv6) services to customers by May 2014
  • Ensure that all our internal users can access the Internet over IPv6 by end December 2013
  • Roll out our LTE service exclusively on IPv6 by end of Q2 2014.

Notice two things present in each of these goals – they are Measurable and Time-based. (They are also SMART – but as you must have guessed, I think SAR are overrated.)

Your initial goal might possibly be just a first iteration, and as you plan the project, you might need to clarify it more. To highlight the importance of this step, in November 2012, Andrew Alston reported an interesting issue with Yahoo IPv6 access for South African users; while there was IPv6 connectivity and AAAA DNS resource records, the services themselves were NOT configured to serve content over IPv6! And that being the case users would not get failover to IPv4 even if though the server was perfectly capable of serving its content over IPv4.

That looks to me like poor goal-setting on the part of a project manager or coordinator. Yes it’s the whole “Begin with the end in mind” thing and it is still a great principle for doing anything right – IPv6 Deployment included. A goal of “Configure IPv6 addresses on the web server and create AAAA records in DNS for our website” will strictly yield a different result from “Ensure that our website is fully accessible directly and natively over IPv6″.

[B] Identify the List of Tasks Required to Achieve each Goal

Here you pick each goal and ask yourself – “what tasks must we accomplish in order to achieve this goal?” In project management terms, this is called progressive elaboration and the result is that you will end up with a list of tasks that must be done to achieve the goal – the Work Breakdown Structure so to speak. For example, take a stated goal like :

G.1 Ensure that our web servers are accessible over IPv6 by May 2013. This can be progressively elaborated as follows:

  1. Perform audit of the web server infrastructure to ensure it can support IPv6.
  2. Address any recommendations from the audit above.
  3. Review security policy relating to the web services and update to cover IPv6.
  4. Create AAAA records in DNS infrastructure for the web server.
  5. Configure IPv6 addresses on the web server.
  6. Configure IPv6 addresses on load balancers (if applicable).
  7. Configure the web server software to accept and server requests over IPv6.
  8. Establish a test plan for this deliverable.
  9. Test the web server against the test plan.
  10. Launch the service.
  11. Update all relevant documentation.

Each of these is a task that will take specific inputs, be allocated specific resources (time, equipment, people etc) and deliver specific outputs. It is the combination of these outputs that will determine whether the goal has been achieved. Some of these tasks are are interdependent and so one will depend on one finishing before they can start. Other of the tasks are independent and can be assigned to different resources and started concurrently. The project manager will have to analyse these tasks to find out any inter-dependencies so as to be able to optimise how the tasks and resources are allocated and executed. The tools and techniques of PERT, CPM and Critical Path are quite useful here, Critical Path being the most effective.

[C] Identify Resources Required to Accomplish each Task

This part is a lot easier once you’ve clearly specified and elaborated the goals. Starting with each of the tasks associated for each goal, list the resources you will require. Here again, you might want for each task to look at resources required in this framework:

Skills: what specific skills are required to perform this task. Knowing what skills are required, will point to what people in the organisation have those skills and would thus be resources on the IPv6 Deployment project. Think through this right and you just might have better luck that this project manager.

Getting project resources

Time: how much time can reasonably be expected to be spent on this. These are just estimates. Beware of the traditional problem of PERT scheduling though.

Equipment & Software: Some tasks might require specific equipment for their accomplishment, list them here.

Money: Need I say more? …

A project coordinator or manager who is non-technical may not know the exact details of these requirements, but that’s where they go talk to consultants, existing technical leaders in the organisation or do research, including mailing lists.

I can’t stress enough the importance of doing due diligence here. One of the complaints I hear from executives is “my techies want this cool new thing but they can’t tell me exactly how much in terms of resources, man-hours and money this will cost us, what (if any) are the risks, their impact and how we will mitigate those risks”.  If this is done right (and then taken further by identifying some ways to cut costs by re-using existing resources), then the business executives are going to be more impressed and it helps greatly in the next stage — getting management approval and sign-off.

[D] Get Management Approval/Sign-off for the Project

If you did steps [A] to [C], congratulations, you now have a project brief that management can look at and more importantly sign off on. Rather than dump a long document on them, you might want to schedule a meeting and do a presentation to the management team or better still the decision makers. In your presentation you’ll give them the short version which essentially says something like:

“Our organisation needs to deploy IPv6 for the following reasons (list the reasons). The benefits to us are (list the benefits). In order to do that we need to do (list the key high level goals that must be achieved). There are risks involved (list risks and their impacts) but here is how we will mitigate those risks. We will need the following resources  and it will take X amount of time and cost $dollars”

Even if management asked for it, you still need to get their buy-in and sign-off on your project proposal because that is what will open the tap to resource allocation process so that you may get the resources you need to move on to a successful implementation.

Well as an effective project coordinator or manager, you need to “pre-wire” the meeting where you present the project proposal. In order words, you need to identify key stakeholders, their influence and how much of their support you need and first approach them and share your plan with them, collect their feedback. If you do that, then your actually presentation/meeting will be short and fruitfully because there will be no ‘surprises’ (something which I have found many managers and ‘bosses’ feel mortally threatened by).

If you did a great pre-wiring job, then you’ll walk out with sign-off of your proposal, if not, then you might well get some feedback (essentially management saying we cannot give sign-off until certain aspects are reviewed). In any case you if there objections/concerns, you will have to address them and repeat till you get sign-off on the project proposal.

[E] Execute the Plan, Documenting Everything as you go

Congratulations! Armed with a management-approved deployment plan, now the real work starts. Getting down to actually DOing the work of deploying IPv6 in your organisation. Simply put, you’ll now engage whatever collaborative tools and processes your organisation has for doing projects to get the work of the project done. If your organisation has a project management office or has some official project management methodology they use (PRINCE2, PERT, Critical Chain etc) be sure to use it so as to benefit from hopefully in-grained organisational processes and the culture.

Ultimately, you’ll review the work breakdown structure, have meetings with various people involved to clarify deliverables, put the project milestones and tasks up on the company project management software (you are using one rather than email right?) and assign them to various people, follow up with various units for other resources and make sure things run on schedule – adapting as the project progresses.

Don’t forget to keep communications flowing amongst the various stakeholders, these updates include but are not limited to:

  • Follow up communications to people that have tasks that are about to start, are overdue or that have changed.
  • Status updates to project champions in the management team to keep them in the loop and make sure they can continue drumming support at the executive level.
  • Regular updates to the entire organisation to know when key milestones have been achieved.
  • etc etc

It is also great to make ‘documentation’ a mandatory part of the accomplishment of each task or work unit. That way there’ll be sufficient low level documentation from which the project manager, coordinator or editor can collage accurate global documentation for the project.

[F] Update Relevant Organisational Processes to Integrate new Capabilities Resulting from the Deployment

So you have now deployed IPv6 on your infrastructure and services and everything has been tested and works like charm. Congratulations …but you are not yet finished. What you’ve done till now is deliver a new service or set of capabilities. This must be integrated into the organisation’s business model for the organisation to derive any value from it. It means some or all or more of the following tasks must be done:

  • Train the marketing and sales staff on the implications of IPv6 -and yes, help them integrate IPv6-capability into their marketing and sales literature and messages.
  • Train the support staff in the necessary skills required to deal with customer problems that are IPv6-related.
  • Review and updated any organisation processes that have changed as a result of the new deployment.

While not an exhaustive step by step guide, I am confident that anyone that adopts such a framework and clear goal-oriented approach to be able to deliver an IPv6 deployment project in a professional and effective manner.

Have you been part of an IPv6 deployment project lately? Please share you perspectives in the comments section.