ADMIN
Features IPv6 Migration Planning Lead image: Lead Image © Jarts, PHOTOCASE.com
Lead Image © Jarts, PHOTOCASE.com
 

Migrating your network to IPv6

New Address

Abraham Lincoln once said, "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." The transition to IPv6 is a big step for many organizations. Careful planning and a systematic approach are critical to a successful migration. By Eric Amberg

All too often, IPv6 is simply ignored or postponed to make room for seemingly more important things. However, IPv6 is one of the most important topics for the future of IT. The transition to IPv6 is a company-wide project. It is not enough for the IT department to have a brainstorming session and hatch a plan. Everyone who has a legitimate interest in the actions and their results must be involved. IPv6 migration planning must be a top priority, and it must have the support of management.

The Right Perspective

If you are responsible for project planning, you need to think like a general: Do not just consider the individual areas of the battlefield but analyze the overall situation. Gain insights, identify strengths and weaknesses, and define objectives. Only after this process should you start to develop a plan for how and in what order you will achieve these objectives. Defining these milestones has proved essential to IPv6 migration.

Always schedule sufficient time and take setbacks into account. Depending on the environment, an IPv6 migration could extend over several years, so be realistic and not too optimistic. You will put yourself and your team under unnecessary management pressure if you define the timing goals too tightly.

Establishing experience and know-how is an important part of the IPv6 migration. Build a lab environment that simulates the basic components of the production environment and allows for realistic testing. If you need to roll back and restart because of a lack of testing, your users will not be happy – not to mention the potentially unpleasant questions from management. Be sure to perform extensive testing on the results after each change.

While you are planning your project, you need a realistic assessment of the costs. Costs arise from the need to replace non-IPv6-capable systems, but also from person-days, expenses for employee training, and support by external service providers.

Evaluation of the Situation

A sensible first step in migration planning is to make an inventory of the existing IT systems. In the best case, you will have a well-maintained, up-to-date Configuration Management Database (CMDB). In addition to other information, your list should include the following data for each asset (e.g., computer, printer, switch, software):

It is also of utmost importance to determine the mutual dependencies of the components. For example, leaving an important file server inaccessible during the migration can affect many parts of the IT infrastructure.

After completing the inventory, you need to identify which components are IPv6 capable. Not all systems and subsystems of an IT infrastructure are relevant to the IPv6 migration. For example, you will not be interested in the desktop or server housings or other passive components. All components that communicate via IP(v4) are initially involved, including printers, switches (at management level), NTP server systems (hardware-based), card reader systems, and IP phones.

You'll need to test all of these systems for their IPv6 capability. However, you should not assume that IPv6 is in place just because it says so on the box: often IPv6 support is only available for a subset of the features and can be buggy. The goal of the laboratory tests is to uncover these kinds of problems. Components that are not IPv6-ready fall into two categories:

You'll need an appropriate budget and schedule for upgrading everything you can upgrade. Any systems you can't upgrade you'll need to replace or eliminate – or come up with a plan for how you will isolate them and keep them running on IPv4, possibly using translation mechanisms such as NAT64 to connect with the IPv6 network.

Involving Service Providers

Internet and intersite connections are typically managed through service providers. Many providers offer advanced IPv6 migration options; however, it is important to contact your service provider and clarify the possibilities.

The IPv6 Address

One of the greatest challenges at the beginning of the migration is establishing a meaningful IPv6 addressing solution. The new addressing rules and variations offer so many possibilities that network designers are often initially overwhelmed. Before you start, you will want to answer the following questions:

The person responsible for planning does not need to answer all of these questions right from the outset. However, you should be aware that these decisions must be made, and you can only develop the address solution in detail after these questions are answered. In this context, address planning tools (IPAM) provide an interesting option.

Address Solution Tips

The assumption is that you almost always have enough space. Consider a typical /48 prefix, which is typically assigned to a company: You have 16 bits available up to the /64 subnet boundary. This is like dividing an IPv4 Class A network into a bunch of Class C networks. All told, you can use 65,536 subnets. If that's not enough, you can typically apply for a smaller prefix, with even more free subnet bits (e.g., /32), or at least an additional /48 prefix. Even private customers are often given a /56 prefix.

If possible, you should avoid messing with the basic /64 subnetwork border; this also applies to transfer networks, which only need two addresses. Although you can theoretically also introduce /127 subnets, this option has not proved useful in practice.

