How to ‘Sell’ IPv6 to Executive Management – Guidance for Engineers

 (aka ‘IPv6 for Managers for Network Engineers’)

“Genius!”, the CEO says as he enters your office (ok more likely your cubicle or desk-space or whatever corner of the office you prefer to go hide out in to concentrate), “I’ve been hearing a lot lately in the news about an IP Apocalypse and this new thing called IPv6. I also understand you recently attended an IPv6 training. I want you to make a presentation to executive management to tell us why this is important to us what our approach as a company should be.”

You think … “Isn’t this whole thing obvious?”. Well, it may be to you, but not to the suits and non-geeks out there who happen to be in the majority and sit on some critical resources you may need. Anyway you have your assignment and more importantly a chance to stand out of the ‘techie’ herd by proving that you are smart at more than designing and building networks and services (which they think is quite easy by the way!) but can connect the dots of technology and to the big picture of why your company exists and makes money.

The purpose of this blog post is to help you think through, create and deliver such a presentation. This isn’t about Powerpoint or Keynote (try not to abuse them) and I assume your presentations skills are good. I would say that with proper preparation (which I am going to guide you through) you should do this in less than 15 slides and take no more than 45 minutes, including questions and answers. The objective is to convince your management to approve an IPv6 Deployment project in the company. Once you have approval for a deployment, you can use the guidance at in this post to plan you deployment project in detail.

I recommend that you research and plan your presentation around the following framework (if you’ve read my previous posts, you know by now for me its all about frameworks and processes):

  1. Set the strategic context: how your organisation derives value from IP networks and the Internet.
  2. Overview of the problem: IPv4 exhaustion.
  3. Implications of IPv4 Exhaustion to your organization’s business model.
  4. Introduction of IPv6 as a solution to IPv4 exhaustion.
  5. Understanding the risks involved.
  6. How much will deploying IPv6 will cost.
  7. Call to action.

[a] Set the strategic context: How your organisation derives value from IP networks and the Internet

For your plan to have any chance of getting the attention of executive management, it must tie into the overall strategy of your organisation. The majority of organisations have some kind of strategic plan (which in the worse case is an incomplete pile of unclear stuff cobbled together during an off-site retreat by people alien to operational realities – but that’s another point). That document likely guides how various projects and operations get prioritised for time, money and skills within the organisation. It also contains the vocabulary that will get the attention of your executive management.

dilbert-strategic-plan-alignment

Great or sloppy, look for and use the company strategic plan!

Well, read that plan, re-read it and know how to wield it to convince management. Ignore its flaws but look for the core of the document i.e. – why was this document written? what problems is it trying to solve? Somewhere in the document, you will find something to which to hook the Internet and by extension IPv6 into the value system and priorities of your organisation.

Sometimes, how your company generates value from the Internet will be clear because the Internet is at the core of what you do e.g. Internet Service Provider, network equipment and software vendor. In other cases, the Internet plays a secondary role, and it just supports your core business activity. The support could range from the mission critical (think e-Commerce, online banking, e-learning etc) to just normal support (research, communication etc)

Don’t forget to look at context from the external perspective. Think of your competitors and clients – what are they doing? or plan to do? and what technologies or innovations will they be needing to achieve those goals? What will be the effect on your brand standing if you are perceived in the market as the laggard when it comes to new technology and innovation? What will it do for your revenue if customers know for sure they are not going to be able to get next-generation services from your organisation?

Still on the external environment, in some countries, it is quite possible that government mandates and regulations may compel you to take action, either in order to qualify for government contracts or because regulation may indirectly require that you have IPv6. This could come up for example if a regulator defines ‘broadband’ in the national broadband strategy as Internet service that must not be NATted or proxied. Notice that that requirement does not explicitly mention IPv6 but there’s no other way I know of beside IPv6 to meet the requirement. A similar requirement may be imposed to combat cybercrime.

Knowing how your organisation generates value from the Internet, be sure you can describe clearly what factor IP networks and the Internet play in that strategy and now you have a foundation for postulating what the impact to your organisations should that factor grow or decline.

[b] Overview of the problem: IPv4 exhaustion

IPv4 is almost finished! That is always the elephant in the room. Being effective in selling IPv6 upwards will mean that you can frame this problem in terms of the implications for your organisation’s business model. Bottom line is this: a day is coming (and it isn’t in the far far far StarTrek-y future) when you will not have the IP addresses required to connect more staff, branch offices, or make new services available. When that dark day comes, will your organisation be ready? (will it have IPv6 tested and ready to roll) or will it be caught with its pants down? (no IPv6 experience or plans and having to resort to big bang implementations with its associated big risks and expenses.)

