Tag: ipv6

In which Mary does a lot of work on a comments policy in order to talk to herself about IPv6. True story.

Anyway, where we last left our heroine, she had found one unpromising (because unanswered) complaint describing her IPv6 problem. She tried updating the router firmware but it said it was the newest available firmware.

Some time later, our heroine found another account of the problem over on Server Fault where it was less likely to be lonely, and our heroine became convinced that she ought to install DD-WRT on her wireless router. Hey, maybe it would have worked, too. But our heroine’s husband likes his Internet to work, and gave her a sidelong look, whereupon our heroine at least deferring bricking her router until the weekend.

However! Our heroine is slightly bored of one of her day jobs, so today she idly searched for updated firmware and updated her D-Link DIR-615 router (C2 hardware edition) from firmware version 3.01 to 3.03WW (WW? I don’t get it either) and now she has a wireless router that does not send rogue IPv6 router advertisements to the network.

The end.

Background knowledge: this post requires some knowledge of networking, at least to the point of knowing what IPv4 and IPv6 are, and what is meant by subnet notation like “/60” and “/64”.

I believed for a very brief time that I’d beaten IPv6 into shape but soon my husband started complaining that sometimes it worked, sometimes it didn’t, and basically questioning whether it was worth any more late nights. (I would poke things, we would jointly debug them, IPv6 involved us skipping dinner two nights in a row in the end.)

Basically what would happen was that anything we tried to connect to over IPv6, most noticeably Google itself (because they trust Internode’s IPv6 routing enough to have turned on IPv6 access for their customers) would either work or just hang. I vaguely suspected some kind of routing error.

Here’s something to try if you have mysterious intermittent IPv6 dropouts or hangs: watch the output of radvdump closely. What you are looking for is any router advertisements coming from a second source: rogue RAs was the search term I was using somewhat in vain.

Unfortunately, if you find such a thing, there are essentially two options (much as you do if someone has put a rogue DHCP server on a network). One is to remove the rogue device from the network, the other is to firewall its announcements away from your clients. Unfortunate in my case, that is, because it emerged that the source of the announcements was our D-Link wireless router (which, per the previous entry, we run as a switch). Removing a wireless switch from our network would have the unacceptable side-effect of re-introducing strings of blue cable to our home, and it’s pretty hard to firewall your switch itself. So in our case, the answer for the present time is to give up on home IPv6.

Overall, although the reason we gave up on IPv6 was not a Linux problem, I have to say that I was really surprised how immature Linux’s tools are at this point. The fundamentals exist: kernel support, DHCPv6 and stateless configuration servers and clients. As an IPv6 client, Linux is doing OK. If you connect a Linux machine to a network that happens to be using IPv6, it’ll likely Just Work. But at the tools and packaging level there’s still loads of gaps along the lines of:

• iptables and ip6tables are entirely separate programs, so you get to have your firewall configuration fun twice! (However, UFW handles this fairly nicely, if you’re in the market for a thin-ish wrapper around iptables.)
• configuring ppp for IPv6 is like ppp for IPv4 circa 1999 or 2000 or so. Things like the “oh yeah, for a reason no one knows, you won’t get a default route, so here’s a little script that will bring one up for you” (see Shane Short’s blog entry)
• radvd is a fairly crucial tool, but there aren’t a lot of example config files for different situations that I could find, and the man page assumes that you know a lot about router advertisements already
• if you want to use Ubuntu’s supported DHCP server (isc-dhcp-server) for DHCPv6, you need to write it a second init script and config file yourself

So after all that you might be tempted to use a dedicated router for IPv6 and I’d sympathise except that the D-Link device does it even worse than Linux. Not promising. I can’t see that moving many ADSL users over to IPv6 is going to happen any time soon.

Background knowledge: this post requires some knowledge of networking, at least to the point of knowing what IPv4 and IPv6 are, and what is meant by subnet notation like “/60” and “/64”.

I’ve just changed ISPs, because I wasn’t much of a fan of my old ISP’s demand that either we enter into a new 12 month contract before 27 November or they’d consider us re-contracted at that date. My new ISP is Internode, Australia’s favourite geek ISP, in part because they offer native IPv6 and it’s even supported by customer service. It took me an entire 24 hours to succumb to the temptation of wrecking my perfectly good home network by attempting to make it IPv4/IPv6 dual stack, partly motivated by Geoff Huston’s “the sky is falling” keynote at linux.conf.au 2011. I like doing my bit to hold up the sky.

I use a Linux machine as our router rather than a consumer router device, that is, my ADSL modem is set to bridge mode and we use our wireless router just as a switch; neither of them do routing. (Or shouldn’t, but we’ll get to that.) In terms of resources for doing this with Internode, or any other ISP who will advertise your IPv6 routes via DHCPv6, here’s some useful material:

• Internode’s own guide, which is a touch sketchy but gets the basics across
• Shane Short’s more extensive write-up of Internode and IPv6

The main problem I had is that for as yet unexplained reasons, while this radvd.conf stanza worked fine when my Linux server ran Ubuntu 11.04 with radvd 1.7, it doesn’t work on Ubuntu 11.10 with radvd 1.8:

prefix ::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};


radvd 1.8 was advertising this in such a way as to get my Linux client to give this error (in /var/log/syslog):

IPv6 addrconf: prefix with wrong length 60

That is, it seems to have been advertising the entire /60 that Internode routes to each customer rather than a single /64. We ended up having to do something like this:

prefix 2001:db8:aaaa:bbbb::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};

That is, because Internode’s IPv6 allocations are static, we just manually picked a /64 out of the /60 allocated to us, and advertised that. I’m not clear if this a bug or a change in the way radvd works or a mistake of mine, we never got a chance to find out because of a showstopper which you’ll see in the next, and at this stage, final post in my adventures in IPv6.