IPv6

As of a couple of weeks ago, I began my adventure into IPv6. My ISP does not currently support native IPv6, so I used Hurricane Electric’s (HE) tunnel broker service http://tunnelbroker.net. I also opted to use their DNS service (minimally) and start their IPv6 certification process. While they have some documentation it is still a bit lacking. I had to fill in some gaps, but overall it’s enough to get started. There is plenty of documentation out there about IPv6 and even how to get it setup for your home router, so I’m not going to duplicate that effort. Instead I’d like to take a look at the packets and supposed performance benefits of IPv6.

 Setup

But first, it is worth noting my overall experience and a couple of “gotchas.” After setting up my account at tunnelbroker and assigning myself a /48 (who doesn’t need a septillion addresses!?) for my LAN and DMZ, I setup my router using stateful addressing and multiple subnets. Being that every device is Internet accessible it is important to establish the proper firewall rules as well. I currently own a Ubiquiti router which has separate rules for IPv4 and IPv6, so make sure to check yours. On a side note, this led me to finally switch from an ACL based firewall configuration to a zone-based firewall. Much better! A couple of important things I learned through this process are that IPv6 requires ICMPv6 for proper connectivity as well as protocol 41. If having ICMP wide open on your network still concerns you, there is an RFC specifically for filtering these messages in firewalls. Once my router was setup, I visited ipv6-test.com. After a few attempts I was able to achieve a 20/20.

 Performance

I heard rumors of performance gains with IPv6, so the next item on my agenda was basic performance testing. I started simply by visiting ipv6.google.com and facebook.com (a cookie banner will appear). Upon initial load, I didn’t notice much of an increase. Then I headed back to ipv6-test.com to run their speed test. Again, there wasn’t much difference. In fact, in a couple of the tests IPv4 loaded faster. This led me back to the web to search for other testimonials, blogs, etc. That’s when I stumbled upon this blog: https://blog.apnic.net/2016/08/22/ipv6-performance-revisited/. I was pleased to see the author using traceroute, analyzing paths and latency, reviewing the TCP handshakes, testing geographic regions and more. I was satisfied so much so that I decided the personal value and tradeoff in time was not worth me performing those same tests. So, for now, that is the best reference I have found yet in regards to performance of IPv6. As predicted, the overall performance does not seem to be improved over IPv4, except for a few minor edge cases such as better routing.

Practical Application

After dashing my hopes of an even faster Internet experience, I turned back to my own use cases for IPv6 and how I might utilize its potential. One Internet-facing service I run is a personal instance of OwnCloud on a RaspberryPi. The Pi pulled an IPv6 address as soon as I enabled it on my router, so I setup a AAAA record in DNS, waited a few minutes, and voila, my first-ever IPv6 enabled site. The “Explorer” badge from HE that I have attached to this post proves that I successfully setup my site. As does this badge:

First Packet Capture

As always, my next step is to dive into the packets to see what this protocol is doing “under the hood.” Wireshark has quite a few filter options for IPv6, so it will take some time to review them, but I imagine many of them are similar to the common IPv4 ones.

The first changes I noticed are the simplified header and the larger header size due to the 128-bit addresses. This is visually much easier to scan than V4.

Then, I could tell I was going through the tunnel as my MSS (located under the TCP Options) was slightly restricted. In the rest of the capture the V4 is 1460 bytes or higher.

From here, I just did some general traffic scanning. Of course, the session started with a DNS request (via my IPv4 network initially). The responses were timely and I noticed the responses included the IPv4 (A) and v6 (AAAA) addresses.

This was followed by a standard ping test. Again, remember that ICMPv6 must be allowed through your firewall (though this was legitimately a ping).

There was also a test for fallback to v4:

I then took a look at the conversations list (it was neat to see the IPv6 tab with an entry!). There were 8 streams with this site with a handful of packets all on port 80 or 8080, so it was pretty typical.

One of the streams of their v6 testing:

For kicks, I looked at the I/O graph and noticed a 1.7Mb spike, but nothing too shocking.

Lastly, I looked at the IPv6 statistics as that is another option I haven’t had before. The “NONE” protocol type peaked my interest. The only 5 packets sorted by protocol that I can find to possibly match are 5 arp requests. I’m not sure why Wireshark would label this as “NONE,” but I’m not going to dig much more into such a simple capture file.

Overall, this was a pretty fun mini-project. I was able to setup a new service (Hurricane Electric), start their IPv6 cert process and challenges, revamp my firewall rules, explore new areas in Wireshark, and now I’m able to assist in testing the launch of an IPv6 VPN project that is just starting. Now I just have to convince my ISP to provide IPv6 natively!

[UPDATE]

Since first posting this, I completed Hurricane Electric’s program and am now a Sage level. I am awaiting the arrival of their T-shirt. I’ve also read the book “Practical IPv6 for Windows Administrators.”

Also, I’ve learned more about IPv6 and Path Maximum Transmission Unit Discovery (PMTUD). One of the more common performance problems I face revolves around MTU and MSS sizes. It seems IPv6 pushes packet size negotiations to the clients instead of the network devices. Being that ICMP messages revolving around PMTUD are now required; once fully implemented, this should result in fewer MTU issues! IPv6 also raises the minimum MTU to 1280. Overall, I’m seeing some wins for network performance!