Thinking Strategically about the Benefits of IPv6

Posted on February 2, 2014 by Mukom Akong Tamon

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?

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

Posted on March 5, 2013 by Mukom Akong Tamon

(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.

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:

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

“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 ..

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

Posted on January 28, 2013 by Mukom Akong Tamon

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.

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.

Beware of IPv6 Transition Techniques as Endgame

Posted on July 18, 2012 by Mukom Akong Tamon

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.

Shifting burden of IPv6 Deployment to transition techniques

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.

Impact of potential resource competition

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

Posted on April 3, 2012 by Mukom Akong Tamon

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)

Definitions

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.

General procedure

[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):

Worked example

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:


1
<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 />

Calculating IPv4 Summary Prefixes

Posted on January 29, 2012 by Mukom Akong Tamon

Given a list of IPv4 prefixes of the same length, how do you find the summary address (or addresses) for them? This post describes a method and uses some worked examples to illustrate. The post draws deeply from the CCIE Routing and Switching Exam Certification Guide by Wendel Odom, with lots additions of mine for clarity as well as some procedures that are not described in the text. I assume that you already understand the standard terminology associated with IPv4 addressing in general.

Definitions

Block (B): Different subnet numbers are multiples of the block (B).
The block for prefix length (P) is given by: $B(P) = 2^{8-P\%8}$ .
The modulo (MOD or %) operation simply finds the remainder of dividing one number by another. We are dividing by 8 here because each octet of an IPv4 address is 8 bits in length.
Inclusive summary address: A summary that includes prefixes outside the range of prefixes you are summarizing.
Exclusive summary address: A summary address (or addresses in some cases) that only includes prefixes within the range you are summarizing.
Interesting Octet: the octet within the IPv4 address in which the prefix length falls. To find this, simply divide the prefix length by 8 and round to the next whole integer.

General procedure

The general procedure to find the exclusive summary address(es) is as follows:

Find the inclusive summary route and use this as the first candidate exclusive address.
Determine the range of addresses of the candidate exclusive address. If it totally encompasses all the component prefixes, then this candidate is the exclusive summary address. If not, split the component candidate address into two with a new prefix length P’ = P + 1
Repeat step #2 for each half of the candidate summary address. As you do this several times, you will eliminate prefixes from the bottom and top of the range till you are left with just the exact prefixes that encompass all the candidate prefixes.

Calculating the inclusive summary route

You should know (from your routing table) or from the problem set in an exam the following information

A list of prefixes to summarize i.e. the component prefixes.
The prefix length of the prefixes (P). This is the same for all component prefixes.

You use the given prefixes to find the inclusive summary route as follows:

Let the number of component prefixes be ‘s’
The number of bits required to give ‘s’ prefixes is given by ‘y’ where: $2^{y}$ ≧ s (take the next whole integer)
Calculate a new prefix length P’ = P – y
Calculate S0 – the subnet number when you take the lowest numeric subnet (e.g 192.168.20.0 is less than 192.168.25.0) in the list as an IP address with prefix length P’.
Calculate S1 – the subnet number when you take the highest numeric subnet in the list as an IP address with prefix length P’
If S0=S1 then this is the best summary route.
If S0≠S1, then repeat steps #4 and #5 with a new (shorter) prefix length P’= P’ – 1

Calculating the exclusive summary route

Find the inclusive summary prefix and use it as a candidate exclusive summary prefix
Determine the range of the candidate summary, if all candidates prefixes fall within the range, then this is the exclusive summary prefix and you are done.
If the range of the candidate prefixes includes prefixes outside the component prefixes, split the candidate into two parts with length P’ = P +1 and repeat step #2 with each half.

How to split a prefix into two parts

Find the new prefix length: P’ = P + 1
Calculate the block that corresponds to this new prefix length B(P’)
First part = candidate prefix
Second part = candidate prefix + B(P’) on the interesting subnet

Worked Example #1 : Inclusive summary route

Find the inclusive summary prefix for: 172.31.20.0/24, 172.31.21.0/24, 172.31.22.0/24, 172.31.23.0/24

