In my previous posts I went over details for the first phase of your IPv6 adoption plan, the assessment, the second phase of training and the third phase of planning and design too. You can find the original post that covers the overall topic about IPv6 adoption here. In this post, I wanted to tackle the fourth phase which is the proof of concept or POC.
A POC is designed to address several items before you deploy or operate an IPv6 enabled network.
• First, a POC allows validation that your design will work as expected.
• Second, a POC will potentially reveal better ways to deploy and operate your network with IPv6 in the mix.
• Third, if your POC does not work, it allows you to iterate quickly on design changes to get to a valid and working design.
• Fourth, it allows testing and validation in an environment that is friendly to outages, issues and breaking things. You don’t want to do initial testing in your production environment. That is a sure way to create a resume updating event.
• Finally, a POC will help re-inforce the knowledge you gained in the training phase by putting it to practical use allowing everyone to learn as the POC progresses.
So what makes up a reasonable POC? How do you determine what is in scope, out of scope, important or not important? Let’s go over some initial questions and steps you can take to determine if something should make it into your POC or not.
A POC should be able to accommodate requirement from each of the key technology pillars you have within a given company. It doesn’t mean you have to build a specific design plan for each, just that you can accommodate their needs if they require specific testing. Additionally, these groups will likely have different timing and dependencies. For instance, it is likely your systems team will want to test IPv6 after you have the network up and operational and the database folks will want the systems up and validated before they begin their testing and so on. As mentioned in my previous post around design and planning you will have teams with varied responsibilities, including:
• 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
There can be more teams and categories than this and any or all teams will potentially want to participate in the POC depending on their scope and need requirements. Some teams will be able to test and validate their IPv6 support without needing any network or security infrastructure in place to test. For others, it will be impossible for them to validate IPv6 support without a network and other resources to test their designs to validate if they are operationally sound and will work. If you are in the unfortunate situation of having a lab comprised of old hand-me-down network gear you might have trouble replicating what you have in production. At that point it might be appropriate to leverage GNS3 or Cisco Modeling Laboratory (CML) to help test your IPv6 configurations.
The most common place to start on a POC is to get a network functional with either dual-stack support (running both IPv4 and IPv6 on the same network) or IPv6 only support. As public IPv4 become harder to obtain it will not be uncommon to see more IPv6 only data center configurations come about as projects. Major Internet players like Facebook (http://www.internetsociety.org/deploy360/resources/case-study-facebook-moving-to-an-ipv6-only-intern… are doing exactly that and making IPv4 a service they deploy on top of IPv6. It is far easier to support a single networking protocol in production and run a simple overlay for the few times you need IPv4 inside your network then to fully support dual-stack. It is operationally simpler and ensures your application services fully support IPv6 while also moving all your IPv4 addresses to the edge to be distributed in pools and used as needed.
Granted, most enterprise networks don’t run public IPv4 networks and are likely making use of RFC 1918 IPv4 address space for the corporate intranet and private data centers. In these situations, it will be more common for a network to become dual-stacked as an initial solution simply because many do not do the work to understand the unknowns that might break their network if IPv4 was not operational. Network teams in a POC can simply build out a dedicated network segment that has IPv6 enabled. I recommend that companies get full IPv6 Internet BGP peering functional prior to starting the POC. This reduces the chance of having to re-address the network at a later time. It is relatively trivial to ask for IPv6 address space from RIR’s today and they are generous with the default allocations. Remember, think how many networks you need to operate in a given allocation request, not how many hosts you have in your enterprise. Refer to Tom Coffeen’s excellent 2014 book, IPv6 Address Planning from O’Reilly Media (http://www.amazon.com/IPv6-Address-Planning-Designing-Future/dp/1491902760/ref=pd_sim_b_4?ie=UTF8&re…) for more information about how to obtain, plan and allocate your IPv6 addresses.
Once your network team has the basics built out I recommend that two teams get into the mix next: Security and systems. If these teams are able to build out their environments and validate they have working IPv4 and IPv6 services (if you are going with the dual-stack approach) then you are well on your way to having a successful POC. Likely your security team will run into some challenges, especially around Path MTU, ICMPv6 and potentially some of the differences in protocol port numbers, as well as other functions and features that are different between IPv4 and IPv6. Your systems team will more likely run into challenges with DHCPv6, DNS and virtualization IP address provisioning. They are likely used to assigning IPv4 address resources using MAC addresses. Given the operational changes in DHCPv6, that no longer applies. As a result, new workflows for deploying VM’s will have to occur. For instance, you will have to run sysprep on Windows platforms to remove the DUID or you will have duplicate values and DHCPv6 will fail to assign an IPv6 address to a host. Also, the concept of a host having different methods to learn DNS server information might be disruptive for both the systems and security teams. To top it off, trying to correlate the host IPv4 and IPv6 information in the logging and authentication process can become challenging as there is no easy way to do this function today.
As with all technology, a good design should take into consideration many of these conditions. This is the value of having a POC: to test and validate your assumptions in your design and to determine if there are gaps in operational models.
Once you have a stable POC from a network, systems and security standpoint it will make sense to request that application teams deploy their configurations on top of the POC environment. From here, testing plans will be critical. You will need to test all the services you use in IPv4 in the dual-stack configuration of the POC. In addition, I recommend you shut off IPv4 to see if your environment works in IPv6-only. This helps you determine what services and applications require IPv4. This is when you should heavily document your testing and validation of these services. This is also an excellent time to bring in some of your helpdesk and users to have them pilot what you have built in the POC. No one can find a broken network faster than an end user just trying to do their job. Also, make sure you set up services like VPN, remote app and desktop services and test those capabilities from an external IPv6 network. This means potentially setting up a few key people in their home offices with IPv6. With any luck, they already have IPv6 from their provider (Comcast for instance) or you can set them up with a tunnel service like Hurricane Electric’s free tunnelbroker.net IPv6 service. Either way, external testing and validation is important.
A POC can fill in a lot of knowledge gaps and help a team feel comfortable with IPv6. There is no replacing practical hands-on time using a protocol. Doing the configuration and debugging of the POC in addition to using and supporting it makes for quick learning for all those involved. Just remember, the goal isn’t to do a POC and then put IPv6 up on a shelf because you are satisfied you can support it. The goal is to move to the next phase: deployment! That will be the topic for my next post, in the meantime remember…
IPv6 is the future and the future is now!
– Ed