[c] Implications of IPv4 exhaustion to your business model

To frame the implications of exhaustion to your business, you must first understand the business model of your organization. In other words, how does you organisation create value and get revenue from it? As already stated in above under ‘understanding the context’, the main ways that organisations derive value from the Internet are as follows:

  • Some aspect of the Internet is at the core of your business model e.g. network equipment vendor, ISP, next generation telecommunications provider.
  • The Internet is a platform on which your organisation conducts business e.g. content provider, e-commerce, e-government, e-banking or online content provider.

With this in mind, some of the implications of exhaustion are as follows:

  1. Loss of future revenue when exhaustion limits the growth of the Internet. (I must note here that exhaustion is also an opportunity for some vendors. They’ll be able to sell you short-term solutions that manage the problem in the short term and gets increasingly more expensive the longer you depend on it). Without more addresses, you will no longer be able to connect more customers nor increase value to existing customers who now have access to higher amounts of and cheaper bandwidth. Even if you are a content provider who will traditionally only need a few addresses for yourself, think of the number of users who have already moved to IPv6 in regions of the world where they don’t have a choice (Asia Pacific) who will be unable to interact with your services and content because those services are only being offered over IPv4.
  2. Revenue retention is no longer guaranteed. A few years down the line when you can no longer grow your client base or serve existing customer with more sophisticated needs, they will switch to any of your competitors who meets their needs.
  3. Without IPv6 operational experience, you might be forced to depend on the kludge that is Network Address and Port Translation (NAPT) and also bring in external consultants to do a big bang (big buck, big risk) implementation late in the game.
  4. Loss of ability to innovate and lead services that will benefit from more addresses and an end to end Internet. This will also cause your organization to fall behind as an innovation and thought leader. A hint here – ‘end-to-end model’ in itself is totally meaningless to most of the executives unless you explain how that enhances the business’s ability for even existing customers to get more out of their current broadband connections (assuming of course we are talking about an ISP.)

[d] Introduction of IPv6 as a solution to IPv4 exhaustion (and why we should care about it)

Having explained the problem (IPv4 address exhaustion) and its implications globally (lid on the continued growth of the Internet) and specifically to your organization (how inability to continue to grow affects your business model), I hope by now your executives are sitting on the edges of the seat, scared for the future. And this is the right time to be a hero and save the day. You now present them with possible solutions viz – Network Address and Port Translation (NAPT) and IPv6. But of course as a network engineer, you know full well that one of those is a pseudo-solution and only IPv6 is a sustainable solution. However, in addition to telling them why IPv6 is the only sustainable solution to the problem, you also owe it to them to explain why NAPT fails to meet the criteria for a sustainable solution.

While NAT has served us well in stemming the need for more addresses, its downsides are well-known and you must spell out to your executives what the consequences of doing NAT are – in terms that they care about. These consequences will run from increased complexity, through loss of the ability to innovate and benefit from innovative new services resulting from and end-to-end Internet to being a dumping ground for legacy technology. Again, keep the geek-talk to the minimum.

And so we care about IPv6 because it is the only way in the long term that we can continue to grow our business, remain technologically relevant and lay a foundation for benefiting from the innovations that will come from an Internet unconstrained by addresses and NAT.

[e] Caution of the risks involved and how to mitigate them

It would not be fair to paint a rosy picture of IPv6 – that only sets unrealistic expectations and sets you up for failure in the future. You management needs to know that you understand that there are risks involved and more importantly that you have some kind of plan for mitigation that risk. That will build your credibility with them even further. There are risks involved either way.

  1. Risk of Inaction: Loss of future revenue, decline in current revenue in the future, falling behind the technological curve etc. Your plan to deal with this is to deploy IPv6
  2. Risk of Action: No, its not a case of “damned if you don’t and damned if you do”. I see it more like “Temporarily crippled if you don’t and certainly dead if you don’t”. The fact is that in IPv6 as a protocol is not yet as mature as IPv4 is. The extent to which that lack of maturity will be a problem will differ from organisation to organisation and may possibly be minimal or non-existent for your organisation. Where there is an impact, it will be felt in the fact that you might not have every single capability that you currently have in IPv4 in IPv6. These could range from the some applications critical to your business that don’t yet have IPv6 support, lack of support in firewalls and security equipment to just new problems posed by the possibility of an end-to-end network with a gargantuan number of IP addresses.

