Measuring IPv6 Deployment Progress

Are we there yet?

American baseball legend Yogi Berra once said, "We're lost, but we're making good time." As funny as that sounds, he made a great point. If you don't know where you are going, how do you know how far you've gone or how far it is to your destination? Similarly, if you don't have a good idea of what success looks like you might not be aiming in the right direction and putting effort toward those activities that will result in the achievement of the goal.

The same concern holds true for the journey from IPv4 to IPv6. Virtually all enterprise organizations start with a fully deployed IPv4 environment and then strive to make progress toward IPv6 deployment. Somewhere along the path, organizations move through a period of running IPv4 and IPv6 in parallel. However, organizations should not lose sight of the ultimate goal, which is to end up with a fully IPv6-only deployment.

Organizations can make this transition from IPv4-only, through dual-protocol, and eventually to IPv6-only very gradually, or they can accelerate their migration. Each organization proceeds at its own pace. This begs the question: how should we measure progress toward IPv6 deployment and how should we measure success?

KPIs for Measuring IPv6 Adoption

When an enterprise embarks on an IPv6 deployment, they will want to document an initial baseline of IPv4 versus IPv6 traffic to use as a starting point for their ongoing measurements. Enterprises are encouraged to measure IPv6 deployment progress and report deployment progress regularly. One good idea is for the enterprise IPv6 Transition Team to create an internal dashboard with statistics of IPv6 traffic measurement showing the IPv6 program's progress. The IPv6 network engineers could gather data on Key Performance Indicators (KPIs) tracking the progress of the IPv6 deployment effort. This dashboard could function much like the old "carrot and stick" analogy for motivating an ornery horse. The dashboard could recognize successes of the IPv6 deployment while simultaneously highlighting areas that are not supporting the IPv6 deployment goals. The dashboard could also communicate progress to IT leadership (whose sponsorship of the IPv6 initiative is essential).

But which KPIs are the best for measuring progress and success? There are many metrics to choose from. Possible KPIs for the IPv6 project could include:

• The number of IPv6 packets transmitted to and from the Internet.
• The number of IPv6 connections/flows/sessions/streams traversing the core network or the perimeter.
• The number of IPv6 connection source addresses observed from flow data (NetFlow, IPFIX, sFlow, Jflow, etc.)
• The number of public-facing Internet websites and applications that are reachable over IPv6.
• The number of visitors to the organization's public website accessed over IPv6 transport.
• The number of IPv6-enabled end-user mobile devices and end-nodes.
• The number of IPv6-enabled servers, sites, routers, access networks, etc.

When measuring IPv6 connections compared to IPv4 connections, it is important to remember the tipping point effect. For every connection that takes place over IPv6, there's one less connection that takes place over IPv4. As IPv6 connections rise, the number of IPv4 connections will fall, as a total percentage of the aggregate of traffic.

It is also important to consider where within the network topology to collect the measurement. For example, if sampling is done closer to an Internet connection that already has IPv6 packets flowing over it then we are going to see more IPv6 activity. If we take the measurement on an IPv4-only LAN containing IPv6-capable nodes, then we will only observe link-local IPv6 traffic using fe80::/10 and ff00::/8 multicast addresses. Furthermore, if we measure at a point on an internal enterprise backbone network of a segment that isn't sending any Router Advertisements (RAs) on its access networks, there may not be any IPv6 packets other than OSPFv3 hello messages. It's vital that the dashboard provide context to understand what your KPIs are measuring and what they are telling you.

Measuring IPv6 usage at the enterprise's Internet perimeter

It could be easy to gather statistics from the production dual-protocol Internet perimeter firewalls. Firewalls are often "choke points" in the network topology and gathering statistics at these devices can show the usage of IPv4 and IPv6 flowing through the perimeter network. Firewalls could record measurements on the raw count of IPv6 packets but also the number of IPv6 sessions. Firewalls could also record the number of VPN connections that use IPv6 which could give insight into IPv6 usage by remote users.

We could also gather statistics from our upstream ISP(s). Maybe the ISP has a customer dashboard that shows traffic statistics for the connection. That would be an easy way to capture some data if their data showed total traffic volumes along with a breakout of IPv4 vs. IPv6.

Measuring IPv6 packets traversing the core of the enterprise network

For an enterprise deploying IPv6 internally (per RFC 7381), IPv6 configuration will be performed inward from the Internet perimeter across the core of the network. IPv6 deployment will proceed to data center networks containing shared services that will need to become IPv6-enabled, and then subsequently to end-user access networks. Measurements of IPv6 traffic flowing across the enterprise backbone could be collected with any modern Network Management System (NMS). SNMP collection of the traffic volumes on interfaces should be a standard feature that is performed automatically. Most NetFlow collectors can gather IPv6 flow data and analyze that information, even if the flow data was sent from the router to the collector over IPv4.

Measuring IPv6 usage across the Internet

An enterprise may want to measure the number of their public-facing applications that have IPv6 access enabled from the Internet. The National institute of Standards and Technology (NIST) Advanced Network Technologies Division (ANTD) has a site where they measure and report on the IPv6 accessibility for U.S. Government (.gov), Industry (.com) and University (.edu) domains.

