In my previous posts I went over details for the first four phases of your IPv6 adoption plan:
You can find the original post that covers the overall topic about IPv6 adoption here. In this post, I wanted to tackle the fifth phase which is deployment.
A deployment of IPv6 is an extension of a POC but you are modifying the scope and the key items you need to address.
- First, because you have validated your design in the POC, deployment is about setting expectations. The start is dual-stack everywhere but the end goal is still IPv6-only.
- Second, you need to develop phases, typically around areas of impact.
- Third, if your deployment runs into problems, your phases need to accommodate being moved around. Iterating quickly through problems to a solution to get to a valid and working deployment is important.
- Fourth, don’t make your phases too big: you will get stuck in a rut and never complete the deployment.
- Finally, a deployment should include all teams and needs to be integrated into the on-going culture.
So what steps do you need to take to have a successful deployment? How do you determine what is in scope for each phase and how many phases you should use? Let’s go over some initial questions and steps you can take to deploy IPv6 properly.
A deployment goes beyond a POC because it must be able to accommodate requirement from each of the key technology pillars you have within a given company. It means you have to build a specific plan for each and that you accommodate or work around their needs. Additionally, these groups will likely have different timing and dependencies which may impact your phases for deployment.
When tackling deployment there are some fundamental order of operation that are important to tackle. Because you are doing a deployment, logging, monitoring, network and systems will be the first critical components that require attention. Your phases have to start with making those parts work first otherwise they will not be successful.
The same teams are involved as in a POC. However, the following order is likely more common for deployment:
- Network – routers, switches, wireless, load balancing, DHCP, DNS, IPAM, Internet peering, routing policies, monitoring, video, voice, transition services (translation)
- Security – firewalls, IDS/IPS, logging, monitoring, identity management, policy and access controls
- Systems and Virtualization – Host servers, applications, guest OS’s, DNS, DHCP, IPAM, logging, identity management, client OS’s, printers, video, voice, transition services
- Storage – SAN, file protocols, file services, backup and recovery
- Help Desk and NOC – troubleshooting, training and escalation around dual-stack and IPv6 tools
- Architects – Impacts that IPv6 will have on their designs and integration points with applications – seeing the big picture
- Database – SQL, big data, Hadoop or other data analysis processes
- Line of business applications – CRM, HR, Financials, or any customer applications developed by the company itself
- Third Party – partner networks, partner SaaS, CDN, DNS, email or any other service the company uses from a third party
There can be more or fewer teams and categories than this and any or all teams will potentially want specific phases depending on their scope and need requirements. The phases of work will likely overlap so that having a project manager who can help the team coordinate what they are doing is critical.
Importantly, management needs to understand that IPv6 is an ongoing requirement once the deployment begins. In other words, they cannot adopt or support a technology in the future that does not address IPv6 in some manner, even if a transition technology is planned. A deployment plan that explains how that transition plan is accounting for IPv6 for the new application or service that is being used on the network will still be needed. Obviously, the best plan is to natively support IPv6 but sometimes if partner solutions do not have that support then transition technology validation should be part of the evaluation of the product.
Let’s examine one team and some likely phases they would encounter. Because almost everyone will begin with some sort of networking turn up for their IPv6 deployment (IPv6 is a network protocol after all) the networking team offers a great example team to start with.
Some example phases I have seen used are:
- External IPv6 – including items like IPv6 BGP peering, IPv6 address allocation requests (if international, potentially additional RIR requests), ISP peering policy arrangements, eBGP set up, IPv6 prefix announcements, iBGP set up, external route server registration, bogon and filter lists, logging and monitoring.
- Transition Edge – including items like load balancers or application delivery controllers (ADCs), firewalls, VPN, external DNS, external SMTP, and any other publicly available service (some do all DMZ services in this phase, some break that out separately since it can potentially include a lot of application testing).
- WAN or Backbone – this typically is limited to simply ensuring that all routing and forwarding devices are IPv6 enabled, peering works, routing protocols work and that the topology is consistent. It may include things like IPS/IDS, flow analysis, and ACL and routing policy.
- Data Center – because you need services for clients to connect to it makes sense to enable those services first. These are often resident in your data center so getting IPv6 working once the WAN or backbone is set up makes sense. It allows you to test specific host and routing behavior end to end along with validating firewall, logging and monitoring. Often the DC is broken into phases and less critical services are deployed first. If those are successful then more services are moved.
- Campus, Building or Client Access – depending on the size and operational complexity of the company several phases could be tackled to turn up client IPv6 access. Often for large companies a campus site is selected and then specific buildings and potentially an operational group in the building is chosen to test with first. It is not unusual that other services or devices are also deployed at this time. Examples would be video, voice, cameras, printers, scanners, sensors and alarm systems.
- Wireless – it is not unusual for wireless to be separated out and also to be broken into two different phases. One for internal use, which often dovetails with the client access phase, and a second that is for the guest network.
In addition to outlining the actual phases, it is important to document who might be potentially impacted by the phase and have the project manager get those specific teams or owners involved in the process early. As you can see from the example potential phases, you will have other stakeholders who will have to be involved for the deployment to be successful.
Just as you did with the POC, you will need to test and validate your deployment as it is happening and ensure your operational models continue to work with the rollout. This requires working closely with operations and help desk to make sure things are actually working as expected. In addition, you will need to make sure existing audit, logging and monitoring tools are functioning correctly and able to work if one protocol or the other is not available.
Once you have a stable deployment started it will make sense to test and validate the environment in an automated way going forward. By automating this process you ensure that as the deployment processes you will not miss or accidently revert things. You will need to test all the services you use in IPv4 in the dual-stack configuration of the network. In addition, I still recommend you shut off IPv4 (if possible) to see if your environment works in IPv6-only.
A deployment of IPv6 is a reinforcement of all the IPv6 skills that your team developed during the POC. Use this opportunity to get as many team members hands on time with IPv6. There is a lot of work to do in the deployment, so do not restrict who is doing the work: it can limit the benefits of skill and knowledge transfer.
Just remember: the goal isn’t to do a deployment of dual-stack and then never go to IPv6-only. You eventually need to run an IPv6-only networks. The running of a dual-stack network is a different skill and the goal is to move to the final phase: operations of an IPv6 network. That will be the topic for my next post, in the meantime remember…
IPv6 is the future and the future is now!
– Ed