Number of prefixes s = 4
Prefix length of components P = 24
Bits required y: 2^y >= s => 2^y >=4 thus y = 2
New prefix length P’ = P – y = 24 – 2 = 22

Taking smallest component prefix as an address with new prefix length, we have 172.31.20.0/22

Block B(22) = 2^(8-22%8) = 2^2 = 4
Thus subnet number are multiples of 4 i.e. 4 , 8 , 12, 16, 20 , 24, etc
Interesting octet is 3rd octet (22/8 = 2R6 = 3)
This address belongs to subnet 172.31.20.0/22 = S0

Taking the highest component prefix as an address with new length, we have 172.31.23.0/22

Block B(22) = 2^(8-23%8) = 2^2 = 4
Thus subnet number are multiples of 4 i.e. 4 , 8 , 12, 16, 20 , 24, etc
Interesting octet is 3rd octet (22/8 = 2R6 = 3)
This address belongs to subnet 172.31.20.0/22 = S1

S0 = S1 thus the inclusive summary prefix is 172.31.20.0/22

Worked Example #2 : exclusive summary route

Find the exclusive summary of 172.31.20.0/24, 172.31.21.0/24, 172.31.22.0/24, 172.31.23.0/24 ,172.31.24.0/24

We start of by finding the inclusive summary prefix first and using it as a candidate exclusive summary prefix.

Number of prefixes s = 5
Prefix length of components P = 24
Bits required y: 2^y >= s => 2^y >=5 thus y = 3
New prefix length P’ = P – y = 24 – 3 = 21
Block B(21) = 2^(8-21%8) = 2^3 = 8
Thus subnet number are multiples of 8 i.e. 8 , 16 , 24, 32 etc
Interesting octet is 3rd octet (21/8 = 2R5 = 3)

Taking smallest component prefix as an address with new prefix length, we have 172.31.20.0/21 which belongs to subnet 172.31.16.0/21 = S0

Taking the highest component prefix as an address with new length, we have 172.31.24.0/21, which belongs to subnet 172.31.24.0/21 = S1

S0 ≠ S1 we repeat with prefix length decremented by 1

New prefix length P’ = P’ – 1 = 21 – 1 = 20
Block B(20) = 2^(8-20%8) = 2^4 = 16
Thus subnet number are multiples of 16 , 32 , 48 etc
Interesting octet is 3rd octet (20/8 = 2R4 = 3)

Taking smallest component prefix as an address with new prefix length, we have 172.31.20.0/20 which belongs to subnet 172.31.16.0/20 = S0

Taking the highest component prefix as an address with new length, we have 172.31.24.0/20 which belongs to subnet 172.31.16.0/20 = S1

S0 = S1 = 172.31.16.0/20 is the inclusive summary prefix

Now that we have the inclusive summary prefix, we can proceed to find the exclusive prefix using this as our first candidate.

First we establish the range of 172.31.16.0/20

We know block is B(20) = 16 and the third octet is the interesting one
The next subnet higher than 172.31.16.0/20 is 172.31.32.0/20
Therefore range of 172.31.16.0/20 is 172.31.16.1 – 172.31.31.255 (this being the last address before 172.31.32.0/20)
This range includes more prefixes than are in the component list (e.g .16.0/24 and .28.0/24)

We split 172.31.16.0/20 into two parts

New prefix length P’= P’ + 1 = 20 + 1 = 21
B(21) = 8
Thus 172.31.16.0/20 = 172.31.16.0/21 & 172.31.24.0/21

Split #1	172.31.16.0/21	172.31.24.0/21
Range	172.31.[16.1 – 23.255]	172.31.[24.1 – 31.255]
Comments	Includes .16.0/24 so we’ll need to split this again	Only 24.0/24 is within range Thus 172.31.24.0/24 is one of the exclusive summary prefixes

Note: We use the block (B) to determine the component subnets and thus know what prefixes are included that shouldn’t be.

We split 172.31.16.0/21 into two parts