For the greater Internet, an example of this can be found in W3Techs collection of information about the usage of various technologies. They collect information about Internet-reachable websites and their usage of IPv6. W3Techs data show the percentage of the top 1,000 websites using IPv6 is now over 54%. This is evidence that the more popular the website, the more likely it is to be accessible over IPv6.

Of course, we are all familiar with how content providers can gather statistics about their visitors and if they used IPv4 or IPv6 to access the website. Facebook maintains statistics on their IPv6 accesses by their users. And no well-respected IPv6 article would dare omit Google's IPv6 Adoption statistics (which is now at nearly 45% globally).

U.S. Federal Government IPv6-Only Mandate Metrics

Much has been discussed about the U.S. Federal CIO Office of Management and Budget (OMB) IPv6 Memorandum (M-21-07), "Completing the Transition to Internet Protocol Version 6 (IPv6)" memo that was published November 19, 2020. This goes along with the U.S. Department of Defense (DOD) Directive-Type Memorandum (DTM) (DTM 21-004) memo, "Department of Defense Implementation of Internet Protocol Version 6". The focus of these IPv6 mandates is solely on counting the number of IPv6-only network-connected devices.

All U.S. Federal enterprises are required to document their progress toward these goals and submit their data in their quarterly Federal Information Security Management Act (FISMA) reports. In addition to reporting on progress against yearly milestones from M-21-07, the FISMA metrics must include: 5.1, 5.2, and 5.3 Number of GFE hardware assets (from 1.2.1-1.2.3):

• That only have IPv4 operational*
• That have both IPv4 and IPv6 operational
• That only have IPv6 operational

*Operational - means that the protocol is both supported, enabled, and provisioned with addresses that are routable internally and externally to the enterprise.

Note that 5.1 + 5.2 + 5.3 must add up to the total number GFE hardware assets from 1.2.1-1.2.3.

It has also been stated in the Federal IPv6 Task Force forums that "Dual-stack systems will not count for the memo's milestones unless they are operating in IPv6-only environments while on Federal networks."

Mobile devices used by employees have multiple wireless interfaces (Wi-Fi and 4G/5G). The enterprise networking team doesn't have control over those wireless ISPs and as the device roams, it could be on IPv4-only, dual-protocol, or even IPv6-only networks. Therefore, it is difficult to count these devices' IPv6 connectedness as a measure of a successful IPv6-only enterprise IT environment. Mobile phones may well be operating in an IPv6-only configuration, whereas residential broadband Internet connectivity is more likely to operate in a dual-stack configuration. Therefore, end-user devices that are connected outside the enterprise network, for example when people work remotely or from home, are not counted toward the IPv6-only quota.

There are several methods of determining the number of IPv6-connected hosts. An NMS may also have the ability to gather IPv4 ARP tables and IPv6 neighbor caches from the network devices and compare them to the MAC address of the end-node. A NetFlow collector/analyzer could also be used to determine the unique source addresses used to create a connection/stream/flow to determine the number of IPv6-enabled nodes.

Another option is to gather that information from DHCP/DHCPv6 servers and share that with IT service management (ITSM) and IT asset management (ITAM) platforms. For instance, Infoblox has a ServiceNow integration. Infoblox has an outbound API integration with ServiceNow to inform ServiceNow when a new device connects to the network and obtains an IPv4 and/or IPv6 address. Infoblox updates the IP address and interface IP version "Discovery Items" in ServiceNow for a particular end node in the CMDB.

Maybe it is better to count the number of physical IT hardware assets that are directly connected to the private internal enterprise network. If we only count physical devices, then do IPv6-enabled VMs running on hypervisors, or IPv6-enabled instances running in cloud infrastructure not count as progress toward the IPv6 goal? When considering IT assets that are connected outside of the enterprise network, cloud infrastructure immediately comes to mind. Cloud service providers vary widely in their support of IPv6. An enterprise might have chosen an IaaS Cloud Service Provider (CSP) that is dragging their feet on IPv6 deployment and this could limit their ability to launch IPv6-enabled workloads. If an enterprise counts internal application services then they should also count software containers. These are ephemeral and come and go at a moment's notice, making them hard to count. Counting all the software containers in IPv6-only data center network could skew the numbers of IPv6-enabled devices in an enterprise.

Summary

For most enterprises, the thought of turning off IPv4 may seem infeasible. However, before an enterprise gets too far along with an IPv6 deployment project they should consider how they'll measure progress and success. Determining what to measure early-on allows you to start to chart progress from the beginning and show progress graphs to management. Edwards Deming is often credited (or incorrectly credited) as saying "You can't manage what you can't measure." However, it is useful to measure IPv6 throughout a long-term IPv6 deployment effort.

You don't have to pick just one of these KPIs to measure. You should pick multiple measurements from multiple perspectives and keep the data gathered and graphed over a long period of time. Enterprises may want to measure both the percentage of users using IPv6 and the percentage of IPv6 packets. Sooner than later one of these data sets may contain some useful insights into how your IPv6 deployment is progressing or possibly highlight an area for improvement.

Public link

Please use the above public link if you want to share this noodl on another website.