- 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.
Category Archives: IPv6
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):
- Set the strategic context: how your organisation derives value from IP networks and the Internet.
- Overview of the problem: IPv4 exhaustion.
- Implications of IPv4 Exhaustion to your organization’s business model.
- Introduction of IPv6 as a solution to IPv4 exhaustion.
- Understanding the risks involved.
- How much will deploying IPv6 will cost.
- 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.
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:
- 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.
- 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.
- 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.
- 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.
- 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
- 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
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 ..
- 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.
- 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.
- 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.
- 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:
- Define clearly what you want to achieve – the goals.
- Identify the list of tasks you will need to achieve each goal.
- For each task, identify what resources you will need – people, finances and time
- Get management sign-off/approval for the project
- Start executing the project – aka Deploying IPv6
- 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:
- Perform audit of the web server infrastructure to ensure it can support IPv6.
- Address any recommendations from the audit above.
- Review security policy relating to the web services and update to cover IPv6.
- Create AAAA records in DNS infrastructure for the web server.
- Configure IPv6 addresses on the web server.
- Configure IPv6 addresses on load balancers (if applicable).
- Configure the web server software to accept and server requests over IPv6.
- Establish a test plan for this deliverable.
- Test the web server against the test plan.
- Launch the service.
- 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.
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.
Beware of IPv6 Transition Techniques as Endgame
By now, even the non-technical folks out there are aware of IPv4 address exhaustion (The IPocalype), thanks to the problem finally coming into the consciousness of the mainstream media. As organizations plan how to deal with this exhaustion, those who do the right thing and choose to deploy IPv6 (instead of trying to teach the IPv4 elephant how to dance using NAT) at some point are likely to choose and deploy one or more transition techniques. These are mechanisms that are supposed to smoothen the migration from IPv4 to IPv6… or will they? They certainly have the potential to do so (smoothen the transition), but network architects must make sure that these transition techniques don’t end up as the seeds of a new problem by becoming ends in themselves rather than a means to an end (full native IPv6).
Failure in transition techniques do and will result in a backlash from users that give the end-game (IPv6) a bad reputation (when you hear comments like “IPv6 is not yet operational”, “It doesn’t work” in various forums, look close by and you’ll find a bad IPv6 experience lurking not far away).
My focus on this post is to caution us that the general human tendency to focus on the short term, look for quick-fix solutions, combined with the reluctance to change could turn these well-meaning transition techniques into obstacles to full blown native IPv6 deployment. There is a precedent for this kind of thing happening – Network Address Translation (NAT) and it’s sibling Network Address and Port Translation (NAPT). In response to the impending issue of IPv4 shortage in the early 1990s, Egevang and Francis proposed NAT as a solution (see RFC 1631). The authors of NAT were well aware of the dangers I am highlighting here, hence their warning:
“NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution.” – K. Egevang and P. Francis – RFC 1631
Looking at where we stand today, network engineers ignored that warning and today NAT is so ingrained in the thought processes of network engineers that it (in its various forms) is being pitched as an alternative to implementing IPv6 despite various documentation that the NAT-path isn’t the way to sustainable Internet growth and innovation.
The problem in this scenario was (and still is) “IPv4 Depletion”, and the two solutions are IPv6 (the fundamental solution – addresses the root cause) and NAT (the symptomatic solution – addresses the symptoms only). The symptomatic solution was supposed to be used temporarily to buy us time while we implemented the fundamental one. But we now know that the success of NAT is the a key reason that IPv4 lived longer than it was supposed to, which in turn kept IPv6 stagnant for about 20 years after being standardized.
This pattern of events fits perfectly the “Shifting the Burden” archetype in Systems Thinking which is described thus in the “The 5th Discipline” by Peter Senge
“A short term solution is used to correct a problem, with seemingly positive immediate results. As this correction is used more and more, more fundamental long term corrective measures are used less and less. Over time, the capabilities of the fundamental solution may atrophy or become disabled, leading to even greater reliance on the symptomatic solution“
An early warning symptom that you are dealing with this pattern of events can be spotted in statements like:
“Look here, this solution has worked so far, what do you mean there is trouble down the road?”
Here is a diagram of the “Shifting the Burden” model adapted to the IPv4, IPv6 context.
Does this pattern of events look/sound familiar? … that’s because it is. As we have relied on NAPT more and more, fewer organisations have thought about implementing IPv6, some of the inertia simply based on the huge investments (financial, emotional and intellectual) that have been made in IPv4 and NAPT. When folks complain of the lack of feature parity of IPv4 with IPv6, they often fail to see that the said lack of feature parity is a direct consequence of the fact that they have not deployed and tested IPv6 to build operational competence with it. IPv4 did not mature overnight, it was through progressive use, improvements, feedback and re-use that it got it’s rich feature set. The end game of falling into this kind of thinking is that we will at some point end up with a system that is stuck at a mediocre level of performance (think sub-par IPv6 and all the problems that result when NAPT is over-used).
I make the case that all the current transition techniques we currently have are different variations of that sub-par system that we might end up in. Of course, some clueful folks will tell me there are no performance issues with some transition techniques, but I think there’s a reason we call them ‘transition’ techniques – they are a move towards an end-game, not the end-game itself.
The vicious cycle is perpetuated further by another occurrence: as the transition technique starts to work ‘better’ than broken implementations of native IPv6, organizations invest more resources in it to optimize it better, all of this investment happens at the expense of native IPv6 deployment which further makes the later less attractive while increasing the financial and emotional investments in the transition technique. This is a classic “Success to the successful” archetype in Systems Thinking which is illustrated below.
So what can we do? (apart from building a time machine, going back to 1994, nipping NAT in the bud and directing all efforts into IPv6!). Here are a few ideas:
- All IPv6 deployment plans should have as their objective native IPv6, any transition techniques deployed should be milestones to that end game. So project managers and CIOs, look out for that and demand it from suppliers, vendors and contractors and from your network engineers.
- Leverage normal equipment and software refresh cycles to ensure that network and application elements support native IPv6. This builds end-game capability in existing systems, thus making sure that transition mechanisms will progressively not be needed.
- Educators and trainers must continue to inform the world of the sub-optimal solution that non-native IPv6 is.
More importantly, I will like to know your suggestions and strategies for making sure this doesn’t happen or even if you think it’s a problem t beware of.
IPv6 Subnetting – General Procedure
First off, because I know most of us are coming from the IPv4 world, I want to state a couple of things from IPv4 subnetting that we must UNLEARN and forget in order to grasp IPv6 subnetting.
- Why we subnet: In IPv4, we usually subnet to conserve addresses (“I can’t waste an entire /24 on a point to point link”). In IPv6 we subnet to optimize our network either for security (“I want all Finance department devices to be on their own subnet”, so we can write simple ACLs for accessing that subnet) or routing (“I want everyone on the same floor or a portion of it to be in the same subnet” – so we can have a single route entry for an entire floor or building thus keeping out routing tables small). Address conservation is not factor in IPv6 subnetting – if you allocate /64s to all your LANs, there’ll always be enough host addresses per subnet.
- There is no VLSM, only SLSM: To conserve addresses in IPv4, we use variable length subnet masking (VLSM) – so we’d take a prefix, cut it up and give /30s to point to point links, /25s to small LANs etc. In IPv6, again we don’t need to conserve space, so we assign and use the same prefix lengths (the IPv6 equivalent of a subnet mask) – this will be what we know in the IPv4 world as “same length subnet masking” (SLSM)
- Think in terms of subnets and not hosts: Again as we are using /64 subnets, we have enough addresses for hosts so we never really need to calculate the “number of hosts per subnet”. In IPv6 subnetting, we are concerned mostly about the number of subnets.
The general IPv6 subnetting problem has the following variations:
- Given a specific prefix of length l, how many sub-prefixes of length l’ are there in the given prefix? and what are these prefixes?
- Given a specific prefix of length l, you are required to break it up to fit a certain number of networks (N)
- Mother prefix: this is the prefix that you are going to subnet. It’s prefix length is L. You would get this from the problem set or in practice, as the prefix allocated to you by the RIR or your ISP.
- Sub-prefixes: these are the component prefixes that you get from subnetting the mother prefix. They have a prefix length (designated L’) such that L’ > L always. We find the sub-prefix lengths (L’) either directly (e.g. how many /52s are there in the /48 that I got from my ISP?) or from the situation we are facing (I have this /32 prefix that I need to divide equally amongst 700 POPs)
- Subnet bits (s): in each variation of the IPv6 subnetting problem, you will need to find the number of bits of subnetting needed to give either the sub-prefix length or the number of subnets required.
- Hexit: a single hexadecimal character (0 – 9 , a – f). A hexit is four bit or a nibble.
[a] Find the number of subnet bits
- Given both the mother-prefix length and the subnet prefix lengths, then s = L’ – L
- Given the number of subnets (N), calculate s from the formular 2^s >= N
- Mathematically, s = log N / log 2 (the answer is rounded up to the next integer)
[b] Find the number of subnet (or interesting) hexits
- A hexit is a single hexadecimal character and the subnet hexits are those that will change for each of sub-prefixes.
- Knowing that 1 hexit = 4 bit and having found the number of bits required then
- Number of subnet hexits = s/4 (round it up to the next integer)
- Note: If s/4 is an integer, then it means that the hex values for each of the hexits for the last subnet will be “F”.
- If s/4 leaves a remainder, then the rightmost hexit will not end in something other than an “F”.
- For simplicity in subnetting and address planning, it is recommended to always work with nibble boundaries (multiples of 4) so that we have clean hexit boundaries.
[c] Find the ‘Increment’ or ‘Block’
This is a constant which is the numerical difference between each of the subnet numbers. Progressive ‘subnet hexits’ are multiples of the ‘Increment’ or ‘Block’
The block B = 2^(16 – L’%16) – the modulo operation % simply takes the remainder and ignores the quotient of the division
[d] Enumerate the subnetIDs
Knowing your subnet prefix length, subnet hexits and block, your subnet IDs form a simple arithmetic progression with initial term 0 and common ratio = Increment
Generally the nth term of an arithmetic progression is: a(n) = a(0) + (n-1)d
Starting from the zeroth subnet i.e. a(0) = 0000 then we have a(n) = (n-1)d
Specifically, to find the last subnetID
- First find the total number of possible subnets: S = 2^s
- Last subnetID = a(S) = (S-1)d
- IMPORTANT! The result above is in decimal so we must convert the result to hex. We an also convert S and d to hex and then work directly in hex.
Our subnets then will be of the general form – mother:prefix:subnetID::/L’
It is really that simple but “the devil” as they say, “is in the details”. So let’s go search for the devil with an example (and hope he doesn’t demand our souls for the honour):
Given the prefix 2001:db8::/32, we need to carve it into 900 sub-prefixes.
This problem gives us the number of required subnets so we’ll have to find the subnet bits. The simpler variation is when we are given the subnet prefix length.
Step #1: Finding the number subnet bits (s) are required
2^s >= 900. So s = (lg 900) / (lg 2) = 10 (rounded up to the nearest integer)
Thus in order to get 900 sub-prefixes, we need at least 10 bits of subnetting. (In fact 10 bits will give us 1024 (2^10) networks but 9 bits will give us 512 which doesn’t meet our requirement)
Now, 10 bits of subnetting means that the sub-prefixes will have a length (L’) of 32 + 10 = 42
Step #2: Finding the number of ‘Subnet Hexits’
Knowing that we need to do 10 bits of subnetting and 4 bits = 1 hexit, then
Therefore 10bits give us 10/4 = 2.5 hexits. We round this to 3 hexits.
The fraction simply means that hexit will vary from 0 and not get through to the top of the hex range i.e. ‘f’
Thus our sub-prefixes will be of the form: 2001:db8:HHH0::/42 (the first two ‘H’s going from 0 – f and the last one ending at some yet-to-be determined value). Again this is another reason to work with nibble (4 bit) boundaries, we avoid all this ‘mess’ and all hexits will change cleanly from 0, 1, 2, 3, 4 … up to f.
Step #3: Finding the Increment (or Block B)
B = 2^(16 – L’%16) = 2^(16 – 42%16) = 2^(16-10) = 2^6 = 64
The hexadecimal equivalent of 64 is 0x40
Step #4: Enumerating the subnetIDs
The general subnetID is given by either one of the following:
- subnetID(n) = 64(n-1) [decimal – so we must convert the final result to hex ]
- subnetID(n’) = 40(n’-1) [where n’ = hex equivalent of n]
Particularly, we want to find the subnetID of the last subnet (we would not need to do this if the subnet prefix fell on a nibble boundry), of which we know there are 1024 (since we calculated that we needed 10 bits to satisfy the design requirement)
So the 1024th subnetID is:
a(1024) = 64(1024 – 1) = 64(1024-1) = 1023(64) = 65472 which in hex is ffc0.
Alternatively, working in hex and knowing that 1024 = 0x400, we could also have
a(400) = 40(400-1) = 3ff(40) = ffc0
So then our last subnetID is : 2001:db8::/42 to 2001:db8:ffc0::/42
We can also find any arbitrary nth subnetID e.g the 243rd one:
a(243) = (243-1)x64 = 242 x 64 = 15488 = 0x3C80 which gives us prefix 2001:db8:3c80::/42 or in hex
a(f3) = 40(f3-1) = 40(f2) = 3C80 which gives us the same answer. [knowing that 243 = 0xf3]
Conclusion and getting real
While I enjoy the intellectual stimulation of knowing how to work this out, I think network engineers should use a good tool to do subnetting in IPv6 after understanding the basics. For a quick technique for doing subnetting of up to 16 subnets in your head, read this post. For anything more complicated, I’d resort to the myriad of tools out there. Apart from the “TheMaskU” iPad app which is really useful, my favorite and preferred is the open source sipcalc. To use these tools well, you need to understand how to find the number of subnet bits and derive the sub-prefix length from it. Our example in sipcalc will be solved as follows:
<br />$ sipcalc 2001:db8::/32 --v6split=42 | more<br />-[ipv6 : 2001:db8::/32] - 0<br /><br />[Split network]<br />Network - 2001:0db8:0000:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:003f:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:0040:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:007f:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:0080:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:00bf:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:00c0:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:00ff:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:0100:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:013f:ffff:ffff:ffff:ffff:ffff<br /><br />Network - 2001:0db8:fc80:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:fcbf:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:fcc0:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:fcff:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:fd00:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:fd3f:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:fd40:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:fd7f:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:fd80:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:fdbf:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:fdc0:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:fdff:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:fe00:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:fe3f:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:fe40:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:fe7f:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:fe80:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:febf:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:fec0:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:feff:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:ff00:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:ff3f:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:ff40:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:ff7f:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:ff80:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:ffbf:ffff:ffff:ffff:ffff:ffff<br />Network - 2001:0db8:ffc0:0000:0000:0000:0000:0000 -<br /><%%KEEPWHITESPACE%%> 2001:0db8:ffff:ffff:ffff:ffff:ffff:ffff<br /><br />
Debunking the IPv6 Has More Security and QoS Myths
I thought that in the year 2011 …when the we’ve had so much talk about IPv6, lots of the smoke about what IPv6 is capable of and what it isn’t capable of would have cleared. Unfortunately not. Today I read this piece from CNET and I went “really? in this age, some major tech website still writes this kind of thing?”. Here are some of the claims they make about the new IPv6 ready DLink routers:
[a] “Enhanced network security: Plug in an IPv6-enabled D-Link router and the new security feature is automatically turned on.”
Exactly what new security feature are we talking about here? Just to clarify what has been done several times allover the web, even though implementation of IPsec is mandatory for IPv6, its usage is NOT and so IPv6 does not yield any new security benefits over IPv4. In fact, poorly managed, IPv6 is a security risk as it could completely bybass all that air-tight security you did for IPv4 on your network edge.
[b] “Increased network speeds and accessibility: As Web sites start to offer content over IPv6 and ISPs deploy IPv6 service, an IPv6-compliant router offers faster connection speeds and provides access to Web sites and applications that have transitioned. With its better design, IPv6 has integrated quality of service, so traffic is classified by voice, video, and data, and transported accordingly, resulting in faster network speeds.”
Puff!!!! Again, IPv6 doesn’t currently offer anything in QoS that IPv4 does not. And sorry to break it to you, but your connection speed is still going to depend upon how much bandwidth you have and not the IP version you are using.
To understand the source of this myth, look at the figure below which show the IPv4 header next to an IPv6 one. With respect to QoS, notice that:
- The field responsible for QoS (specifically enables a packet to be marked for special treatment) in IPv4 was “ToS” ie Type of Service. This field is 8 bits long. In v6, the field was renamed to the more appropriate “Traffic Class” but same size and brings nothing new.
- In IPv6, there is one new field … the “Flow Label” which is the source of this myth. The flow label in theory is meant to identify upper layer flows so that a router can identify upper layer flows without having to look beyong layer 3 (which could be time-consuming and slower). In reality, that field’s usage has not been defined and so it is currently unused. Therefore …right now, IPv6 offers nothing new to QoS that IPv4, thus making the assertion that IPv6 is faster false.
Even I used to propagate these myths which are based off of the original intentions of the IPv6 designers …but as time has gone on, we must do a reality check …the major benefit of IPv6 today is more address space and with that …maybe a return to the original end-to-end model of the Internet. Who know what cool innovations will result from that?