IPv6 Migration from IPv4: a Practical Guide (with bonus)

The Internet was initially designed to support end-to-end connectivity i.e. every device/host on the Internet should be able to “talk” to every other device directly like in a peer to peer model. As such, when the Internet was conceived and IPv4 was chosen (and IPv6 was not even an idea!) as the network protocol (official “flag day” was January 1, 1983), 4.3 billion (2^32bits) IPv4 addresses seemed like a lot.

However, with the explosive growth of the Internet (mostly due to the World Wide Web and proliferation of computing devices), it became clear that IPv4 addresses will eventually run out. Several mechanisms were put in place to slow down the exhaustion of the IPv4 address space including:

• Classless Inter-Domain Routing (CIDR)
• Private IP addressing
• Network Address Translation (NAT)

At the same time, to provide a more permanent solution, a new version of the Internet Protocol was also proposed and standardized in 1998 – IP version 6 (IPv6). IPv6 uses 128-bit addresses which (theoretically) provides a LOT of IP addresses – million times more IP addresses than the estimated number of grains of sand in the world.

IPv6 Migration Concerns/Barriers

Those who forecasted the depletion of the IPv4 address space were right. Of the five (5) Regional Internet Registries (RIRs) that are tasked with allocating public IPv4 addresses, only one RIR (AFRINIC) still has IPv4 addresses to allocate and it is projected that this will be depleted by July 2018.

Note: Even though the RIRs have run out of IPv4 addresses, there are still unallocated blocks available with various Internet Service Providers (ISPs) around the world. Various RIRs also have transfer policies to move IP addresses between entities (an example here).

So if IPv4 addresses have really been exhausted, why does IPv6 make up less than 20% of Internet traffic? We will consider a couple of reasons in this section.

Effectiveness of Workarounds

CIDR, private IP addressing and most especially NAT in its different forms worked well to cushion the impact of IPv4 address exhaustion.

While this may be okay for existing organizations, a new organization may find it difficult to obtain a public IPv4 block because of the IPv4 address space depletion. Also, many organizations (e.g. Facebook) are already moving or will eventually move to IPv6. This means a lot of services (that you need access to) will eventually be reachable only through IPv6. If you are still using IPv4, you may not be able to access those services or at the very least, the quality of access may be impacted.

Side talk: As we will see later in this article, there’s something called Dual Stack, where IPv4 and IPv6 are supported simultaneously and this is the recommended approach for IPv6 transition. The plan is to support both protocols until IPv4 is eventually phased out. However, the question of whether IPv4 will ever be completely phased out remains unanswered. None of the ‘big guys’ have mentioned anything about completely phasing out IPv4 although some ISPs have stopped issuing IPv4 addresses.

Lack of IPv6 knowledge

There is a general lack of understanding about IPv6 because it is a completely different IP version (not an extension) from IPv4 and is not backward compatible with IPv4. Due to this fact, many organizations are not willing to rock the boat. Education and training can help move people past this fear.

Perceived cost implication

Since IPv6 is a “new” protocol, organizations think they will have to spend a lot of money to migrate their networks. The truth however is that IPv6 is not really new – a draft standard was released as far back as 1998. This means that most devices already support IPv6 and the perceived cost of migrating to IPv6 may not be as expensive as the real cost.

How to migrate your network from IPv4 to IPv6

At this point, we will assume you have decided to migrate your network (or parts of it) to IPv6. As such, we will discuss the steps you can follow to achieve your goal.

Project Plan, Scope and Goals

Migrating from IPv4 to IPv6 is a big deal and should be treated as such. Like any standard project, you should have a plan, define the scope and identify the goals of the project.

Looking at the goals of an IPv6 migration for example, what do you want to achieve? Some scenarios include:

• Obtain an IPv6 address block so that internal users on your network that want to experiment with IPv6 can gain access to IPv6 services on the Internet
• Enable IPv6 within your internal network only. This means that all communication within your network will be using IPv6; however, users still access an IPv4-only Internet.
• Enable IPv6 at the edge of your network so that external users can access your services (e.g. web server) using IPv6.

At this point of the migration, you would want to build the team that will be responsible for the project. Because it may be difficult to justify IPv6 migration, getting top management support is also very important for the success of such a project.

Network Readiness Assessment

The next step is to perform an audit of your network (hardware and software) to determine three major things:

1. What network components are IPv6-ready i.e. IPv6 is supported on network devices and is already activated or may need to be activated
2. What network components need to be upgraded to support IPv6
3. What network components need to be replaced to support IPv6

