As I was reading Ed Horley’s fifth blog post in his series on IPv6 planning and deployment best practices, it made me think about how organizations shouldn’t wait to get started. Organizations should not delay their IPv6 deployment by trying to attempt to design it perfectly from the start. Large and small organizations tend to fall into the traditional linear “waterfall” thinking when it comes to deploying information technology. Their desire to get things right the first time and anticipate all future problems halts their forward progress. This got me thinking about how a more “agile” approach could be used to speed up IPv6 deployments.
The Agile Methodology is an approach to project management that is typically used in software development. It uses an iterative approach of smaller work amounts called “sprints.” This methodology originated from a paper written in 2001 titled “Manifesto for Agile Software Development” that documents, according to the authors, how software should be created. This manifesto is also complimented by a list of guiding principles titled “Principles behind the Agile Manifesto”. This agile methodology helps to rapidly create early versions of software that deliver the essentially features and then over time improve the software with user feedback. The goal is to ship minimum viable working software early and not wait for a fully functional product with all the features before you start to hear from customers. If you try to anticipate all the features a user may want, you could waste valuable time writing software that isn’t as valuable to customers as you thought. You want customer input sooner (and throughout the process) to speed up creation of the product and adapt to changes. This will help you go to market quicker and deliver more user-desirable features earlier in the product lifecycle.
The mantra of many Silicon Valley startups “fail fast, fail often, fail forward” further illustrates the concepts of this new methodology. It seems to say: “We want to have adaptive planning with quick feedback cycles because we do not know what the future holds.” Humans have shown that we are bad at predicting the future and at anticipating market demand. For example, just ask an IPv6 expert what year they expect IPv6 to become mainstream.
Many times people start implementing IPv6 without fully knowing the intricacies of the protocol. This may be an acceptable approach and may be substantially better than waiting to deploy IPv6 until it is “finished.” Consider that, even today, the IPv4 protocol is not finished evolving. Therefore, you cannot afford to wait until IPv6 is finished evolving before you start to move forward with deployment. Get started and adapt as your needs evolve and as the protocol becomes fully integrated into all network-connected devices. With IPv6, you want to have early delivery, flexibility to change rapidly, continuous improvement, and evolutionary development.
Agile methodology shares some philosophies with the Scrum methodology for software development. Both are iterative and incremental approaches and they both extol the virtues of flexibility and agility and speeding up the development lifecycle. Scrum challenges the traditional linear and stepwise methods for managing projects. The traditional waterfall approaches lead to cost overruns, missed schedules, and products that were not fit for task or purpose. The product could take years to develop before it is first seen by the customers and well after it was too late to change.
One of the key principles in scrum is the concept of getting customer and user input early in the process and getting continuous feedback as part of feature testing. These “User Stories” drive the functionality and goals of the project and will then be broken up into much smaller tasks and assigned to the various team members (e.g., IPv6 transition team members). Scrum methodology prescribes trying to achieve each of these within one sprint cycle. A sprint cycle can be anywhere from a few weeks to a month or more. The goal should be to try to keep the sprint cycles to a uniform duration that are not too lengthy.
When it comes to IPv6, there are many “user stories” that would drive planning and deployment. Examples of IPv6-related user stories are:
- Reduce dependence on IPv4 addressing scarcity and avoid Carrier-Grade NAT (CGN)
- Establish IPv6 connectivity to the Internet via current ISPs
- IPv6-enable Internet perimeter firewall
- Establish a dual-protocol, Internet-reachable authoritative DNS service
- Deploy a dual-protocol web server for testing Internet connectivity
- IPv6-enable the primary company web site
Smaller, measureable goals is another agile method. You do not want to take on a large goal and then not measure success until completion. It is better to have smaller goals that lead toward the ultimate direction, but allow for measurement of success sooner in the process. An example of this is for organizations to start their IPv6 deployment by focusing on achieving a few simple tasks. Deploying IPv6 Internet connectivity to your DNS server, your web server, and your e-mail server are three short-term goals that are easy to evaluate success. As we saw from the above list of user stories, a common agile approach to IPv6 might be to start at the Internet edge. Once you have had success on that initial goal, then you can move forward with deploying IPv6 internally within the enterprise.
The same agile methodology holds true for IPv6 address planning. You would not want to spend years working on the ultimate IPv6 addressing design that takes everything into consideration. By trying to make it “perfect” you will be delaying your start and delaying the time when you start to gain experience with IPv6. By creating an IPv6 addressing plan that focusses initially on the Internet perimeter, you are starting small. If you fail, you can easily re-address that smaller portion of your environment. Then you can apply these lessons learned toward your IPv6 addressing plan as you start to bring IPv6 into your core and internal WAN. By the time you are ready to start assigning IPv6 addresses to access networks and ultimately to end-user devices, you will possess deployment and testing experience. Ron Broersma (U.S. Navy/SPAWAR) predicts that most organization will go through multiple iterations of their IPv6 addressing plan before they settle on their final design.
Another aspect of agile methodology is to facilitate collaboration between smaller self-organizing cross-functional teams. This is applicable to IPv6 because you do not want to solely create a team of network engineers to lead your IPv6 deployment. Deployment of IPv6 is not just a “network problem.” Today, the Internet Protocol touches every facet of your enterprise. Servers, storage, facilities systems, mobile devices, wired and wireless networks, and embedded smart objects all rely on IP connectivity. Therefore, IPv6 will eventually touch every one of these areas.
The most successful IPv6 deployments will be performed by interdisciplinary teams that have management support and representation from all business units. Organizations should take a page from how the U.S. government has structured their IPv6 initiatives. For example, enterprises should create IPv6 task force teams that have people from systems, software, network, and helpdesk departments. Having these different perspectives and specialties be part of the small and focused agile team will increase the likelihood of success.
Another aspect of agile and scrum methodologies is to avoid complexity and try to keep Occam’s Razor in mind. When it comes to IPv6, you will want to keep it simple, dual-stack where you can, tunnel where you must. You will prefer using native IPv6 connectivity to the Internet and proceeding in a “small strokes fell great oaks” approach to getting the job done. Your IPv6 deployment will likely be treated like an organization-wide program (i.e., a collection of many smaller projects) and will transpire over many years. Don’t force complexity; IT systems are already complex enough.
Another area of avoiding complexity in IPv6 is to stick to several standard prefix lengths. The /64 is the common prefix length that you will use virtually everywhere for interfaces (see RFC 4291 and RFC 7421). There may be a few other prefix lengths that you may use sparingly but /64 should be the default prefix length. You might use a /128 for loopback interfaces and you might entertain the use of /127s. However, I would argue that you have plenty of /64s and there is benefit of simplicity and commonality in keeping all prefix lengths the same across your entire networked environment.
From all of this, we can take away the idea that we should start sooner, rather than later, on our IPv6 deployment. Our planning and deployment strategies will likely change over time as our requirements and user stories change. We should create small interdisciplinary teams that can accelerate the business impact of IPv6 sooner than with traditional linear approaches. We shouldn’t be afraid to fail with IPv6 as it offers plentiful amounts of IPv6 addresses to adjust as needed. In today’s busy IT world “time is of the essence.” There is no time like the present to start using agile and scrum methodologies to accelerate your IPv6 deployment.
