In the first part of this two-part series, I shared a recent IPv6 deployment case study I worked on for a government network in the LACNIC region, concentrating on the hereditary peculiarities in the network that we had to overcome, many of which are common among government and organizational networks worldwide.
This second post is a quick guide to the necessary steps such networks will face during an IPv6 deployment project.
1. Get training
IPv6 is not the same as IPv4, not just because of the different length of the addresses. It requires different planning and may require equipment upgrades. As such, you and your team need to get up to speed with it before you set out to deploy it.
A mix of theoretical and hands-on training, both online and face-to-face, from trainers that have had experience with deploying IPv6, industry standards, good practices and policies is a small investment that will result in savings and quality of deployment.
2. Plan how to deploy
Once your team has a sound understanding of IPv6, it’s time to start thinking about planning your deployment.
Every project should start with an audit of the current and future planned changes in infrastructure, from client devices, operating systems, applications, network services, servers, security equipment and, of course, all the equipment that supports the network itself (switches, routers, wireless, and so forth).
The project team must also audit and study the organizational systems the project will have to support, and potential bottlenecks. This will assist with: planning how long each step will take; who will perform the necessary tests to confirm that it works as expected, and that it has not adversely affected the rest of the network, nor its internal or external users; and understanding who can and will connect with an IPv4-only, IPv6-only or dual-stack network.
In terms of testing, it is essential to test from various points on the Internet, to confirm that your network is not just accessible from its immediate environment, economy or region. I often see cases of networks that have not made these checks and have incorrect global visibility.
Generally, this project will force a rethink of many aspects of the current design of the network. It will not be necessary to make changes in all cases — this will depend on each network. But deploying IPv6 can be an opportunity to ensure that the network and its applications and services comply with future developments, such as the Internet of Things (IoT).
3. Take control of the DNS
One of the most important aspects for an adequate deployment of IPv6 is the control of authoritative DNS zones.
The transition to IPv6 is based on the fact that the operating system and/or applications are able to choose properly if they must use IPv4 or IPv6. This implies an intensive use of the DNS for the entire network, which is not common when using only IPv4.
If we don’t have control of the DNS, or depend on third parties to make changes, deployment and testing can become very complex, which can generate large and unnecessary delays and difficulties.
4. Consider using BGP
Many current government and organizational networks running IPv4 don’t deploy BGP with their Internet providers. Instead, they depend closely on Network Address Translation (NAT) or other translation mechanisms, the problems of which are well documented.
Figure 1 — Before and after schematics of a government client’s network. Drag the slider left to right to see the difference. Right click to view the larger-sized image.
In the case of IPv6, there is no need for NAT, therefore the use of BGP is not only a good practice, but essential if you want to employ provider independent addressing to avoid renumbering when changing providers.
Imagine a ministry with 5,000 officials, each with their own computer, in addition to the entire network infrastructure, firewall rules, server configurations and another 5,000 VoIP phones. Imagine the economic cost, the impact on human resources and the ‘disconnection’ time with citizens to make this change every four years when negotiating for a better deal with another ISP. Do not underestimate the impact even when we talk about only 500 or 1,000 user devices.
5. Develop an addressing plan
In many cases, existing IPv4 address plans can be used as a reference for IPv6. The recommendation, however, is to start from scratch because undoubtedly IPv4 ‘patches’ will have been made over the years.
In addition, IPv4 address plans will most likely be based on private addresses that may even be duplicated in different parts of the network. IPv6, again, is an opportunity to look to the future.
We can say that IPv6 has almost unlimited address space, but you have to be meticulous and not waste addresses where it is convenient. In many cases, it’s recommended to use ‘bits’ to facilitate identification of networks/VLANs, services, geography or several of these aspects. However, it pays to be cautious with these recommendations — each network case is very different and often this leads to a waste of addresses because of the ‘consumption’ of bits in an absolutely ridiculous and unnecessary way.
6. Obtain Internet number resources (ASNs, IPv4 and IPv6 addresses)
If you want to avoid renumbering and be able to have your own addresses with BGP, you have to obtain from an RIR an ASN in addition to your IPv4 and IPv6 addressing space.
In the case of IPv4, if the need is adequately justified, it is possible to obtain up to a /22, that is, 1,024 addresses. This will only be possible while IPv4 addresses remain in the corresponding RIR and if it is the first time your organization has requested addresses. Alternatively, an IP broker could help with acquiring more IPv4 addresses.
In the case of IPv6, if your organization only uses the addresses for its own network and not for third parties, it can qualify for a minimum of one /48 for each ‘site’ of the network. This allows addressing for up to 65,536 subnets (/64) within each site.
If it is a larger network, which may need to sub-assign addresses to third parties, even to other institutions in the case of a government network, then it will qualify for a minimum of one /32 (allowing 65,536 sites, each with its own /48).
Large networks of governments will often require shorter prefixes, for example, /25 or /26.
7. Employ IPAM tools
Many organizations have historically used a text document, spreadsheet or even a notebook to create their address plan. Because IPv6 address space is a lot larger than IPv4 it’s easier to use specific IP addressing management tools — IP Address Management or IPAM for short — which can be open source, commercial solutions or even devices (‘appliances’).
Often these solutions allow coordination with the DNS and even with DHCPv4 and DHCPv6.
8. Understand assignment and auditing of addresses
One of the most important aspects when deploying IPv6 is to understand the differences between the different mechanisms of address assignment, such as autoconfiguration with SLAAC, DHCPv6, or the combination of both and even the use of multiple addresses on each interface. It is also necessary to understand what devices or operating systems can use one or the other and in what circumstances.
In networks that are required to continually ‘audit’ the devices and users that are accessing certain applications or services — a usual practice in government networks or financial entities — these aspects have a special relevance and represent very significant changes with respect to IPv4, which can have an impact on applications, databases and network security mechanisms.
9. Make sure you have IPv6 support
When auditing network equipment — the servers, client equipment and operating systems — don’t assume that because it says ‘supports IPv6’ that it does.
There is no clear definition of ‘IPv6 support’; it depends exclusively on the context of where a device or operating system will be used. That is, what RFCs it must comply with according to its location and functions in each specific point of the network.
Check with your vendors to make sure that what you have and what you’re planning on purchasing will be compliant.
10. Test applications and services
This is undoubtedly the most complicated aspect of deploying IPv6. We can find applications that use literal addresses, applications that use old libraries without IPv6 support, applications that store 32-bit fields in databases, and an endless list of other problems.
All these applications could continue working when we deploy IPv6 with IPv4 (dual-stack), but will not work when IPv4 is removed from the network; this will happen sooner rather than later. While maintaining dual-stack in the network, applications that depend on IPv4 for security or audit purposes will not work correctly when users access them with IPv6. Likewise, many applications can be impacted when external users only have access to IPv6.
In short, this forces us to study and classify these applications and adopt appropriate solutions.
11. Take a long term approach to choosing your transition mechanisms
Deploying IPv6 should not be considered exclusively dependent on the coexistence with IPv4. While generally the logical step is that both protocols coexist at present, the very near future is that networks will be IPv6-only.
This implies that the entire deployment project must contemplate both situations, and solve the problems that arise in both cases, with the aforementioned special impact on applications, since some of them can’t be modified (the manufacturer no longer exists, there is no access to the source code, the change is very expensive and so forth). And in some cases, adopt transition mechanisms that allow coexistence initially, and finally an ‘IPv6-only’ network.
12. Check contracts with operators and connections with other organizations
Often, and especially in large networks, we have several Internet providers that generally do not collaborate with each other. It also happens that there are other different providers for voice, or other telecommunication services.
Deploying IPv6 will require renegotiating those contracts, both data, voice and other services, so they not only have IPv6 support (initially in dual-stack mode, in the future they could be IPv6-only), but also BGP support. Only in cases of a single common provider for all services, is BGP not required, although it is still convenient and good practice to have multiple paths with different providers, and to announce your own addressing space via your own ASN.
Like all projects there will be variations
Once we have considered all 12 of these steps only then can we start with deployment. Depending on the size of the network, it may take several months, even years, for the most complicated aspects, such as the analysis and adaptation of all applications.
It is important to keep in mind that there are many other aspects, besides those indicated in this guide. For example, it will be necessary to prepare a purchasing guide, so that future acquisitions and contracts fulfil the appropriate requirements in each case regarding IPv6 support and training for software developers (internal or external collaborators). Also it’s worth preparing a roadmap to maximize the use of having IPv6 deployment; it is logical to assume that the network will have IoT services in the future; think SmartCities in the case of government networks.
All these aspects, and many others, will undoubtedly give you a vision very different from your current IPv4 network, hence the importance of training and consulting with people with previous experience in government and corporate networks with IPv6, since this guide is only a starting point.
Jordi Palet is CEO/CTO of The IPv6 Company.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.