How to Find and Measure IPv6 Traffic on Your Network

My last post was all about finding IPv6 prefixes on the IPv6 Internet. I think the next natural question is “What about IPv6 traffic?” or more specifically, “What about IPv6 traffic on my network?” In this post, I’ll talk about some network tools, or instrumentation, that can be used to find and measure IPv6 traffic that is out on your network. Network instrumentation is going to be important whether you plan to integrate IPv6 into your network or not. “What?” you might ask, “why is instrumenting my network to detect IPv6 important if I’m not going to run IPv6 in my network?”

Instrumenting your network to detect IPv6 traffic is important because it gives you visibility into what is happening on your network. When you know something is there and have awareness, you can develop policies to handle and control the situation. If you are not aware of what’s going on, you are implicitly allowing it to happen which might not be in the best interest of you network’s users. Detecting IPv6 Tunnels in an Enterprise Network speaks to instrumentation mechanisms in detail, but here’s a quick overview of your options:

1. Netflow: The primary instrumentation tool that will provide visibility into IPv6 traffic is netflow. It gives you all sorts of useful information such as source/destination address, source/destination ports, number of packets, etc. There are likely some changes required to your current netflow configuration when looking to capture IPv6 information. Prior to the 12.4(20)T release of software you could use the traditional netflow configuration to capture information. In releases after 12.4(20)T, you need to use flexible netflow to capture IPv6 flow information. Another change has to do with how the netflow information is exported off of the platform. Netflow requires version 9 record formats in order to export IPv6 flow information. This only impacts the configuration on the device, but also services that access the flow information as there will be a change to the record format. Testing should be done prior to implementing IPv6 data collection and exporting of IPv6 netflow information to ensure that all services and applications that use the data are not impacted.

2. Cisco switching infrastructure: IPv6 traffic can flow on a network even though it is not enabled on the network infrastructure. The existing Cisco switching infrastructure can be used to observe that traffic and identify those hosts. In the example below, a Catalyst 6500 is used to identify IPv6 traffic. The switch itself is not configured for IPv6. It is acting simply as a L2 switch and forwarding IPv6 frames between hosts in a single VLAN. To identify the traffic the following configuration commands are used:

mls flow ipv6 full

ip flow ingress layer2-switched vlan X

With these commands enabled, IPv6 traffic that is possibly traversing the switch can be observed. The information from the flow information can then be used to identify the end systems that are configured for IPv6.

3. SNMP MIBs The key here is to figure out what MIBs need to be polled to get the proper information. For IPv6 traffic statistics and interface information, RFC 4292 and 4293 MIB implementations need to be supported. Also, keep in mind that platforms that switch IPv6 packets in the hardware path need to support counting that traffic in that path. Netflow and SNMP allow visibility to what is happening with IPv6 traffic from remote systems. Embedded Event Manager (EEM) scripts can also be created to run CLI commands and send that information to interested parties. For example, a script could be developed to send interface accounting information every 10 minutes. The Cisco EEM support community offers a wealth of information and insights into running EEM scripts in your network.

4. Access Control Lists (ACLs): While access control lists are typically used to enforce a security policy, a peripheral function for them could be to identify IPv6 traffic traversing policy enforcement points. A simple access control list (ACL) entry such as <permit/deny ipv6 any any log> will capture traffic that is flowing to the interface where the ACL is applied. Keep in mind that the “log” keyword might imply software switching of the intended traffic. Proper testing is recommended before deploying.

5. Quality of Service Policy: The existing Quality of Service (QoS) policy can also be adapted to discover IPv6 traffic that might be flowing in the network. This case is similar to using IPv6 ACLs, but in this case the QoS policy is modified to include a service class that matches IPv6 traffic. QoS capabilities are going to vary from platform to platform so this is another feature to thoroughly test before deploying.

6. Intrusion Detection/Prevention Systems: Just like ACLs can be extended to help identify IPv6 traffic, the Intrusion Detection/Prevention system (IDS/IPS) can be extended to help identify IPv6 traffic that is flowing on the network. IPv6 traffic signatures can be developed to provide an indication that IPv6 traffic is flowing on a particular area of the network. The network operations team can then follow up with additional instrumentation tools to further identify and track down the source of that traffic.

I’ve talked a lot about internal tools to identify and monitor traffic. You can also use several, publicly available tools to monitor the overall progress of traffic that is external to your organization’s network. The World IPv6 Launch measurements page has some great views into how IPv6 is progressing across the globe. Google also maintains statistics for IPv6 access to their website. Akamai and Cisco both maintain similar statistics. Hurricane Electric has a web page that shows how IPv6 integration is happening across the globe by showing sites that have registered AAAA records and networks that have IPv6 enabled.

Last but not least, I was also recently alerted (Thanks, Vesna!) to a couple of tools maintained by the RIPE NCC that can help an organization with IPv6 detection. You can use RIPEstat to locate the status of IP address ranges (including IPv6). It shows registration information as well as BGP info, and has several interfaces (e.g. web browsing, embeddable web widgets, API data calls, etc). IPv6 RIPEness measurements show how ready each “member” is and also aggregate information per country. Lastly, you can use the RIPE Atlas tool to test IPv6 site reachability.

Please note that some tools might require membership in RIPE for access.

Whether or not you plan to enable IPv6 in your network, you will need a way to verify whether or not IPv6 traffic exists in your network. There are plenty of great tools available to detect and monitor IPv6 in your network. A good start on your instrumentation is to get into the lab and test some of the tools that were mentioned in this blog.