Define a range at the start or at the end of your address space that you use for special purposes, for example, for transfer networks. Then, set a range that you keep in reserve (Figure 1). This range will act as a buffer between the transfer networks and the LAN if you need more than planned of either variety.

Dividing the IP address space.
Figure 1: Dividing the IP address space.

For your subnetwork planning, try to maintain a logical and consistent numbering scheme. For example, assume you have 16 subnet bits – that is, four hexadecimal digits. You have three sites and are unlikely ever to have more than 256. Each location has four different types of network: LAN, servers, DMZ, and telephony. In Figure 2, the third wireless LAN network at the Boston location would have a subnet value of 0103.

An address concept across multiple sites and different applications.
Figure 2: An address concept across multiple sites and different applications.

Migration Strategies

Only in a very small number of (professional) environments will you be able to introduce IPv6 throughout the enterprise all at once – the risk of major failures and breakdowns would be huge! Because of the available migration technologies, an instantaneous upgrade is usually not necessary. You can introduce IPv6 gradually and systematically. Three rollout alternatives that have proved useful are core-to-edge, edge-to-core, and IPv6 islands.

The core-to-edge approach (Figure 3) involves first migrating the core systems on the network – that is, the core routers and switches – and, if necessary, central server systems. The core systems are often equipped with the most advanced IT infrastructure and therefore support IPv6 best. From the core, you then work your way forward to the edge systems, on which your users work. You can expect increasing complexity configuring user desktop systems. This approach is often the best option if the IPv6 transition can occur as a long-term project.

Migration strategies: From the edges or the center?
Figure 3: Migration strategies: From the edges or the center?

An edge-to-core migration is often used to migrate IPv6 as soon as possible. In this scenario, the edge systems where the users work will migrate before the core systems follow. You should only adopt this approach if absolutely necessary.

Another approach to introducing IPv6 is to set up IPv6 islands. Islands operate in isolation but communicate with each other through a tunnel over intermediate IPv4 networks. You can use the island approach in parallel with the other approaches. In scenarios in which parts of the IT infrastructure communicate with each other in isolation, it is a good idea to have only a few interfaces to the outside world.

Migration Technologies: Dual Stacks and Tunnels

It is only possible to roll out IPv6 all at once in very small environments. In most cases, you will need to adopt technologies that enable a smooth migration and facilitate IPv6's coexistence with IPv4. You can combine these technologies, depending on the scenario.

The most important transition technology is the dual stack, which allows IPv4 and IPv6 to operate in parallel on a system. The advantage lies in a largely safe migration, because in case of problems, you can immediately resort to IPv4.

The disadvantage of operating a dual stack is a higher administration overhead, which can lead to a higher potential for error because, in principle, any change to the IP configuration and communication needs to be carried out for both IPv4 and IPv6. Nevertheless, dual stack is a popular migration option, since it minimizes the effect on the existing infrastructure.

If you cannot implement a dual-stack solution across the board, you can use the island solution to transition part of your infrastructure while maintaining communication through tunnels. IPv6 packets are typically tunneled in IPv4 and transferred from island to island (Figure 4) via the IPv4 infrastructure.

A tunnel connecting two IPv6 systems over an IPv4 network.
Figure 4: A tunnel connecting two IPv6 systems over an IPv4 network.

Tunnel technologies are always a second choice because they don't provide native IPv6 communication. In some scenarios, tunnels are useful as temporary solutions and should be considered, where appropriate, for migration planning. Various tunnel solutions exist, including:

Keep in mind that tunnel technology is only a temporary solution that you will need to remove and replace with a native IPv6 solution.

If neither a dual-stack or tunnel solution is available, your last option is to translate from IPv6 to IPv4 or vice versa. Various translation methods have evolved for this purpose. Translation has major disadvantages and should be considered if you have no other way to communicate. Techniques include the obsolete NAT-PT, which has been replaced by the NAT64/DNS64 approach and complemented by 464 XLAT, as well as other mechanisms.

Switches and Routers

Switches are generally not directly involved in IPv6 communication; however, several reasons exist for involving switches in migration considerations, including:

Routers are the essential connection points for IP(v6) communication. If the routers do not support IPv6, no cross-subnet network communication via IPv6 is possible. Router migration therefore plays a crucial role within the framework of the IPv6 transition. Fortunately, most router manufacturers have implemented good IPv6 support in their products. But beware of pitfalls! You need to test the products and remember to include performance tests. In the case of some routers from well-known manufacturers, the routing logic for IPv4 was implemented at a very low level, but this level of care does not apply to IPv6 routing; systems thus route IPv6 at speeds an order of magnitude slower than IPv4. The IPv6 addressing solution is very closely connected with migrating the routers. Without defining subnets, router migration is not possible on IPv6.