New prefix length P’= P’ + 1 = 21 + 1 = 22
B(22) = 4
Thus 172.31.16.0/21 = 172.31.16.0/22 & 172.31.20.0/22

Split #1	172.31.16.0/22	72.31.20.0/22
Range	172.31.[16.1 – 19.255]	172.31.[20.1 – 23.255]
Comments	Totally out of range, so we discard this	Includes the remaining component prefixes apart from .24.0/24

Therefore, the exclusive summary prefixes for 172.31.[20-24].0/24 are 172.31.20.0/22 AND 172.31.24.0/24

Worked Example #3 : Exclusive summary route

Find the exclusive summary prefix for 10.22.12.0/23, 10.22.14.0/23, 10.22.16.0/23 10.22.18.0/23

We start of by finding the inclusive summary prefix first and using it as a candidate exclusive summary prefix.

Number of prefixes s = 4
Prefix length of components P = 23
Bits required y: 2^y >= s => 2^y >=4 thus y = 2
New prefix length P’ = P – y = 23 – 2 = 21
Block B(21) = 2^(8-21%8) = 2^3 = 8
Thus subnet number are multiples of 8 i.e. 8 , 16 , 24, 32 etc
Interesting octet is 3rd octet (21/8 = 2R5 = 3)

Taking smallest component prefix as an address with new prefix length, we have 10.22.12.0/21 which belongs to subnet 10.22.8.0/21 = S0

Taking the highest component prefix as an address with new length, we have 10.22.18.0/21 which belongs to subnet 10.22.16.0/21 = S1

S0 ≠ S1 we repeat with prefix length decremented by 1

New prefix length P’ = P’ – 1 = 21 – 1 = 20
Block B(20) = 2^(8-20%8) = 2^4 = 16
Thus subnet number are multiples of 16 , 32 , 48 etc
Interesting octet is 3rd octet (20/8 = 2R4 = 3)

Taking smallest component prefix as an address with new prefix length, we have 10.22.12.0/20 which belongs to subnet 10.22.0.0.0/20 = S0

Taking the highest component prefix as an address with new length, we have 10.22.18.0/20 which belongs to subnet 10.22.16.0.0/20 = S1

Still, S0 ≠ S1 we repeat with prefix length decremented by 1

New prefix length P’ = P’ – 1 = 20 – 1 = 19
Block B(19) = 2^(8-19%8) = 2^4 = 32
Thus subnet number are multiples of 32 , 64, etc
Interesting octet is 3rd octet (19/8 = 2R4 = 3)

Taking smallest component prefix as an address with new prefix length, we have 10.22.12.0/19 which belongs to subnet 10.22.0.0.0/19 = S0

Taking the highest component prefix as an address with new length, we have 10.22.18.0/19 which belongs to subnet 10.22.0.0.0/20 = S1

S0 = S1 = 10.22.0.0/19 is the inclusive summary prefix

Now that we have the inclusive summary prefix, we can proceed to find the exclusive prefix using this as our first candidate.

First we establish the range of 10.22.0.0/19

We know block is B(19) = 32 and the third octet is the interesting one
The next subnet higher than 10.22.0.0/19 is 10.22.32.0/19
Therefore range of 10.22.0.0/19 is 10.22.0.1 – 10.22.31.255 (this being the last address before 10.22.32.0/19)
This range obviously includes more prefixes than are in the component list so we split it

We split 10.22.0.0/19 into two parts

New prefix length P’ = P’ + 1 = 19 + 1 = 20
B(20) = 16
Thus 10.22.0.0/19 —> 10.22.0.0/20 & 10.22.16.0/20

Split #1	10.22.0.0/20	10.22.16.0/20
Range	10.22.[0.1 – 15.255]	10.22.[16.1 – 31.255]
Comments	Includes ranges below 10.22.12.0/24	Includes ranges above 10.22.18.0/24 We’ll need to split this to trim the range from above

We split 10.22.0.0/20 into two parts

New prefix length P’= P’ + 1 = 20 + 1 = 21
B(21) = 8
Thus 10.22.0.0/20 –> 10.22.0.0/21 & 10.22.8.0/21

