Prioritizing IPv6 Enablement of Your Applications
Scott Hogg- There are tangible performance benefits to enabling IPv6 on applications.
IPv6 performs faster (on average) than IPv4 on the Internet.
- Prioritize IPv6 for public-facing applications.
- Apps that are accessed by clients that are already using IPv6 (e.g. mobile apps) would benefit from IPv6 enablement.
- Track and minimize use of stateful NAT64, and 464XLAT CLAT/PLAT traversal.
- Create a ranking spreadsheet/algorithm to make a prioritized list of the applications needing IPv6 connectivity.
Prioritize Internet Apps with Broad Internet Reachability
It has been known for a decade that IPv6 performs better, with lower average Round-Trip-Time (RTT) than IPv4 across the Internet (read Part 1, Part 2). APNIC’s statistics measure the worldwide RTT difference between IPv6 and IPv4. Subtracting IPv4’s higher RTT from a IPv6’s lower RTT yields a negative number of milliseconds where IPv6 is observed to be faster. Therefore, APNIC’s statistics show that IPv6 is faster overall than IPv4.
IPv6 connections are not routed through a Network Address Translator (NAT) and instead are routed along the most direct optimal path. On the other hand, IPv4 connections are always routed from the client through several NATs along the traffic path to the application server. These multiple NATs are also what makes IPv4 addresses only “Locally Significant.”
One must consider the perspective of the end-user (or customer) when making an application broadly accessible. It has been estimated that two billion devices access Google’s online sites each day, and now IPv6 has surpassed IPv4 becoming the most popular Internet Protocol. It is likely that Internet application users are already using IPv6. Enabling a website for IPv6 will make it faster. The same is true for DNS servers and that is why they should be made to have dual-stack connectivity.
The primary reason an organization wants to make public-facing applications use IPv6 (and run dual-protocol) is to take advantage of IPv6’s end-to-end direct routing resulting in better end-user experience. This goes for all types of public-facing services (web, DNS, and e-mail). Some large organizations may already be striving to IPv6-enable their public-facing services because of government mandates. The U.S. government issued a IPv6 mandate for federal organizations to IPv6-enable web, DNS, and e-mail servers by 2012. Then in 2020, the U.S. government published their Federal CIO IPv6 Memo, OMB Mandate M-21-07 with a goal to move to IPv6-only communications. Other countries around the world are also prioritizing the use of IPv6 and are being successful in achieving their goals.
Work to Minimize DNS64/NAT64 and 464XLAT Traversal
When a client is using both IPv4 and IPv6, it sends DNS queries for the A and AAAA records for the destination website. The dual-protocol client makes two connection attempts to a dual-protocol server using Happy Eyeballs (HEv2 RFC 8305) using IPv4 and IPv6 in parallel and chooses the best one. If the IPv4 connection is slower, because of NAT444, then the IPv6 connection will have a lower latency and will be chosen, providing better customer experience. If IPv4 and IPv6 both successfully connect and they have similar performance, then client applications will default to using IPv6. By making the webserver accessible over IPv4 and IPv6 the protocol chosen will be which is available and higher-performing from the client’s perspective.
An IPv6-only client querying an application’s DNS name still solely using an A-record would indicate that the application would require DNS64/NAT64 (RFC 6147, RFC 6146) for reachability. Alternatively, if an application has a hard-coded IPv4 address dependency, then 464XLAT (RFC 6877) could be used to perform a translation on the mobile device (CLAT) and another translation within the provider’s network (PLAT). This is Case 2 in “How to Make Your Website Faster with IPv6”.
Therefore, organizations should strive to minimize the amount of traffic that goes through a NAT64 (or 464XLAT CLAT/PLAT). Any IPv6-only client’s traffic that is going through the NAT64 or CLAT/PLAT should be a candidate for IPv6-enablement. Of course, the app team should work to avoid using any hard-coded IPv4 address in applications. Any Fully-Qualified Domain Name (FQDN) for an application service that only has an A-record should enable IPv6.
Organizations should track which apps are communicating through the 464XLAT CLAT on the client device or through the stateful NAT64/PLAT. From this data they can begin to create a list of applications with IPv4 dependencies. The application that represents the most traffic volume going through the NAT64 should be at the top of the IPv6 implementation list.
Looking at the Stateful NAT64 (or PLAT) state tables allows an organization to monitor those IPv4-only applications that represent the largest number of connections, packets, or bytes transmitted. These commands display the state table at that moment for the translated sessions that are occurring. It should be mentioned that this state information doesn’t necessarily show how much data is traversing these sessions, but rather each state table entry represents a separate connection. Organizations may want to create some type of log or extract the data to perform a longer-term analysis of which destinations are most frequently visited.
The following commands on various NAT64 (or PLAT) systems show the translation state table. These commands also show examples of how to look for all IPv6-only client connections being translated to an IPv4-only application destination. From this output one can observe how the IPv4-only address has been converted into hex and placed in the bottom 32-bits of the IPv6 synthesized address.
Cisco IOS-XE
show nat64 translations
show nat64 translations verbose
show nat64 translations total
show nat64 statistics
show nat64 translations v4 translated 64:ff9b::c0a8:0b06
show nat64 translations v4 original 192.168.11.6
Juniper SRX
show security flow session nat
show security flow session nat destination-port 443
show security flow session destination-prefix 64:ff9b::c0a8:0b06
Palo Alto Network Firewall
show session all
show session all filter destination-port 443
show session all filter destination 64:ffb9::c0a80:0b06
show counter global filter value all | match nat64
Fortinet FortiGate Firewall
get system session6 list
diagnose sys session6 list
Jool.mx
jool -i "nat64" session display
jool -i "nat64" session display --tcp --numeric
jool -i "nat64" session display --icmp
jool -i "nat64" session display --tcp –csv
Build a Prioritized List
Enterprises should start to gather data about IPv4-only applications, their connections, popularity, and performance. Organizations should build a ranked list of applications with the ones at the top of the list needing IPv6 connectivity sooner rather than later. Organizations should rank their applications based on bandwidth and enable IPv6 on the highest-bandwidth applications first. Remember, for every page that loads over IPv6, there is one less page that loads over IPv4. Moving more traffic to IPv6 should be the near-term goal, resulting in a “tipping point effect”.
Organizations should rank applications higher that are public-facing and globally-accessible by IPv6-enabled mobile devices. This will result in a performance benefit, so those IPv6-only devices won't need to use DNS64/NAT64 or 464XLAT to reach an IPv4-only site. Those dual-protocol or IPv6-only devices can reach the site using IPv6 directly, with minimal latency, no NAT backhaul, thus improving performance.
Organizations should construct a list of the most important applications for the enterprise organization. Based on the application characteristics they can determine which applications to urgently enable IPv6, and those applications that fall to the bottom of the to-do-list. The following scores will help create this ranked list.
Create a numerical scoring system for the performance benefits of IPv6-enablement
- Give a higher numerical value to those applications that are accessed by many users via their already-IPv6-enabled mobile devices.
- Give lower scores to internal private apps accessed by users on IPv4-only networks.
Create a numerical score for the number of connections
- Give a higher numerical value to applications that are accessed by many users (e.g. public Internet apps).
- Give a lower value to apps that are accessed only by a few users.
Create a numerical score for the CAPEX costs of IPv6-enablement of the app
- Give a higher numerical value to those apps that may require hardware or software upgrades with significant costs.
- Give a lower value to those apps that don’t require any hardware or software purchases or upgrades.
Create a numerical score for the OPEX costs of IPv6-enablement of the app
- Give a higher numerical value to those applications that will be very time intensive and require a lot of human effort to enable IPv6.
- Give a lower value to those applications that are easily enabled for IPv6 connectivity.
Computing the ranking score
Then organizations can perform some simple algebra to create values based on these scores assigned to the applications.
- Combine the first two scores (performance, number of users/connections). This is the amount of benefit the application derives from IPv6 enablement.
- Combine the second two scores (CAPEX and OPEX costs). This is the relative cost to perform the IPv6 enablement.
The next step is to sort this list based on the numerical calculated comparison of these two quantities.
- Those applications that result in the greatest performance benefit for the largest number of users with the least costs to enable IPv6 are those that rise to the top of the list.
- Those applications with the lower performance benefit to fewer users and possibly cost more to enable IPv6 will drop to the bottom of the list.
One can also add to this calculation a numerical score for the observations of traffic volumes of applications passing through a CLAT or a NAT64/PLAT.
Please contact me if you need help with this analysis and creating the ranking list.
Now that the organization has their ranked list, they can get started on IPv6-enablement of those apps at the top of this list and work their way down. Let’s get started!
Scott Hogg has over 30 years of network and security experience and is president of Hogg Networking (HoggNet.com). Scott Hogg specializes in teaching Internet Protocol version 6 (IPv6) and providing implementation guidance to large organizations. Scott is CCIE #5133 (Emeritus) and CISSP #4610. Scott is Chair Emeritus of the Rocky Mountain IPv6 Task Force (RMv6TF) and co-author of the Cisco Press book on IPv6 Security.
