IPv6 Weekend Update

| | Comments (2) | TrackBacks (0)

Over the weekend, I had two minor issues with IPv6.

Issue 1: Misconfigured Routing

Per my previous entry, the ITS Wiki is now IPv6-accessible. However, we didn't have networking configured quite right on the box.

When I got home, I noticed extremely high latency when loading the wiki over IPv6. It turns out that I wasn't actually loading it over IPv6. Since v6 routing was broken on the server, my browser had to wait for v6 connections to time out and then fail over to IPv4 for each request to the server.

The server is running CentOS 5. We had forgotten that on Linux, you have to explicitly configure the IPv6 default router. Technically, you shouldn't have to, since IPv6 routers multicast their address, and hosts are supposed use these router advertisements to auto-configure their routing table. The good news was that this was a one-line fix.

In /etc/sysconfig/network, I had to add:


and restart networking. After that, IPv6 worked fine.

Issue 2: Non-nameserved 6to4 hosts

At home, I use 6to4 tunneling. This lets me connect to IPv6 hosts even though my cable modem provider doesn't offer IPv6. There is a special range of IPv6 addresses reserved for 6to4 tunneling (the 2002/16 range). Since these addresses are automatically configured, they're not normally nameserved.

As I've mentioned previously, many of ET's hosts have IPv6 enabled. I tried to ssh into one of these hosts, but my connection kept getting dropped. Since I have IPv6 enabled on my laptop at home, it was trying to use IPv6 to connect to the server (which also has IPv6). However, the server uses TCP wrappers to restrict access to ssh. The ACL looks like this:

$ cat /etc/hosts.allow
sshd: .psu.edu .hsd1.pa.comcast.net

Since my 6to4 address isn't nameservered, I can't connect. As a quick fix, I forced ssh to use IPv4 (using the -4 flag). Technically, this isn't an IPv6 issue. The issue is that I have a non-nameserved IP address.

We're still investigating how best to address this in ET. We could modify the TCP wrapper ACLs to allow 6to4 addresses from Comcast's State College range, but that coudl get messy if Comcast renumbers their network.

0 TrackBacks

Listed below are links to blogs that reference this entry: IPv6 Weekend Update.

TrackBack URL for this entry: https://blogs.psu.edu/mt4/mt-tb.cgi/620


Kazriko said:

Greetings. There is one other thing that you can do to get a reverse domain setup for your use there. https://6to4.nro.net lets you define a DNS server for ipv6 reverse lookups. The tricky part is that every time your comcast IP changes you'll need to re-delegate the addresses and change your server so that it listens to the new address reverse space.

The good news though is that since radvd auto-configures your internal addresses and the bottom 80 bits stay the same, you only need to change the named.conf to the new first 48 bits and you won't have to touch the zone file at all.

It might get tricky if other people password the nro site for your dynamic ip before you get there though. I don't know if you can override it?

Derek Morr Author Profile Page said:

Thanks for this. I blogged about this when it came out - http://www.personal.psu.edu/dvm105/blogs/ipv6/2008/03/6to4-and-reverse-dns.html

I've since switched to a static tunnel from Hurricane Electric, and that's solved the problem.

Leave a comment