Split #2	10.22.0.0/21	10.22.8.0/21
Range	10.22.[0.1 – 7.255]	10.22.[8.1 – 15.255]
Comments	Totally out of range	Includes the .12.0, 14.0 and 16.0 prefixes Still includes the prefixes below .12.0 and so needs to be split this prefix to trim it from the bottom

We split 10.22.8.0/21 into two parts

New prefix length P’= P’ + 1 = 21 + 1 = 22
B(22) = 4
Thus 10.22.8.0/21 –> 10.22.8.0/22 & 10.22.12.0/22

Split #3	10.22.8.0/22	10.22.12.0/22
Range	10.22.[8.1 – 11.255]	10.22.[12.1 – 15.255]
Comments	Totally out of range	Contains the .12, .14 prefixes and nothing else

We split 10.22.16.0/20 from split #1 into two parts

New prefix length P’= P’ + 1 = 20 + 1 = 21
B(21) = 8
Thus 10.22.16.0/20 –> 10.22.16.0/21 & 10.22.24.0/21

Split #4	10.22.16.0/21	10.22.24.0/21
Range	10.22.[16.1 – 23.255]	10.22.[24.1 – 31.255]
Comments	Contains .16.0 and .18.0 but also .20 which we don’t want Split this again	Totally out of range – discard

We split 10.22.16.0/21 from split #4 into two parts

New prefix length P’= P’ + 1 = 21 + 1 = 22
B(22) = 4
Thus 10.22.16.0/21 –> 10.22.16.0/22 & 10.22.20.0/22

Split #5	10.22.16.0/22	10.22.20.0/22
Range	10.22.[16.1 – 19.255]	10.22.[20.1 – 23.255]
Comments	Contains only .16.0 and .18.0	Totally out of range – discard

Therefore, the exclusive summary prefixes for 10.22.[12, 14 , 16, 18].0 /23 are 10.22.12.0/22 AND 10.22.16.0/22

Conclusion

Be aware that when you summarize to certain prefix lengths, some operators might not accept them. Inefficient summary routes lead to bigger BGP tables.
Most ISPs and Regional Internet Registries (RIRs) will allocate you address space along boundaries that can easily be summarized neatly
The Block (B) will always increase in the progression: 2 , 4, 8, 16 , 32 , 64 , 128

Debunking the IPv6 Has More Security and QoS Myths

Posted on May 16, 2011 by Mukom Akong Tamon

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.

IPv4 and IPv6 Headers Compared

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?

IPv6 Subnetting Made Easy

Posted on May 9, 2011 by Mukom Akong Tamon

Introduction

Call it emotional attachment to IPv4 or whatever you like, but recently I have become more and more interested in finding and easy way to subnet IPv6 prefixes in my head like we are used to doing in IPv4. This post expands on an idea I picked off of the NANOG mailing list.

The method presented here is for the quick subnetting in your head, which you should get by practice. So it works well for a small number of subnets (16 max) but can be expanded for any number of subnets. However if you have to deal with more than 16 subnets, it is certainly more efficient to use any of the several IPv6 calculators out there (my favourite is sipcalc – a command line tool).

This method helps you answer the question: “Given the prefix PPPP/Y, what are the sub-prefixes of length /Z (where Z > Y) that can be gotten from it?“

I assume that you understand the fundamentals of IPv6 addressing, very basic binary and hex math. I also assume that you know how to arrive at the value Z from an analysis of your network design or requirements.

Definitions

Hexit – a single hexadecimal digit (0 – 9 , a – e). A hexit is made up of 4 bits.
Hex grouping – each of the groups of hexits of an IPv6 address that are separated by colons.
Defining hexit – the hexits that change for each subnet but stays the same for the same subnet. Think ‘interesting octet’ from IPv4 subnetting days. You could simply look it up from the following table.

The bit ranges that define various IPv6 hexits

Parent prefix – the original prefix to be subnetted in prefix/length format.
Y = prefix length of original prefix
Z = prefix length of subnets of original prefix

The Procedure

