Sunday, January 24, 2016

by Craig Miller

Seeing packets on the wire

Last month I wrote of tools which are useful in discovering IPv6 hosts, and prefixes on your network (see Tools of the Trade). In this post, I'd like to cover two more tools in more detail. I think of them as the X-Ray Vision tools for your network, tcpdump and wireshark.

What is there to see?

Both of these tools will allow you to see the individual packets that are flowing on your network. Each has a protocol decoder which will present the packet in an easily human readable format. Through the decoding, you will see the ethernet header followed by the IP header, followed by the UDP or TCP header (in Scapy format: /Ethernet/IPv6/TCP).

With this information, you will be able to see check the EtherType field is correct (86DD for IPv6) or the actual source IPv6 address of a packet. For example, remember that IPv6 hosts have multiple IPv6 addresses, and it may not be clear from the outset which address the stack has selected as its source address.

Overview of tcpdump and wireshark

tcpdump is the oldest, and dates back to 1987. Therefore it takes a little learning to get used to it, but the efforts will quickly pay off. Although tcpdump was initially just for troubleshooting TCP packets, it has long since been expanded to be a full fledged protocol decoder.

It is CLI-based, and therefore can be run on the far end of a ssh connection, making long distance troubleshooting possible, by actually seeing the packets flowing in a remote network half a globe away.

wireshark is a GUI (Graphical User Interface) tool which grew out of the need for an open source alternative to the very expensive Network Associates Sniffer products in the 1990s. It runs on most OSs such as Windows, Linux, and MacOS X. For those who have used wireshark for sometime, you will remember than the original name was ethereal. It has virtually replaced all the closed source protocol decoder tools, and has a very active development community.

As with any GUI-based tool, it is easier to use, with familiar menus, and easy capture start and stop buttons. Drilling down on individual packets is also quite straight forward as it uses a familiar hierarchical approach to headers (e.g. clicking the '+' displays the detail of the header).

But being GUI-based is a double-edged sword, easier to use, but harder to run when debugging a network on the other side of the globe.

Tying the two together

But one doesn't have to choose between the two. Each will read a previously saved capture file, typically in pcap format. Therefore it is possible to use tcpdump to capture on a distant network, and send the pcap file back to a local machine to be displayed with wireshark. Of course, this can get tedious if repeated more than a few times.

To have tcpdump save the capture to a file use the -w option. The following will capture 100 packets from interface eth0 to the file mycap.pcap

tcpdump -c 100 -i eth0 -w mycap.pcap

After transferring mycap.pcap file back to your local machine, you can view it with wireshark by just specifying the filename on the command line (or use the File->Open menu).

wireshark mycap.pcap

And there your remote network traffic will be displayed in all its protocol decoded glory!

Drinking from a firehose

You will quickly discover that unless you are on a small test network, you will quickly be overrun by the shear amount of packets. Like trying to find a needle in a haystack, without some sort of filter, finding the real packets of interest will be a challenge.

Capture filters to the rescue. wireshark borrowed the concept, and syntax of capture filters from tcpdump. This is good, as you only have to learn one syntax for both tools.

Since this is a blog about IPv6,the two must useful capture filters are:

ip6

icmp6

Continuing on the example above, but only capturing IPv6 traffic place the capture filter last on the command line.

tcpdump -c 100 -i eth0 -w mycap.pcap ip6

Now when you drag the pcap file back to your local machine, only the IPv6 traffic will be displayed.

Another capture filter useful in debugging the mechanics of IPv6 on your network is icmp6. You will remember that IPv6 uses ICMPv6 for many things including arp-like MAC address resolution, and Router Advertisements (RAs). To capture only the ICMPv6 packets on your remote network.

tcpdump -c 100 -i eth0 -w mycap.pcap icmp6

As I mentioned wireshark uses the same syntax for capture filters. In order to use a capture filter with wireshark one has to start a capture with options. This will open a new dialog box with a Capture Filter button. You can type the capture filter in the blank on the right, or click on the button for a selection of common capture filters.

Is anyone out there?

Of course, sniffing a switched network (or even modern wireless networks), you will quickly discover you can only see the packets destined to the host where you are running tcpdump (or wireshark). Ethernet switches conveniently switch other traffic off of your LAN connection. This is good for reducing traffic congestion, but less good if you were interested in using your X-Ray glasses on the network.

Picking a centralized location on your network, such as your router, is often the best place for sniffing the network, since the router will see any packet that is destined to be forwarded off the network.

Because the router is such a good location to debug network issues, you can often find a packet capture application for the device. OpenWRT a popular open source distribution for home routers, and conveniently has tcpdump as a installable package.

The Internet is your friend

Because tcpdump and wireshark are popular tools, there is a lot of good information on the internet. This post is not intended to be a definitive tutorial on the tools, but to help you get started looking in the right direction for debugging IPv6 networks with your X-Ray glasses. Here is a couple of good starting points.

Using your X-Ray Glasses

With these packet sniffer tools, you will see in great detail what is on your network. Using the capture filters, you can quickly debug or just explore how IPv6 is working on your network. Capture filters help you use your X-Ray Glasses wisely.

Monday, January 4, 2016

Where are we at?

by Craig Miller

The end of the year is full retrospectives to remind us how far we have come, since we last passed this spot on the earth's orbit around the sun. Why should IPv6 be any different?

For years there has been a Mexican Standoff of sorts with regards to IPv6 adoption. The ISPs didn't want to offer IPv6, because the Content Providers didn't have any IPv6 enabled sites. The Content Providers didn't want to offer IPv6 content, since there was no one to come see it, and so on.

Breaking the log jam

Slowly we are breaking that log jam. But one of the most significant examples of change is Telus, a national ISP here in Canada. This fall they turned on IPv6, and within a short amount of time, 1 out of 3 users on their network is using IPv6.

I apologize for the small numbers. But as you can see IPv6 on the Telus network went from essentially Zero, to 37% in the last six months, and really most of it was since the end of September. The State of the Internet site contains the full size graph, as well as many other providers whose names you will recognize, like AT&T, Comcast, and SurfNet (in Europe).

Applications need IPv6 too

But having content and ISPs providing IPv6 connectivity isn't the end of the IPv6 adoption story. There are also the applications. There are still way too many IPv4-only-applications in use today. I ran into one the other day on my Chromebook, SFTP File System. A nice application, allows the mounting of a remote file system over SFTP on the Chromebook. But when I tried to connect to a IPv6 address (or more correctly a DNS name mapped to only an IPv6 address), the application failed, giving a fairly cryptic error. Fortunately, this application is open source, and after inspection, it is easy to spot the IPv4-only socket call.

Help is on the way

The IPv6 Forum has published royalty free sample code (tested on BSD and Linux) to help developers, not only support IPv6 in their applications, but to do so intelligently (using non-blocking socket calls, rather than blocking and making the user wait 30 seconds for the call to fail). The sample code includes client and server examples.

Don't be left behind

With millions of new IPv6 users (who probably don't know they are running IPv6) suddenly online, there is no time like the present to start thinking about your implementation, and how you can support IPv6. Don't be left behind.