Let take some examples on the points above. Looking at the first point, most Windows OS already have IPv6 support. Some flavors (e.g. Windows 7 and 8) even have IPv6 enabled by default. Looking at the second instance, you may have to upgrade the IOS versions of some of your Cisco routers so that they can support IPv6. Finally, if you have some legacy systems/software that were only designed to be used with IPv4, you may have to replace those systems/software if they fall under your project scope.

At this point of the project, the cost implication of migrating to IPv6 should start becoming clear. Keep in mind that the cost should not be restricted to network devices and software only; operational costs, training and so on also need to be factored in.

Addressing Plan

The sheer size of IPv6 addresses can be quite overwhelming and as such, it is recommended that you have a plan for how you want to allocate your IPv6 address block within your organization.

Depending on the size of your organization and the ISP/RIR to which you are requesting an IPv6 address block, the block you receive will vary. Let us assume you get a /48 block from your ISP. If you want to keep with the recommendation that the last 64 bits of an IPv6, it means you have 16 bits with which to create subnets. You can divide those 16 bits into different parts representing regions, locations, type and so on.

There is a good document here that discusses IPv6 address plan in detail. One thing to note about IPv6 addresses is that you don’t have to be as conservative as with IPv4. As much as possible, plan your IPv6 addressing in such a way that it is easy to aggregate addresses thus reducing the routing table size and reducing impact on router performance.

Depending on the scope of your project, you may also need to determine how end devices will get IPv6 addresses. The possible options include:

• Manual configuration – mostly suitable for servers
• Stateless Address Autoconfiguration (SLAAC)
• Dynamic Host Configuration Protocol version 6 (DHCPv6)

Transitioning to IPv6

Most organizations currently rely heavily on IPv4 and it will not be possible to switch to IPv6 in one day. As such, there needs to be a way to transition gradually from IPv4 to IPv6. This means that in most cases, IPv4 and IPv6 will coexist and this will probably be for a long time. We will dedicate a later section of this article to transition techniques.

Other considerations

There are a few other things to consider when migrating from IPv4 to IPv6. The first on the list is Routing. The same way IPv4 had static, default and dynamic routing, IPv6 also supports all these types of routing. In terms of dynamic routing, the routing protocols we are familiar with from IPv4 are also available for IPv6 including OSPFv3 and EIGRPv6.

Note: OSPFv3 is not the same as OSPFv2 even though they are similar.

Another consideration is Security. There is a misconception that IPv6 is more secure than IPv4 but this is not necessarily true. Initially, IPsec was mandatory for IPv6 but not anymore; it is now optional. This means that IPv6 must also be made secure just like IPv4. The same security techniques apply: IPsec, ACLs, stateful firewalls and so on. This document from NIST discusses secure deployment of IPv6 at length.

Finally, Services for IPv6 need to be taken into account. One of the most important of such services is Domain Name System (DNS). With longer address length in IPv6, DNS becomes a valuable service not only for external users but also for internal users. Unlike ‘A’ records used to store IPv4 addresses in DNS, IPv6 addresses are stored in ‘AAAA’ records.

Transition Techniques

To facilitate the transition between IPv4 and IPv6, several techniques exist including:

• Dual stack: With this technique, all the network devices are configured for both IPv4 and IPv6. Even though this is the recommended approach and has many advantages, there are also disadvantages. For example, the cost of running dual-stack is increased both on the capacity of devices required and also on administrative operations. Another challenge is that all parties along the path must also support dual-stack which may not be feasible.
• Tunneling: In this case, one protocol is encapsulated inside the other protocol. For example, if you have two IPv6 networks that need to communicate with each other but they are connected through an IPv4 network, IPv6 traffic can be tunneled inside IPv4 packets and carried over the IPv4 network. Examples of tunnel technologies supporting IPv4-to-IPv6 transition include configured/manual tunnels (6in4), IPv6 Rapid Deployment (6rd) and Intra-Site Automatic Tunnel Addressing (ISATAP)
• Translation: This final technique involves translating one protocol to the other thereby allowing IPv6 hosts to communicate with IPv4 hosts. NAT64 and DNS64 are common translation mechanisms between IPv6 and IPv4.

Note: While we have discussed tunneling and translation of IPv6 over/to IPv4, the reverse case is also possible.

Lab Scenario: Configured Tunnel Example

Configured tunnels (also known as manual tunnels, static tunnels, 6in4) are not considered flexible because all the configuration has to be manually done. However, they are stable and easy to configure and troubleshoot.

Let’s take a simple lab setup where an organization has two sites. The two sites have IPv6 enabled internally but are connected together over an IPv4 network (e.g. the ISP only supports IPv4).

In this scenario, a manual tunnel can be configured between the edge routers at both sites to carry IPv6 traffic between them. Let’s look at the default configuration on the devices (without the tunnel).

