Here is the standard question to start with. Why should I migrate to IPv6 at all? Everyone’s been saying that I need to migrate for years, but I still haven’t had to. Why start now?

Well, it’s true. We’ve been running out of IPv4 space for a long time. Technically, we’ve already run out, as IANA have allocated all remaining blocks to the RIR’s. But unless you’re growing rapidly, you may find that there’s enough IPv4 space available for you. You have to evaluate this for yourself.

That said, here’s the standard list of reasons to consider migration to IPv6:

• IoT is getting bigger and needs more addresses than IPv4 can provide
• You can eliminate NAT. There’s no NAT (in the traditional sense) in IPv6
• There is no need for private IP spaces (like RFC 1918)
• Your customers may want to use IPv6, and you need to support them
• There may be a government requirement for IPv6
• You’re trying to pass an exam that includes IPv6 

Now that’s out of the way, let’s look at the approach to migration and the technologies that we can use.

Have a think about how you want to migrate to IPv6. Don’t just jump right in. There’s probably more to it than you realise.

Here, we’ll look at each of the migration phases in detail. You may notice that this maps to Cisco’s PBM model.

1. Discovery
2. Assessment
3. Planning and Design
4. Implementation
5. Network Optimisation

The discovery phase focuses on the business. The key here is to identify business goals and drivers. Why do we want to use IPv6? What is the impact on the business if we do use IPv6? What’s the impact if we don’t?

The project needs justification in a business case. Consider the time-frame for the project, government or industry compliance, and site geography.

Some justifications that you may want to consider include:

• If you are a service provider, you may need IPv6 to expand, and your customers may need to you support it
• Is the business expanding into countries where IPv4 space is hard or expensive to get?
• IPv6 is cheaper (per address) to register than IPv4
• Are there compliance requirements in your industry?
• Do you provide a web front-end to your customers? Does this need to support IPv6 for the growing mobile market?

Next, establish the project team. This is not just network people. This can include application support, customer account managers, and sometimes legal.

It may be tempting to skip this stage. Try to avoid the temptation. This is where we identify potential show-stopper issues before we run into them.

Here, we need to check what issues we may face:

• Is there any equipment that does not have IPv6 support?
• Does some equipment support partial IPv6 features? For example, IPv6 transport may be supported, but OSPFv3 may not
• Is any additional licensing required for IPv6?
• Are there any applications that use hard-coded IP addresses?
• Do the technical and support staff understand IPv6? Is a training plan required?

Start by getting (or planning to get) your IPv6 addresses. This means that you need to decide if you want to use PA or PI addressing. PI is recommended, as IPv6 gets deep into your network. It can be hard to migrate away from provider assigned IP’s later.

Next, select a place to start the deployment. Do you want to start at the edge and work toward the core? Perhaps starting at the core and working out is better? Maybe an IPv6 island is what you need?

The place you start impacts the migration strategy you use. Dual-Stack is usually the recommended approach in most cases. If you start in the core or with an island, you may need tunnelling. More details on the migration technologies are coming soon.

Consider how you will be assigning addresses to hosts. There are several options here, like DHCP, SLAAC, and manual. There will be more detail on this later.

At the end of this phase, you should have a detailed design. Check that this is in line with the business drivers that you identified earlier. The design should include areas like:

• Addressing
• LANs, WANs
• Security
• Anything else relevant to this network/business

Here’s the fun part that you’ve been waiting for. This is where you start deploying IPv6.

Part of this is an execution strategy. For example, can you start in the lab? How are you going to test the results of the changes? What’s your change management process? How will this affect your security policy? Consider a process where users can give you feedback on their experience.

It’s recommended to start with a small deployment first. Once you iron out the bugs and get that right, you can take the experience you gain to the rest of the network.

This is a continual process. This requires monitoring of the process, feedback from users, and tuning the network.

There’s no one right way to do your migration. There are several tools at your disposal, and you need to select the ones that suit you. When deciding on the tools to use, consider how they align to your deployment strategy. Which ones are your staff are able to support?

The migration tools fall into three basic categories. Dual-Stack, Tunnels, and Translation. Be careful to avoid the older deprecated tools like NAT-PT.

Where possible, the first choice should be Dual-Stack. This is where all devices run both IPv4 and IPv6 simultaneously. Changes to one stack does not affect changes to the other stack. You can see here how important the assessment phase is. Using dual stack everywhere requires all devices to fully support IPv6.

Using this method needs a little more resources from your devices. On top of this, you may need to run a different IGP. For example, if you currently run OSPFv2, you will need to use another routing protocol, such as OSPFv3. Some IGP’s support both IPv4 and IPv6 with address-families, simplifying the configuration. One line of reasoning is that it’s better to keep the IGPs (and therefore control planes) separate. This way a problem in one does not affect the other.

Clients often prefer the IPv6 path when available. At least, this is true at the Operating System level, as the applications may follow their own rules. This is true in DNS as well, as clients will search for AAAA records before A records.

In fact, DNS plays a critical part in IPv6 deployment. The good news is that you don’t need an IPv6 enabled DNS server to return AAAA records. IPv6 is only needed in the payload. The underlying transport used to deliver the information to the client may still be IPv4.

When evaluating Dual-Stack, consider:

• Some network devices have limited TCAM space; running IPv4 and IPv6 may exhaust this space
• Can the network devices handle extra throughput?
• Do the security devices (such as firewalls and IPS) have the same features for IPv6?
• Are there legacy applications that will not work with IPv6?
• Are there any old devices that do not support IPv6?

The basic procedure to use Dual-Stack:

1. Enable IPv6 Routing
2. Enable IPv6 CEF
3. Add IPv6 Addresses to interfaces
4. Create DNS records

Tunnels are used to connect different ‘islands’ through the network. You may have a few IPv6 networks that need connectivity over IPv4, for example. The alternative can also be true. In the future you may be using IPv6 everywhere except a few small legacy IPv4 islands.

Be aware that tunnels may present a challenge for security devices. Some devices will get ‘confused’ by the extra header.

The basic tunnel options are:

• Manual
• Tunnel Broker
• 6RD
• DS-LITE
• LISP
• ISATAP

A manual tunnel is like a VPN without the encryption. This could be done as a GRE tunnel, or an IPIP (IP over IP) tunnel. DMVPN (GRE multipoint with IPSec) is also an option. As you can imagine, there are pros and cons to each option.

GRE supports multicast, while IPIP does not. But, it has a bigger header, reducing your MTU. GRE is a good choice if you have IS-IS, as it can carry non-IP traffic. IPIP encodes the IPv6 address in the IPv4 header.

A manual tunnel is a suitable choice for connecting a small number of islands. If the number of islands starts to grow, this solution becomes less manageable.

A tunnel broker is a service provider that offers IPv6 over IPv4. You use your IPv6 enabled devices to build a tunnel to the provider. The tunnel runs over an IPv4 underlay network. Then you access the IPv6 internet over this tunnel.

This is an option if you need to access the IPv6 internet, but cannot implement IPv6 at the edge of your network. This option comes with increased OpEx costs.

6RD (Rapid Deployment) is so ISP’s can get IPv6 to their customers quickly. In this technique, IPv4 is still used at the provider’s edge.

There are two parts to this approach. The 6RD Router is a CE device (on the customer premises), which is IPv6 enabled. This router builds a tunnel to the 6RD Border Relay in the provider network.

This limits the CapEx requirement for the service provider. They can support IPv6 without replacing equipment everywhere.

DS-LITE (Dual-Stack Lite) is where the transit network is based on IPv6, but we still need to support IPv4 hosts. Simply put, it tunnels IPv4 over IPv6.

DS-LITE encodes IPv4 addresses into IPv6 addresses. Carrier-grade NAT translates the address back to IPv4 before it enters the internet.

LISP, or Locator ID Separation Protocol, is an overlay technology. It runs layer-3 over layer-3. IP traditionally does not handle mobility well. It does not have any geographic information built in. LISP was built with this mobility in mind.

To accomplish this, LISP uses an address for the host, called the Endpoint Identifier (EID). Also, there’s an address for the location, called the Routing Locator (RLoc). These generic addresses can contain IP address information. This is tunnelled over the underlay network. This is why it can be useful in IPv6 migration.

Consider using LISP when there are several IPv6 islands. It does not have the same scalability concerns that manual tunnels have. This is useful if there can be no changes to the underlying infrastructure. The downside is that you need to know LISP to use this solution.

ISATAP uses a dual-stack host, that connects to an IPv6 gateway. The host uses DNS to discover the location of the gateway. It then builds a tunnel to the gateway across the IPv4 network. From here, the host can access IPv6 addresses.

The upside to this is that it allows end-to-end control, which is good for security.

The downside is that it doesn’t scale well, it doesn’t support multicast, and it doesn’t support NAT.

Translation is particularly useful on the edge of the network. This is useful when connecting IPv6 devices to the IPv4 internet, or IPv4 to IPv6. Tunnelling is preferred to translation when inside the network.

Translation services rely on DNS working well. It’s not a suitable solution when your application has hard-coded IP addresses.

Translation services include NAT64, DNS64, and SLB64.

NAT64 is the primary mechanism to translate between IPv4 and IPv6. This can be stateful or stateless.

A stateful connection allows connections initiated with IPv6 to access IPv4. This uses a pool of IPv4 addresses on the outside, making this similar to port overloading.

Stateful NATs use a 1-to-1 relationship. This allows communication to be initiated in either direction. This makes it particularly useful for accessing IPv6 servers from an IPv4 network.

Some downsides to NAT64 is that it can break HTTP headers that use client IP’s (such as X-Forwarded-For). An appliance that can do rewrite can solve this problem.

Also, NAT64 can look like a DoS attack to some security devices. This is because many services may be accessed continually from a single IP address.

DNS can be used to synthesize AAAA records where they don’t exist. This works along with a NAT64 device.

Think of an IPv6 client trying to access an IPv4 server.

1. The client queries the DNS64 server for an AAAA record
2. The DNS64 server queries the authoritative server, which reports that there is no AAAA record
3. The DNS64 server gets an A record instead
4. The DNS64 server creates a fake AAAA record, which includes the IPv4 record, and returns it to the client
5. The client begins communication with the server
6. The NAT64 device intercepts the traffic and translates between IPv6 and IPv4

Server Load Balancing is useful when presenting a front-end to the IPv6 internet. The idea behind this is that a load balancer (such as a NetScaler) is configured with an IPv6 frontend. The backend services are still all IPv4.

This is a bit like using NAT64 but is deployed on an application basis.

This is a short-term solution but is suitable when there are legacy applications.