IPv4 exhaustion has required network operators wanting new blocks of addresses to acquire them at increasing prices via the transfer market. While this hasn’t stopped some larger organizations with deep pockets, it’s required others to take one of two paths to expand their network: stretch the IPv4 addresses they have by deploying Carrier Grade Network Address Translation (Carrier Grade NAT) or deploy an IPv6-only network.
Carrier Grade NATs are network devices that translate private addresses to public addresses in much larger network deployments. While network operators can deploy a Carrier Grade NAT solution relatively fast, it has a number of drawbacks, specifically introducing extra functionality and additional network components. These extra network components can impact network performance and place the company at a disadvantage.
Read: The trouble with NAT
An IPv6-only network is one that has no IPv4 provisioned to the devices on the network. IPv4 hasn’t been removed from the network devices entirely, it’s just not used by the devices. No IPv4 addresses are assigned using Dynamic Host Configuration Protocol (DHCP), or manually on the devices. There are no IPv4 routes to the network, and an interface that generates IPv4 traffic will not have that traffic leave the network.
Moving to an IPv6-only network makes the most economical sense for the future, but legacy IPv4 hosts and services will continue to exist for some time. This means that operators need mechanisms that allow IPv4 packets to route through their IPv6-only network.
These so called ‘transition mechanisms’ are numerous and fulfil many different use cases, but in order to realize IPv6-only deployments, routers that implement these mechanisms need to be fully tested to ensure they will work, and work well, in an operator’s network.
Transition mechanisms — handling legacy IPv4 networks
IPv6 transition mechanisms are protocols that allow for the transition between IPv4 and IPv6 networks.
Operators are planning or are already using transition mechanisms that connect legacy IPv4 devices over IPv6-only networks. These include IETF standardized technologies such as DS-Lite, Lightweight 4over6, MAP-T, MAP-E, 464XLAT, DNS64 and NAT64.
These transition mechanisms all have different properties such as encapsulation or translation of packets, but ultimately they allow IPv4 and IPv6 devices to communicate.
Learn more about transition mechanisms at IPv6 @APNIC
What are the roadblocks when testing IPv6 transition mechanisms?
Probably the single most important priority for operators and implementers when making a change or upgrading their network is to ensure users will stay connected. This requires a great deal of testing and validation which, in the case of deploying an IPv6 transition mechanism, has some potential roadblocks. The most common roadblocks can be grouped into protocol complexity and configuration complexity.
Protocol complexity
IPv4 and IPv6 have different fragmentation rules that must be taken into account when translating or encapsulating.
DS-Lite requires fragmentation at the IPv6 layer not the IPv4 layer. In a DS-Lite deployment, a CPE (B4) often confuses this requirement, fragmenting the IPv4 packet and causing issues when the DF flag is set in the IPv4 packet. When fragmentation does occur (for example, in UDP connections) network security devices often drop the fragmented packets due to processing time or a perceived security risk.
Fragmentation issues are present when working with tunnelling mechanisms, and stateless translation mechanisms also have corner cases for dealing with Carrier Grade NAT that must be accounted for, both of which make manual testing difficult. Finding an automated testing solution to cover these cases will help detect these types of issues on a consistent and repeatable basis.
Configuration complexity
Configuration complexity leads to operational roadblocks that are often reported when deploying transition mechanisms.
Using both IPv4 and IPv6 addresses in a solution makes it difficult to track issues across an entire network. For example, Mobile Application Part (MAP) protocols have complex addressing schemes that an operator might want additional tools for to give them information about which devices have particular addresses.
Other common complexities arise when operators need to configure maximum transmission unit (MTU) configuration to avoid fragmentation as much as possible. Or ensure customer premises equipment (CPE) devices properly initialize the correct transition mechanism after a reboot or power outage.
In many cases, I’ve observed CPEs taking several reboots before re-initializing the transition mechanism. If a management protocol is used such as DHCP, TR-069 or a user-service platform (USP), a network operator needs to ensure that all the CPEs are getting the same uniform information or network outages will occur.
Roadblocks help us learn
Transition mechanisms are the bridge to getting today’s networks to tomorrow’s IPv6-only network.
Knowing the potential roadblocks helps network operators avoid them and ultimately gives users a better experience.
The overall goal is for any user, including myself and my non-networking savvy father, to enjoy seamless connectivity without ever knowing we have transitioned to an IPv6-only network.
Timothy Winters has worked on and championed IPv6 for the last 20 years as part of the IPv6 Forum’s IPv6 Ready Logo Program and has built international testing programs proving interoperability worldwide.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
I am very curious about “corner cases for dealing with Carrier Grade NAT”. Can you give me some simple examples?