INTERNET RTR
interface FastEthernet0/0
ip address 192.0.2.1 255.255.255.252
no shutdown
!
interface FastEthernet0/1
ip address 192.0.2.5 255.255.255.252
no shutdown
!


EDGE1
ipv6 unicast-routing
!
interface FastEthernet0/0
no ip address
ipv6 address 2001:DB8:ABCD:1::1/64
no shutdown
!
interface FastEthernet0/1
ip address 192.0.2.2 255.255.255.252
no shutdown
!
ip route 192.0.2.4 255.255.255.252 192.0.2.1
!

EDGE2
ipv6 unicast-routing
!
interface FastEthernet0/0
no ip address
ipv6 address 2001:DB8:ABCD:2::2/64
no shutdown
!
interface FastEthernet0/1
ip address 192.0.2.6 255.255.255.252
no shutdown
!
ip route 192.0.2.0 255.255.255.252 192.0.2.5
!

As you can see, the EDGE routers are dual-stack i.e. both IPv4 and IPv6 are enabled. On the internal interfaces (Fa0/0) only IPv6 is enabled; IPv4 is enabled on the external interfaces (Fa0/1) connecting to the ISP (INTERNET).

The configuration on the host devices (simulated using routers) are very simple – IPv6 address and IPv6 default gateway – as shown below:
HOST1
interface FastEthernet0/0
ipv6 address 2001:DB8:ABCD:1::1000/64
no shutdown
!
ipv6 route ::/0 FastEthernet0/0 2001:DB8:ABCD:1::1

HOST2
interface FastEthernet0/0
ipv6 address 2001:DB8:ABCD:2::2000/64
no shutdown
!
ipv6 route ::/0 FastEthernet0/0 2001:DB8:ABCD:2::2

At the point, we can now configure a manual tunnel between EDGE1 and EDGE2. The required configuration options include an IPv6 address, tunnel source, tunnel destination and a tunnel mode (ipv6ip). We will also enable EIGRPv6 for routing purposes (static routes can also be used).

EDGE1
interface Tunnel12
no ip address
ipv6 address 2001:DB8:ABCD:12::1/64
ipv6 eigrp 12
tunnel source FastEthernet0/1
tunnel destination 192.0.2.6
tunnel mode ipv6ip
!
interface FastEthernet0/0
ipv6 eigrp 12
!
ipv6 router eigrp 12
no shutdown
!

EDGE2
interface Tunnel12
no ip address
ipv6 address 2001:DB8:ABCD:12::2/64
ipv6 eigrp 12
tunnel source FastEthernet0/1
tunnel destination 192.0.2.2
tunnel mode ipv6ip
!
interface FastEthernet0/0
ipv6 eigrp 12
!
ipv6 router eigrp 12
no shutdown
!

Assuming everything goes as planned, the IPv6 routing table of the EDGE routers should contain the IPv6 subnet of the other side. For example, here is the routing table of EDGE1:

EDGE1#show ipv6 route
IPv6 Routing Table - 6 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route, M - MIPv6
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
D - EIGRP, EX - EIGRP external
C 2001:DB8:ABCD:1::/64 [0/0] via ::, FastEthernet0/0
L 2001:DB8:ABCD:1::1/128 [0/0] via ::, FastEthernet0/0
D 2001:DB8:ABCD:2::/64 [90/297270016] via FE80::C000:206, Tunnel12
C 2001:DB8:ABCD:12::/64 [0/0] via ::, Tunnel12
L 2001:DB8:ABCD:12::1/128 [0/0] via ::, Tunnel12
L FF00::/8 [0/0] via ::, Null0

Also, we should be able to ping between hosts:
HOST1#ping 2001:db8:abcd:2::2000
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:ABCD:2::2000, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/130/348 ms

If we capture packets between EDGE1 and EDGE2, we will see that the IPv6 ping packets (ICMPv6) are encapsulated inside IPv4 packets.

Conclusion

This brings us to the end of this article where we have discussed IPv6 briefly and some things to think about when migrating from IPv4 to IPv6.

Like any project, migrating from IPv4 to IPv6 should be planned, properly scoped with clearly defined goals. After this, a network readiness assessment should also be carried out to determine the state of the network to support IPv6.

Defining an IPv6 addressing plan early on will help with the success of the IPv6 migration project. Because of the size of the IPv6 addresses (and the assigned blocks), one doesn’t need to be as conservative with an IPv6 addressing plan.

Due to the fact that IPv4 and IPv6 will probably need to coexist for some time, several transition mechanisms are available including dual stack, tunneling and translation.

Finally, other factors like routing, security and IP services need to be considered.