RYAN HARRIS | Sr. Network Engineer 

This blog post is part of a series detailing the various parts of planning and deploying IPv6 for enterprise networks. It is meant as a primer for the network engineer or architect to understand the various concepts they may be unaware of when developing their IPv6 production design.  

If you have not read the previous posts, I would highly recommend that you start at the beginning:   

• Part 1 – Hierarchical Subnetting Design  
• Part 2 – Routing Design  
• Part 3 – OSPFv3 
• Part 4 – Security 

Dual Stack 

The migration of the world towards IPv6 has not been an overnight success. Of course, there has been resistance and apathy from people who either do not understand the issues arising from IPv4’s continued use or are just hoping they can kick the can far enough down the road that they will not have to participate in the migration. 

A modern enterprise network has dozens or hundreds of applications, several operating systems from Windows, Mac OS X, Linux, and embedded operating systems in printers, IoT devices, network equipment, and more. Despite earnest attempts to support IPv6 across every application and device in the network, the unfortunate truth is that there are still holdouts lacking support. The good news is that we do not have to take the leap to an IPv6-only network all at once. 

A dual-stack network is configured with both a legacy IPv4 subnet and an IPv6 network, and the operating system decides which protocol to use. This allows us to implement IPv6 on our client networks while our data center IPv6 networks are still being built and tested and allow access to IPv4-only Internet resources. 

While it may sound like dual-stack deployment is a great idea, it should not be the long-term goal. IPv6-only networks should be the end goal, and I recommend that IPv6 test environments be set up almost immediately. Long-term dual-stack networks will retain all the downsides of an IPv4 network, namely the address space limitations while having an overall higher management requirement. 

Happy Eyeballs 

One of the first questions you may have when considering a dual-stack network deployment is, “How does the operating system decide which protocol to use when connecting to a remote server?” Originally, IPv6 had priority over IPv4, and the operation system would try to connect using IPv6. Once that failed and timed out, it would try to connect using IPv4. The obvious problem is that this leads to a terrible user experience for IPv4-only services. 

In steps, Happy Eyeballs was originally defined in RFC 6555 and updated to version 2 in RFC 8305 to improve the user experience in dual-stack networks. Happy Eyeballs defines the process by which an endpoint can attempt to connect over both IPv4 and IPv6 while prioritizing IPv6 traffic. 

From a high level, an endpoint that has implemented happy eyeballs will attempt the following algorithm: 

1. Request an AAAA and an A record from the DNS server. 
2. If the AAAA record is returned first, immediately attempt to connect using IPv6. 
3. If the A record is returned first, wait for the resolution delay timer to expire (the RFC recommends 50ms) before proceeding with the connection using IPv4. If a negative AAAA record is received before the resolution delay timer has expired, proceed using IPv4. 
4. If the AAAA record is received after the resolution delay time has expired but before the IPv4 connection has been established, attempt to make a connection using IPv6. 
5. Continue with any received records until a connection is established. 

The RFC describes several other scenarios for prioritizing IPv6 connections while maintaining the ability to fall back seamlessly to IPv4. The general idea is that inserting a small delay in the establishment of IPv4 connections allows for more IPv6 connections and avoids lengthy timeouts for non-working IPv6 deployments.