Picking up from the topic of my last article titled “From IPv4-Only to Dual-stack to IPv6-Only: What Tech Will You Need?” we are going to cover what technologies are required when dealing with a dual-stack IPv6 network. This is likely the majority of networks out there (or soon to be in the near future) so it is important to understand what tools you have at your disposal.
To summarize the last article’s premise, there are operational challenges running a dual-stack network and you need to know where you are at on the adoption curve to understand what technologies will provide you the greatest value and flexibility in adopting IPv6. These technology decisions will impact your design and ultimately your path to IPv6-only.
Assuming you have made the decision to move past the IPv4-only phase and to start implementing dual-stack then some key questions come up that should be addressed. In this article, I am going to limit the discussion to technologies that would be of interest to enterprises and smaller businesses. There is a broad and extensive set of technologies available to service providers, telecommunication and hosting providers that are not tailored to the needs to most enterprises and small businesses.
Dual-stack phase:
The company IT executives made the decision and now you are being tasked with coming up with a plan for getting the company entirely dual-stacked and working with both IPv4 and IPv6. Let us establish some ground rules about dual-stack so we all start with the same assumptions.
- Not all equipment or systems in your network will support IPv6
- You will need to provide a transition method for those systems that are “stuck” on IPv4-only as a protocol
- If the system that does not support IPv6 is simply some IPv4 network equipment it may be possible to tunnel IPv6 within IPv4 until you can replace the equipment
- If the system that doesn’t support IPv6 is a host of some kind then a translation technology will be needed
- Dual-stack will ALWAYS consume more memory, CPU, bandwidth and other resources than running a single IP stack
- Dual-stack requires extensive testing and validation (just like ANY new technology you would deploy)
- You will start by moving a small, tightly controlled segment of the overall network to dual-stack
- You have to decide if you want to configure dual-stack from the edge back to the core or from the core out to the edge
- You will need to provide training and education on how to troubleshoot, test and validate application and protocol behavior on a dual-stack network
Now that we have this basic understanding, let us talk about the things you need to do for a dual-stack network to protect it and optimize it in regards to IPv6.
- Just like with IPv4-only, put in place First Hop Security (FHS) measures for IPv6 to ensure that a misconfiguration or bad actor cannot put their own RA on the Ethernet Layer-2 segment
- Have inspection systems in place looking for IPv4 and IPv6 traffic and monitor that traffic
- Proactively set up link-local and global unicast network addresses on major network equipment (So you can monitor and alert on systems even if IPv6 has not been utilized yet).
- Allow the correct ICMPv6 traffic in your ACLs to allow for the proper functioning of Neighbor Discovery (including components like Path MTU Discovery)
- Inspect IPv4 and IPv6 traffic for IPv6 and IPv4 tunneled traffic
- Modify (or choose) your DDI platform to handle IPv4 and IPv6 values
- Make sure to utilize global unicast addresses and provide stateful packet inspection (firewall) your traffic
- Avoid unique local addresses (ULA) unless you have a well-established use case that has been validated by an IPv6 professional
- Provide access to IPv6 resources from IPv4 only hosts (via a translation method)
- Provide access to IPv4 resources from IPv6 only hosts (via a translation method such as DNS64/NAT64)
There is a lot to cover in the list but we are going to focus on the last two points. The last two really address the specific technology discussion about what you need to support each protocol effectively.
The major IPv6 transition technologies are either tunneling or translation-based. For these last two points, tunneling really is not an option as the host systems are single-stacked in either IPv4 or IPv6. Because IPv6 is not backwards compatible with IPv4 there is no simple way for the networking protocol itself to accommodate the translation. Often this would mean running a proxy of some kind to solve this shortfall. There are several pseudo-proxy-like technologies available for dual-stacked networks to accommodate exactly this situation. They are:
SLB64
SLB46
DNS64/NAT64
Each provides a unique solution to address common situations and they are well supported in many dual-stack hardware and software solutions available today. Let us run through each one and review its use case and where it fits on the adoption curve.
Server Load Balancer – IPv6 to IPv4:
SLB64 is designed to provide IPv4 resources to IPv6 hosts by hiding the IPv4 addresses behind a virtual IPv6 address. The virtual IPv6 address is advertised via DNS for IPv6 hosts to reach that resource. This technology can be used for internal resources but also for external resources. Often, this is where many companies start with enabling their Internet edge services and making them available via IPv6. This is typically done on some sort of application delivery controller (ADC) or what we used to call a load balancer. Products from F5, A10, Citrix and others are capable of doing this and if you are utilizing code from the last three years or sooner, you can likely enable this function. Realize that this solution comes with all the typical caveats that any load balancing solution does: You lose some end-to-end host visibility; not all software applications will necessarily work; and you will need logs from the ADC to understand what sessions are being mapped to correlate information in log files (the firewall log that has IPv4 NAT to an ADC log of a virtual IP and then to a Syslog of a real IP of a host is an example). These aren’t horrible tradeoffs and this is why so many start with a SLB64 solution. It really does address many needs for companies at a cost-effective price point and, as a result, is often one of the first transition technologies used.
Server Load Balancer – IPv4 to IPv6:
SLB46 is the reverse of SLB64. It is designed to provide IPv6 resources to IPv4 hosts by hiding the IPv6 address behind a virtual IPv4 address. The virtual IPv4 address (VIP) for the resource is advertised via DNS for IPv4 hosts to reach. Typically, this is implemented later in the IPv6 adoption curve because in the early stages of IPv6 adoption it is rare to have an IPv6-only device on the network. If everything new is just adding IPv6, everything operationally already has IPv4 and so should be accessible to an IPv4 host (security considerations taken into account). I have normally seen this become a concern later in the dual-stack lifecycle when either IPv4 address constraints or a technology constraint means a portion of the network is IPv6-only. At that point, some translation is required and SLB46 is a good option. It can be run on the same device as the SLB64 solution and again has all the same caveats of using an ADC. It also benefits from an attractive price point due to the likelihood a company already owns an ADC capable of doing this function.
DNS64/NAT64:
Finally, we have DNS64 and its complimentary proxy function NAT64. This service is strictly a solution for IPv6-only hosts to reach IPv4-only destinations (for instance, network resources that are IPv4-only or IPv4-only websites on the Internet). It is commonly deployed in networks as they transition to a larger percentage of IPv6-only hosts and those IPv6 hosts need to talk to localized IPv4 resources that are not able to be dual-stacked. The quantity of IPv4 host end-points are either too large to accommodate SLB64 or they are too distributed to justify deploying that many ADCs. There may also be some architectural requirements for the stateless operation of NAT64 with DNS64, requirements that preclude the use of the more stateful SLB64. This means DNS64/NAT64 can technically be deployed and work even with asymmetrical routing. With that being said, I know of no implementations that actually leverages that function of the technology outside of localized High Availability (HA) to survive hardware device failure. The nice attributes of DNS64/NAT64 are that it scales well and can be relatively easy to implement with commercial OS software or in conjunction with router and DDI technology.
Figure 1 – DNS64/NAT64 explained
Those are the common transition technologies you will likely employ during the course of dual-stacking your network. You may start with an SLB64 solution to get a few key services up and working on IPv6. You might then start having portions of your network move to IPv6-only and give them ready access to the IPv4 hosts you can leverage using DNS64/NAT64 to scale and grow. As IPv4 diminishes on your network you can introduce SLB46 so that the islands of IPv4 hosts can access the more prolific IPv6 services you will operate.
That covers the second phase or dual-stack and the technologies you will likely leverage. In the next article we will be covering IPv6-only and what technologies you will have to adopt to ensure your network is running at its best.
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now!
– Ed
