In my previous posts I went over details for the first phase of your IPv6 adoption plan, the assessment and the second phase, training. You can find the original post that covers the overall topic about IPv6 adoption here. In this post, I wanted to tackle the third phase in the overall adoption plan, planning and design.
Planning and design are challenging for many organizations for a variety of reasons. The challenges are:
· First, unless you have had training to build fundamental skills around IPv6 you will likely have difficulty making good design decisions.
· Second, if you have not been through a full IPv6 design and deployment you likely will not have a full understanding of impacts. Thus, a plan will be hard to establish.
· Third, defining the scope of the IPv6 adoption plan will dictate the type of planning and design work you will need to do.
Given a specific mandate to adopt IPv6, what top level planning items should you anticipate? I think many project managers think IPv6 should be treated as a special project in order to get it implemented. This may make sense in certain key technical areas within a company but for IPv6 adoption overall I believe that that method leads to the never-completed IPv6 project that spans multiple years and frustrates a lot of people. So how should a company tackle getting an IPv6 plan going?
An IPv6 plan should be built for each key technology pillar (or silo) within a given company. For instance, many companies today have key teams in their IT department that are responsible for:
· Network – routers, switches, wireless, load balancing, DHCP, DNS, IPAM, Internet peering, routing policies
· Security – firewalls, IDS/IPS, logging, identity management
· Systems and Virtualization – Host servers, applications, guest OS’s, DNS, DHCP, IPAM, logging, identity management, client OS’s
· Storage – SAN, file protocols, file services, backup and recovery
· Database – SQL, big data, Hadoop, R or other data analysis processes
· Line of business applications – CRM, HR, Financials, or any customer applications developed by the company itself
As with all things technology related, things change and the next generation of teams and roles is developing around a more DevOps-centric model. This changes the roles of some of the classic pillars but the skill sets are still the same. You might have to do more scripting, coding, testing, and perhaps use new tools but your primary skill sets are still relevant in this new landscape.
So an analysis of how an IPv6 adoption plan is likely to impact each of the pillars will help you come up with a comprehensive plan. Planning is about knowing what you want to accomplish, putting down on paper the specific tasks to reach that goal and then putting dates and an execution plan together. For a successful IPv6 plan to come together, each of the pillars I mentioned above needs to have a specific plan of attack on how they are going to support IPv6 and get it rolled out. An overall plan for a company would simply show where each team is in their particular objectives.
Granted, there are some teams who have to get things done before others can start their work. Often, the first team mentioned to get IPv6 going is the network team. But before you can start all this work to get IPv6 implemented you will need a design; i.e., something you can refer to that tells you how to get something done. Creating a design to deploy IPv6 becomes the first task in your overall IPv6 adoption plan.
Good design is an art form that few have mastered in the IPv6 world. Those who have mastered it are in a small club and are often difficult to find and hire to work on your specific IPv6 project. So how do you get good IPv6 design guidance? How do you overcome the deficit that exists today in obtaining talented IPv6 practitioners? By reading. Many teams can still do an adequate job on IPv6 design and correct as they learn more about the protocol without detrimental effect. You can learn about IPv6 address design and planning by reading Tom Coffeen’s excellent IPv6 Address Planning book from O’Reilly Media. You can learn about impacts of securing your network by reading IPv6 Security by Scott Hogg and Eric Vyncke from Cisco Press. And if you need to learn about overall enterprise network design read IPv6 in the Enterprise Network by Shannon McFarland and co-authors from Cisco Press. [IMO, Ed’s being entirely too modest here. Chances are probably approaching 100% that you have one or more flavors of Microsoft Windows in your infrastructure. In that case, Ed’s book Practical IPv6 for Windows Administrators (Apress, 2013) is an indispensible resource. -Tom] All of these books will help you more profoundly understand the impacts of your decisions on your IPv6 design in addition to giving you good information to enlighten and inform. More importantly, if you read those books along with many other good IPv6 references out there (see a more complete list at the bottom of this post) then at a minimum you will not be designing in a vacuum.
As with learning all new things the first realization of the journey is that you don’t know what you don’t know. In other words, you likely have no clue at the beginning of your IPv6 design what to consider because you don’t know enough about IPv6 to know what is or is not important. I think this is often why I tell everyone who is exploring IPv6 to obtain training immediately if their staff will be doing the assessment work. If they don’t, they have no clue what to ask and how to ask it while doing the assessment work. This means the assessment itself may not be accurate. If you have an established IPv6 practitioner do the assessment then you can likely do training and have your staff read and start design work based off what the assessment says with a pretty high level of confidence that the outcome will be positive.
As with all technology, a good design can often help determine the fate of a successful deployment and adoption of a specific protocol, application, topology or other technical choice being made by a given company. Not all technology design decisions are good ones for their respective companies and good design and planning can really help avoid mismatches or highlight pitfalls.
So what small amount of guidance can I give you about your IPv6 design? First and foremost, do not design your IPv6 network with IPv4 thinking.
What does that mean? There are a lot of compromises we have made over the years of operating IPv4 networks that are so engrained in the lore of building IT solutions that we forget there might be other ways to solve problems and free ourselves of these self-imposed constraints. IPv4 thinking involves things like:
· An acceptance that NAT and private address space are MUST have solutions
· That you must conserve address space on ALL network segments
· That functional design must bow down to protocol resource limitations
· That state must be maintained through a network constraining routing and topology choices
· That global addresses are somehow evil, exposing your resources directly on the Internet
· That security cannot function in the same way or with the same impact as what is done in IPv4 today
As your learning expands and your experience grows in IPv6 you will see how limiting these notions are. Often, they can disguise an unconscious FUD (fear, uncertainty, doubt) that results in a hesitancy to learn something new and a dismissal of the challenges of learning IPv6. IPv6 has plenty of its own challenges and operational problems without dragging along all your old ones from IPv4, trust me! At a minimum, keep an open mind to new ideas, ways of thinking and push the comfort levels of your teams to being receptive to new ways to get something done.
Once you have your first design (you will likely end up doing several designs — that is okay, it is pretty common) then it makes sense to start the next phase for your IPv6 adoption plan: Proof of concept. When your team is ready to start testing in a lab to confirm their design, that in itself is a huge milestone in your adoption plan. It is the first time you get to see if your design will work and if you can move to the next step of deployment. If the outcome is negative on the design, that’s okay too. Remember, it might take several tries to get a workable solution that addresses all of your unique business requirements. IPv6 is an important technology to adopt. Don’t be upset if it doesn’t go perfect with the first design. Your planning should anticipate this and you might want to assume you will be doing several POC’s for each related team that has to do something with IPv6 adoption.
Start building out your adoption plan and tackle that design process. Practice makes perfect so get your team doing POCs as soon as you can. I will cover Proof of Concept deployments in my next blog post so until then, remember: IPv6 is the future and the future is now! -Ed
Reference Books Sorted by Published Date:
IPv6 Address Planning by Tom Coffeen (O’Reilly Media, 2014)
IPv6 Essentials, Third Edition by Silva Hagen (O’Reilly Media, 2014)
Practical IPv6 for Windows Administrators by Ed Horley (Apress, 2013)
Understanding IPv6 Third Edition by Joseph Davies (Microsoft Press, 2012)
IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6 by Rick Graziani (Cisco Press, 2012)
IPv6 in Enterprise Networks by Shannon McFarland, Muninder Sambi, Nikhil Sharma, and Sanjay Hooda (Cisco Press, 2011)
Planning for IPv6 by Silvia Hagen (O’Reilly Media, 2011)
DNS and BIND on IPv6 by Cricket Liu (O’Reilly Media, 2011)
Day One: Exploring IPv6 by Chris Grundermann (Juniper Networking Technologies Series, 2011)
IPv6 Network Administration by Niall Richard Murphy and David Malone (O’Reilly Press, 2009)
IPv6 Security by Scott Hogg and Eric Vyncke (Cisco Press, 2008)
IPv6 Essentials, Second Edition by Silva Hagen (O’Reilly Media, 2006)
Deploying IPv6 Networks by Ciprian Popoviciu, Eric Levy-Abegnoli, Patrick Grossetete (Cisco Press, 2006)
Running IPv6 by Iljitsch van Beijnum (Apress, 2005) (an older book but a great reference)
Global IPv6 Strategies: From Business Analysis to Operational Planning by Patrick Grossetete, Ciprian Popoviciu, and Fred Wettling (Cisco Press, 2004)
