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:

• What global unicast prefixes are available? You need to determine the scope for the address plan when it relates to systems that have public addresses.
• Do policies exist in your company group, administration, or other parent instances that need to be considered when developing the addressing scheme?
• Should the existing subnetwork structures remain for IPv6? Admins often want to retain elements of the old system; however, IPv6 also offers the possibility to correct mistakes in the old IPv4 strategy and create new structures.
• Which systems require manual IPv6 configuration? Basically, you can provide all IPv6 nodes with manual, static IPv6 addresses. This is not desirable in many environments; however, it will be useful in most IT landscapes to assign static addresses at least to servers, printers, and other active network components.
• How will the assignment be handled for systems that have no fixed IP addresses? (Options include by autoconfiguration, DHCPv6, EUI-64, privacy extensions, etc.)
• How will you ensure the tracking of dynamic IPv6 addresses and their assignments?

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.

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.

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.

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.