Security Components

Before you even think about using IPv6 to talk to the Internet, you need to ensure that your security components can provide the same level of security for IPv6 as for IPv4. Of course, this applies first and foremost to the firewall. The firewall must fully map the IPv4 framework on IPv6. You'll need to add special filters that are relevant only to IPv6, such as extension headers.

One essential point in the scope of firewall configuration is eliminating NAT for IPv6. In plain talk: All systems that communicate directly with the Internet use globally unique (global unicast multiple) addresses. This address is routed to your location, so internal systems are potentially vulnerable. It is thus essential that the perimeter firewall provides a suitable filter. You get good protection in this scenario if you add intermediate proxy systems that handle the communication for the internal clients. This configuration is already part of best practices for IPv4.

Remember also that proxies must support communication from IPv6 to IPv4 systems and vice versa. But other components, such as VPN gateways, must be checked for their IPv6 capability and thoroughly tested. If you are using an IDS or IPS, these systems must support IPv6 and be configured for it in the scope of the migration. Ensure that the following security components are taken into consideration at an early stage in the migration to IPv6:

The last point is especially important, because quite a few management and monitoring software vendors have neglected IPv6.

DNS: Even More Important for IPv6

If the Domain Name System (DNS) is important in IPv4, it is considerably more significant in IPv6 given that the addresses are more complex. An infrastructure that uses IPv6 is typically unthinkable without DNS mechanisms. The positive news is that most DNS server implementations support IPv6, and no reimplementation of this service is required.

Instead, you only need to extend the existing zones to include IPv6 entries. It is important, however, that these entries actually exist for IPv6, because the IPv6 address will only rarely be entered. An administrator who might easily remember an IPv4 address will be overwhelmed with the more complex IPv6 addresses. Maintaining and updating the DNS systems and zones is hugely important in IPv6 and must be taken into account in migration planning.

DHCPv6 Usage Plan

Whereas the DNS service only needs to be extended, the considerations relating to DHCP are of a more fundamental nature: Through the autoconfiguration mechanism, you may no longer need to operate a DHCPv6 server. On the other hand, not all IPv6 configuration options can at present be transferred using router advertisements, so DHCPv6 might need to play a complementary role. You need to decide how hosts obtain their IP address:

Depending on how you address these considerations, you might need to plan for DHCPv6.

Hardening IPv6

One essential aspect of IPv6 migration is the security level after the migration. IPv6 comes with new vulnerabilities and challenges. The issue of security should be considered from the outset in your IPv6 migration project. IPv6 is not inherently more or less secure than IPv4. Security depends on the existing security mechanisms and technologies. There is admittedly still a knowledge deficit relating to IPv6 vulnerabilities, because this protocol is still not as widely available as IPv4, which every hacker on earth has already taken apart. On the other hand, you can set up a solid baseline, taking into account some basic principles, then supplement those principles with additional measures if necessary.

I have already addressed the most obvious issue: After eliminating NAT, the network firewall is now the only protection against attacks from the Internet in some environments. The firewall configuration thus assumes fundamental importance. But in principle, the situation is no different for IPv4 – the firewall is the designated protection mechanism, not the NAT device – and the usual firewall configuration rules also apply to IPv6: as much as necessary, and as little as possible.

You might need to make sure other security components are IPv6 capable. Proceed carefully and study each component: For instance, your intrusion prevention system might prevent some forms of attack in IPv4, but not detect them in IPv6.

First hop security is another important consideration. First hop security refers to measures taken on a switch on the local subnet, as close as possible to the device, to establish protection. Potential attacks include RA-Guard, DHCP snooping, and ARP spoofing (neighbor discovery inspection). Since various IPv6 features are based on neighbor discovery, the first hop is very significant for security, and you need to examine it in the context of migration planning. Unfortunately, not all access switches support these features, so you'll need to weigh the costs and benefits carefully.

Conclusions

Migrating to IPv6 is a complex undertaking. The complications and potential problems associated with IPv6 migration make it all the more important for network managers to receive training and be fully informed. Start early, plan carefully, and test extensively. If you can, take your time during the changeover to acquire the necessary knowledge and know-how. Staff training is a central issue and a step you should take right at the beginning of your IPv6 migration planning.