In any case, unless you have set up some kind of test environment (that as must as possible closely represents each of the equipment and applications in your network), you will not know what exactly these risks are. You’ll have to analyze each risk for its impact and propose possible ways of mitigating them. Ultimately, you’ll have to compare these risks with the ultimate risk of inaction and getting left behind.

Although I have often wondered: some of those capabilities you think you need are legacies of an address-scare network design ethic, and if you re-think things, they might not actually be necessary in an IPv6 world.

[f] How much will deploying IPv6 will cost us

Remember, while as a network engineer, you live in the world whose concerns are things like convergence, failover, scalability (arcane words to executives), your executives live in a world whose concerns are revenue, costs and risks. The key cost elements of include:

  • Replacement of devices that will not support IPv6 with a simple software upgrade.
  • Replacing or upgrading software that doesn’t support IPv6.
  • Training to build capacity in IPv6.
  • Possible consultant fees to assist with some aspect of the deployment.

Some of the ways of mitigating these costs include using the organisation’s existing procurement process and equipment cycles to ensure that any and all devices and software acquired supports IPv6 (whether it is going to be used immediately or not). Here is where you make the case for starting now and spreading any costs gradually rather than having to spend a single huge sum if you rush late into the game (the accounting people will love you for this perspective.)

For the training costs, if you are in Africa, you can get the best IPv6 training on the continent free of charge from AFRINIC which organises at least twelve (12) such sessions in different countries each year. Head to learn.afrinic.net to find the one closest to you. (full disclosure: I work for AFRINIC and I am the Training Manager and lead IPv6 Trainer). There are tons of useful learning resources online, from blogs posts to youtube videos to free books. All of these again are more valuable if you do a planned, approach rather than a big bang (big buck big risk) in which you’ll be forced to not just incur large capital expenditure on buying equipment and software, but also on getting consultants (some of whom my colleague says ‘charge by word’) to help with the project and paid training for your staff.

In a nutshell, the biggest way to mitigate costs is to start now, go slow, learn and build experience while leveraging equipment refresh cycles to replace network elements that don’t play nice with IPv6.

[g] Conclusion and call to action

 "Way To Success" by nokhoog_buchachon (freedigitalphotos.net)

“Way To Success” by nokhoog_buchachon (freedigitalphotos.net)

Remember what the CEO asked you? ‘…what our response as an organisation should be’. Up till now you’ve educated them on the problem and its implications as well as shed some light into the solution. Now show that you are a person who Gets Things Done by giving them suggestions towards concrete action to achieve the desired future goal of IPv6 deployment. You need to must tell them what to do. It’s really quite simple and it comes down to ..

  1. Getting your own IPv6 address space now. From your ISP (give them notice if they can’t do this, you won’t be renewing your contract), from your Regional Internet Registry (IPv6 costs you nothing extra if AFRINIC is your RIR). And if you already used resources from AFRINIC (where asking additional IPv6 addresses doesn’t cost you extra), your credibility again shoots up if you already applied for and obtained the block of address space. So tell management that we’ve already taken the first step.
  2. Developing the skills and capability required to deploy IPv6. Ask to attend an IPv6 training for you and your team, put together some spare equipment in an IPv6 lab and start getting some experience.
  3. Aligning internal procurement process. Ask for a review of internal procurement process to be updated so that IPv6 support is a mandatory requirement in devices and applications purchased from now henceforth.
  4. Putting together an IPv6 task force of sorts and start working on an IPv6 Deployment Plan. (See this post about an effective framework for planning an IPv6 deployment). I know some people advice against a dedicated IPv6 task force (because we don’t have an IPv4 task force). I do not agree with that for the following reason: IPv4 is the status quo and the resource allocation process has everyone by default working on some aspect of it. The same is not true of IPv6 and so if you want to stand a chance at succeeding you must have specific resources dedicated to working on it, so there’s a clear line of responsibility and accountability. Whether that’s a dedicated IPv6 task force or creating and assigning IPv6-specific goals to existing operational structure is up to you. In any case … make sure someone has responsibility for something (… otherwise no one will.).

Remember that executives worry about – revenue, costs, risks, business growth and IPv6 has implications for all of them. It is what will ensure future revenue and growth, it will cost money and has risks – the gravity of the costs and risks will depend on whether you start sooner or rush it at the last minute.

Do this as an engineer and your executives will have renewed respect and awe for your insight. It shows that you ‘see the big picture’ and are can think and act strategically and don’t be surprised if you suddenly find the execs coming to pick your brain about some tech issue (IF you get this right!)

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

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.