IPv4 to IPv6 without going through IPv5

We are talking about IPv6 lately because we are running out of IPv4 and we increasingly need more and more IPs for the new area of Internet of Things (IoT). It's a fact that the IP next generation (IPng) protocol and the IPv5 experimental protocol are not so well known by IT engineers but what we should know is about the IPv6 protocol like addressing and subnetting, stateful and stateless autoconfiguration, IPSec support, the new anycast packets, transition mechanisms, etc.

I want to highlight transition mechanisms used by main technology companies like Akamai, Google or Cisco because, maybe, as a network engineers, we'll have to participate or migrate IPv4 to IPv6 networks in the future.
  • Dual Stack: This is the most advisable way to migrate from IPv4 to IPv6 because we can do it periodically and progressively. However, all devices should support both protocols, IPv4 and IPv6.
Dual-Stack transition mechanism
  • NAT64: This is a transition mechanism based on Address Family Translation (AFT), which is a NAT technique similar to the traditional NAT for IPv4. In addition, all devices should be behind a NAT64 router.
NAT64 transition mechanism
  • 6to4 tunnel: This is another method to connect two IPv6 worlds separated by IPv4, where boundary routers make a 6to4 tunnel against each other. They are going to use the prefix 2002::/16 where the IPv4 tunnel address is identified inside the IPv6 domain.
Tunnel transition mechanism
  • ISATAP: or Intra-Site Automatic Tunnel Addressing Protocol is an extension of the dual stack mechanism, because it relies on dual stack nodes to make the migration, and it also uses tunnels. However, the ISATAP mechanism is often criticized because it depends on the DNS protocol to know the Potential Routers List (PRL). As a result, a layer 3 protocol needs a higher layer protocol to work properly, which is a violation of network design principles.
ISATAP transition mechanism

Next, we can see an example of 6to4 tunnel transition mechanism along with the network diagram and the configuration for Alcatel-Lucent Omniswitch:

6to4 transition mechanism diagram
VLAN configuration for both switches:
vlan 40 → Backbone
vlan 50 → Acceso

Interface tagging configuration for both switches:
vlan 40 members port 1/1/10 tagged
vlan 50 members port 1/1/41 untagged

IPv4 configuration for SW1:
SW1# ip interface "intf40" address mask vlan 40

IPv4 configuration for SW2:
SW2# ip interface "intf40" address mask vlan 40

IPv6 configuration for SW1:
SW1# ipv6 interface "intf50" vlan 50
SW1# ipv6 address 2001:db8:1100:1000::/64 eui-64 "intf50"
SW1# ipv6 address 2002:c633:6489::254/16 "tunnel_6to4"
SW1# ipv6 interface "tunnel_6to4" admin-state enable

IPv6 configuration for SW2:
SW2# ipv6 interface "intf50" vlan 50
SW2# ipv6 address 2001:db8:b000::/64 eui-64 "intf50"
SW2# ipv6 address 2002:c633:6488::253/16 "tunnel_6to4"
SW2# ipv6 interface "tunnel_6to4" admin-state enable

Static route configuration for SW1:
SW1# ipv6 static-route 2001:db8:b000::/64 gateway 2002:c633:6488::253 metric 1 tunnel_6to4

Static route configuration for SW2:
SW2# ipv6 static-route 2001:db8:1100:1000::/64 gateway 2002:c633:6489::254 metric 1 tunnel_6to4

PC1# ping6 2001:db8:b000::1
PC2# ping6 2001:db8:1100:1000::1

Once we have tested the 6to4 tunnel, we can analyse network packets to see IPv6 encapsulation through the IPv4 network:

SW1# port-monitoring 6 source 1/1/10 enable timeout 10 capture-type full

6to4 transition mechanism wireshark packet
We have heard a lot about there aren't enough IPv4 addresses but it seems that IPv4 is going to stay for a long period of time and, in the meantime, both protocols will have to coexist.

Regards my friends, and keep studying about IPv6 too because it will come.