Image by comedy_nose
If you are planning a transition to IPv6, you’ve probably come across advice on how to organize a network migration. This advice most likely mentioned the following steps:
- Analysis: Inventory all network devices, operating systems, software and compliance details.
- Planning: Redesign your network and plan upgrades to devices/software.
- Testing and Staging: Test key elements, document compliance, troubleshoot, ensure routing and create key use cases.
- Execution: Take the leap of faith that you have done everything you can for the changes to be successful, as well as take the fallout for any steps you didn’t think of earlier.
Somehow these steps don’t seem like enough. We must take into account the fact that both internal and external users access the network every day, and some phases of network change may require unacceptably long outages with intermediate solutions. The reality of integrating IPv6 into a network is that, depending on the size of your network, it could take several phases or be as simple as adding a second IP address and default routes to each IP-enabled device.
Why Deploying IPv6 Is Like Travelling to a Foreign Country
When you plan a trip to a foreign country, you might learn the basics of its language before you leave, such as how to ask for directions and order food. On your trip, you’d also probably pick up a few explicative remarks that express your emotional or physical discomfort from having eaten the wrong foods. However, if you use your native language to express your discomfort, you will be met with blank stares.
IPv4 and IPv6 are like two different languages but can operate on the same network at the same time. Any computer or network device with both an IPv4 and IPv6 address and routing statements is ‘dual stack’. Perhaps you can think of it as being bilingual.
Similarly, IPv4 websites can’t communicate directly with IPv6 users and vice versa. That’s why your journey towards IPv6 should begin with a travel plan.
5 Questions to Ask Before You Begin Your IPv6 Journey
1. What do you want each user’s IPv6 experience to be like on your network?
- Who are your users (e.g. customers, the public, vendors, internal employees, external employees)?
- What are they accessing on your network (e.g. web content, mail servers, ecommerce tools, SharePoint, intranet, CRM, billing systems, etc.)?
2. What modes of transportation or tools are needed so the user gets the content they want?
- List the dependencies that are both inside and outside your network or control that contribute to each group’s experience. These might include DNS, web browsers, other client-side applications, support tools or personnel.
3. Identify when a lesser experience is acceptable or not acceptable.
- External users: Recognizse that if you have a web server and content such as video, Flash and style sheets, they also need to have IPv6 enabled. If these services don’t have IPv6, you will see an error message. Is that okay? If they don’t have DNS enabled for the IPv6 addresses, they can’t get to the content.
- External employees: These users will be IPv4 or IPv6. Define what is critical for them to be productive (e.g. VPN, CRM or email) or not critical (e.g. fax machines, etc.).
- Internal employees: Assuming internal users will be dual stack for a while, what network elements can only work with IPv4 (e.g. printers, fax machines, IP phones, intranet, CRM, etc.)?
4. What is the most important experience to your business?
In other words, what generates money for your company, what communicates your brand and what ensures that you continue to operate as a business?
- You must ensure accessibility to anything related to your domain name (e.g. websites; email; DNS; and corporate, e-commerce and extranet portals).
5. How much of the new IPv6 language do you need to learn?
- Hexadecimal address notation, AAAA (quad-A) DNS records, NAT64 and more.
- What can you learn along the way? Perhaps v6DHCP, flow control, DS-LITE or others.
Answering the above questions as you start your network analysis will help you easily identify your key network elements, along with which phase of IPv6 enablement they belong in.
If you want to know where I would start, I would focus on enabling IPv6 in the DMZ (demilitarized zone or public server area), edge routers, DNS, email, web/e-commerce sites, content servers and firewalls. Don’t forget to also enable internal areas/personnel that are essential to the support of IPv6 content for external users, or perhaps set up a dual stack ‘jump server’ in the DMZ, accessible by both IPv4 and IPv6.
I hope that your adventure into IPv6 and enabling this new Internet language in your network is not just educational, but also a successful and fun trip.
What about you? What items are on your IPv6 travel plan? Feel free to share your comments below.