As I discussed previously, today is World IPv6 Day and Fedora is taking part in it and holding its own Fedora IPv6 Test Day. The goal of which is two-fold: Firstly, to get more wide-spread testing of the AF_INET6 code in the distribution. Secondly, by encouraging Fedora users to get IPv6 connected today, we'll be helping participating network administrators see how their equipment will handle a ramp up in IPv6 adoption, and test their prepardness in dealing with IPv6 issues.

The main Fedora Project wiki page provides a bit more detail, but I'll try to go over a few of the details quickly and provide some helpful information.

First and foremost is to get connected with an IPv6 address. Most ISPs are not yet providing native IPv6 connectivity to clients (though the awesome Teksavvy in Canada is!) and the only way to get connected will be through a tunnel. Both Hurricane Electric and Sixxs tunnels are fairly easy to configure, and I've used Hurricane Electric before to great success. On the off chance that your ISP provides an IPv6 subnet routed through a PPP tunnel, I found a helpful guide by Henry to configure IPv6 over PPP. His experiences are on Mandriva, but a quick glance at the instructions makes me think they'll be as relevant for Fedora users. I used a slightly different approach for my home network since I'm using an OpenWRT as my gateway. If I get a chance, I'll provide directions on using pppd directly to bring up your tunnel in a follow up. As an aside, the Apple Airport Extreme (don't knock it, it was a fantastic 802.11n 5GHz gigabit AP at the time) supports IPv6 bringing up a tunnel natively, so if your network uses one of those devices you may be able to find instructions on how to use that to participate.

If you've made it this far, you should have an IPv6 address with Global scope on at least one of your network connections. Awesome! If you're following this on June 8th, you should be able to reach Google, Facebook, and other participating sites over IPv6. If not, you can try Google over IPv6 and you'll even be able to see the dancing kame, which was all the rage in the early 2000s.

If you'd like to help with Fedora IPv6 Test Day it would be great if you'd help us with a few tests, each of which is documented off the main page, and report your results by signing up for a Fedora Account and adding your results to the wiki page. You can also test your IPv6 using an online tool and follow any advice provided.

If you choose to keep your tunnel up after the tests are finished, please remember that IPv6 entirely bypasses your IPv4 firewall, as they are two separate paths right now. You should check to make sure that any rules you are using to filter things on IPv4 are also applied to IPv6. You can verify this by using "ip6tables" in place of "iptables" and treating it similarly.

Where can you go from here? Well, you could roll out IPv6 on your home network in place of using the typical RFC 1918 192.168.x.y style network and gain end-to-end connectivity between machines from anywhere on the IPv6 internet (see note above about firewalls!) It is quite nice to not have to deal with NAT and port-forwards, and remember which port is which machine in order to SSH to an internal machine behind your gateway. You could also use it with a VPN to tunnel your traffic back home, so you'll always appear to be on the IPv4 internet from home. You could also choose to go IPv6-only for some devices on your home network, and configure NAT64 using Ecdysis which presents the IPv4 internet gatewayed behind a /32 of IPv6 addresses through the magic of DNS (this is pretty neat stuff.)

As I'm writing this now around midnight on June 8th, the World IPv6 Day testing has been underway for a few hours now. Hopefully you'll take the time to read a bit about IPv6 today, if not participating in the test day.

If you are participating, there's a few things you might want to know:

First off, as I mentioned above, IPv6 is firewalled separately from IPv4 on Linux, and a different tool (ip6tables) is required to manipulate the firewall rules. You should understand what you're doing with your network firewall if you choose to advertise your IPv6 prefix to your whole network. Don't say I didn't warn you.

Secondly, and somewhat annoyingly. The "ping" command does not handle IPv6 at all, and the separate "ping6" command is required to do it. Most irritatingly, the manpage documents them as if they were a single tool. Someone should really be a dear and improve that.

Thirdly, if you advertise a prefix via radvd, as opposed to using static addressing, or just a single IP out of the prefix, you'll end up with your MAC address embedded in the IPv6 address on your interface. This may not be desireable if you'd rather not let anyone running a webserver which computer you're accessing their website from, and so RFC 4941 provides a mechanism to add a secondary (but preferred) address which is randomly generated periodically to provide some level of anonymity. Your EUI-64 derived address remains on the interface, so that you can access it in a fixed place if you know the address. I've noticed that Mac OS X (Lion at least) and Windows 7 both enable this by default, while Linux does not. If you'd like to enable it, you can echo 2 | sudo tee /proc/sys/net/ipv6/conf/$device/use_tempaddr After which you should see two addresses on your $device (probably eth0 or wlan0.)

Fourth and finally, if you want to make sure that you're communicating over IPv6, you can use tcpdump and filter to show only the IPv6 packets by running sudo tcpdump -i $device ip6 which filters the output so you only see IPv6 communications. You could further limit the automatic ICMP traffic so you only see TCP and UDP (more or less) with sudo tcpdump -i $device ip6 and not icmp6 see the pcap_filter manpage for more information on the kind of filtering you can do with tcpdump.

Go forth and test. Might I suggest some songs to test by?

Posted Wed 08 Jun 2011 12:31:12 AM EDT Tags:

Well, World IPv6 Day is underway, and nothing seems to have fallen apart too badly. Looking at some packet traces on my home network, I see that my gmail is now being served over IPv6, which is pretty cool, and I hadn't even noticed the transition. Here in red Fedora-wearing land, we're taking part too, and we'd like you, gentle reader, to help out as well.

The development of IPv6 has been interesting to watch for the last decade or so, but I had more or less put it on the back-burner as something to care about until recently when the v4 address space exhaustion made the news. Then, at the Ottawa IPv6 Summit (which was an excellently run conference here last month) I found out from Bart Trojanowski that my ISP Teksavvy was doing a demo rollout of IPv6 with a second PPPoE tunnel on its DSL service, so I decided to sign up and give it a go.

After spending most of Sunday trying to set up my OpenWRT to route both an RFC 1918 subnet and my /28 over an aliased vlan on the WRT54GS with proper DHCP for both, I finally had v4 addressing working happily and brought up a second PPPoE tunnel (maybe more on setting this up in a happy way in a future post, I couldn't get a second pppoe tunnel working in the uci config on the latest Backfire release) to route the /56 prefix my ISP had given me. This was much easier to set up, and only a quick opkg install of radvd away. Plugging in my prefix, two free IPv6 capable DNS servers OpenDNS into the radvd.conf, and my home network was IPv6 routable.

Of course, OpenWRT Backfire didn't seem to ship an IPv6 firewall by default, so that was first on the list to fix. Fortunately ip6tables is also only an opkg install away, and they provide an /etc/firewall.user shell script hook that seems an appropriate place to put IPv6 firewall rules. Helpfully, there's also an OpenWRT ip6tables page with some default rules you can base yours on.

Once that was all up and running, it was time to test IPv6 connectivity. There's an automated suite to test your IPv6 which will more than likely complain about your resolvers, however this is a fix your DNS provider must implement, unless you switch your nameservers to the OpenDNS ones above. Today, the 8th of June, 2011, is going to be an excellent time to test though, as Google, Facebook, and others will publish AAAA records in their DNS, allowing direct IPv6 access to their websites for the day (some have been providing an alternate testbed for a while now.)

One of the more pleasant things I've noticed is how well NetworkManager on my Fedora laptop has handled IPv6. At the Ottawa IPv6 Summit, an IPv6-capable wireless network was on the air, and that provided a pretty good opportunity to see how well things would work in an IPv6-only environment (not much was reachable, except the shell server I use since David Woodhouse has been fastidious about providing IPv6 tunnels to his machines.)

In a follow-up post, I'll talk a bit about how you can get set up to help network administrators test their IPv6 readiness by pitching in with Fedora IPv6 Test Day and getting yourself IPv6 enabled, either through your ISP, or with a tunnelled subnet. If you're interested, Red Hat is also providing an IPv6 info page (reachable by both protocols) with information on the readiness of Enterprise Linux. It's worth reiterating though, that this test day is mostly about testing the content providers, their networks, their IPv6 connectivity, and their prepardness. Linux distros in general have supported IPv6 fairly well (or at least as well as can be expected without large-scale deployment) in all key software for a number of years. I believe the single most important thing about today will be increasing the exposure of administrators around the world to IPv6, and hopefully educating them.

Posted Tue 07 Jun 2011 10:21:30 PM EDT Tags:

Well, I've created an ikiwiki blog. Let's see if I actually have anything interesting to say. Things look much more spartan by default than you seem to get with Wordpress, but hey, I like minimalist things. Besides, ikiwiki is nice and sensible and does static content generation, so I can simply rsync it across the internets (or more likely, commit the generated result back to a branch in the backend git tree and push it all as one.)

Posted Tue 07 Jun 2011 07:16:05 PM EDT

This blog is powered by ikiwiki.