Calculate the following parameters

Number of subnetting bits: x = Z – Y
Number of subnets possible with x bits: S = 2^x
Number of hexits represented by the x bits: h = x/4 (this should be rounded up to the next integer)

For a given number of subnet bits (x), the defining hexit for each subnet will increase in value according to the increment, from hexadecimal zero (0) to “e” as shown in the table below. Note that the ‘definining’ hexit(s) is simply the one after the boundary hexit (that defined by original prefix length Y.

IPv6 Quick Subnetting Cheatsheet

Examples

[a] Subnet 2001:db8::/32 into /36s

Subnetting bits (x) = 36 – 32 = 4 (these will give us 16 [i.e. 2^4] subnets.
Number of hexits represented by 4 bits = 4/4 = 1
From the table, the defining hexit should increment by 1 with discrete hex values 0 – f.
Thus our subnets are:

2001:db8:0000::/36
2001:db8:1000::/36
2001:db8:2000::/36
2001:db8:3000::/36
2001:db8:4000::/36
2001:db8:5000::/36
2001:db8:6000::/36
2001:db8:7000::/36
2001:db8:8000::/36
2001:db8:9000::/36
2001:db8:a000::/36
2001:db8:b000::/36
2001:db8:c000::/36
2001:db8:d000::/36
2001:db8:e000::/36
2001:db8:f000::/36

[b] As a small end site, you received the 2001:db8:c001:ba00::/56 assignment from your ISP, and you have 3 main office locations you want to divide this block between. Find these 3 subnets.

Number of subnets required = 3
Subnetting bits (x) such that (2^x) >=3 , x = 2 (this will actually give us 4 subnets of equal prefix length). Also the prefix length of our subnets will be 58 (56+2)
Number of hexits represented by 2 bits = 1
From the table, the defining hexit should increment by 4 with discrete hex values 0, 4, 8, c.
Thus our subnets are:

2001:db8:c001:ba00::/58
2001:db8:c001:ba40::/58
2001:db8:c001:ba80::/58
2001:db8:c001:bac0::/58

Please drop me a comment if you have suggestions of how to make this even easier and happy v6 subnetting …in your head. If you would like a highly detailed and complete method for IPv6 subnetting, let me invite you to read my other post “IPv6 Subnetting – General Procedure“

Saving Router Configurations Across GNS3 Sessions

Posted on December 30, 2008 by Mukom Akong Tamon

For those who use GNS3 to emulate Cisco networks, sooner you get to a point where you would love to save the configuration and pick off from where you left. Uptill recently, I used the crude method of exporting my configuration files and then manually setting them as the startup config for each router. I however found a better way of recent … just save your lab as a GNS3 Project. Here is the procedure:
1. Lay out your lab: U know, place devices, connect them, configure switches and even default router configs (if you have a default config you typically use eg aliases, idlepcs and logging synchronous)
2. Run your lab (click Start/Resume all IOS)
3. Telnet into each of the routers and configure it to your heart´s desire. Make sure you do a copy run start or a write terminal after you finish configuring each router.
4. With your lab still running, switch back to the GNS3 window and click File->New Project. Type in a name for the project and be sure to check the ¨Export router configuration files¨ option.

5. Click Ok and GNS3 will ask whether you want to apply the project settings to which you say yes.
6. GNS3 will extract the config from your routers and save them for you and automatically set them as startup config for the next time.
If you look in the directory where you saved the project, you will find that GNS3 creates the following:

A project file eg lab.net
A directory to store config files with the same name as the .net file of your project eg lab01_configs. In it you will find files with the name of your routers and the .cfg extension eg (R1.cfg, R2.cfg etc)
If you selected the option in the New Project dialog box, a working directory folder is also created eg lab01_working.

Next time, you can just open your lab, launch right in and start having fun.

	Melvina on Dumping Ntop Data
	weight loss on Calculating IPv4 Summary …
	Lieselotte on Dumping Ntop Data
	Francesco on IPv6 Subnetting Made Easy
	tkudcz@gmail.com on How to ‘Sell’ IPv6…