06/8: Happy World IPv6 day!
If you want to have an identd that can talk IPv6, you can choose oidentd.
If you are running it from inetd, you should configure your inetd to respond to IPv6 as well. I’m using openbsd-inetd, and the lines in /etc/inetd.conf to make it listen on both IPv4 and IPv6 for the auth service are:
auth stream tcp4 nowait root /usr/sbin/tcpd /usr/sbin/oidentd -I auth stream tcp6 nowait root /usr/sbin/tcpd /usr/sbin/oidentd -I
Note the protocol, which specifies IPv4 or IPv6. Also note the -I option to oidentd, to make it read from stdin and write to stdout and to exit after answering one request (needed for inetd operation).
I briefly considered nullidentd, but the description made it sound like it would only ever return one static string. Not quite what I was looking for, and I didn’t investigate further.
I found this procedure for starting to use IPv6 on a home network. It is specific to Debian and the SixXS tunnel broker. Many thanks to Martin Krafft for this very nice description that starts with the firewall rules and moves on from there.
02/13: IPv6 from SixXS
I want to get an IPv6 address from SixXS.net. The first step is to apply for an account. They gave me one. I tried to use the username/password credentials to log in, and was not able to read the page. I guess it must be xhtml, and it had some kind of error right after the head element. So all I got was a message in the browser saying that there was an error on line 14 character 8.
I tried logging in again today, and was able to see a page full of info.
I don’t know what the problem was. Could have been a problem on the remote end, or maybe I didn’t have cookies enabled. It works now, and I was able to apply for a tunnel. We’ll see what happens next!
I apt-get upgraded, and then apt-get using apt-cacher didn’t work any more. It seems if you have a perl IPv6 library installed (IO::Socket::INET6), apt-cacher will assume you have deployed IPv6 and it will make an IPv6 only connection for listening.
To make all your services obtain IPv4 address along with IPv6 ones, as root “echo 0 > /proc/sys/net/ipv6/bindv6only” and edit /etc/sysctl.d/bindv6only.conf to contain 0 rather than 1. Then restart your service(s).
Or if you do have IPv6 running locally, you can change your apt sources.list file (/etc/apt/sources.list) to refer to ipv6-localhost instead of localhost:
deb http://ip6-localhost:3142/debian.mirror.iweb.ca/debian/ unstable main contrib non-free deb-src http://ip6-localhost:3142/debian.mirror.iweb.ca/debian/ unstable main contrib non-free
(other distro’s might use another name like localhost6. Look in your /etc/hosts file for the right name.)
Another gotcha: If you install apt-cacher-ng, and you already have apt-cacher running, then apt-cacher-ng will attach to the remaining free interface (the IPv4 one) and apt-cacher will still be running on IPv6. The two packages don’t conflict. Yeargh. I can’t wait to see the cache corruption … Ah, no cache corruption. It starts its own cache — from scratch. Well better that than corruption I guess. But, even better to be running only one of them on all listening ports.
And another gotcha: Installing apt-cacher-ng might end up adding a proxy config to your apt config like so:
/etc/apt/apt.conf: Acquire::http::Proxy "http://aa.bb.cc.dd:3142";
so then if you use urls as above, you would have specified the proxy twice: once in the url and once in the apt.conf file. Apt then complains with:
Failed to fetch http://aa.bb.cc.dd:3142/volatile.debian.org/debian-volatile/dists/lenny/volatile/contrib/source/Sources.gz 403 URL seems to be made for proxy but contains apt-cacher-ng port. Inconsistent apt configuration?
The fix is to remove the proxy either from apt.conf or from the sources.list entries. Note that the proxy might have been put in /etc/apt/apt.conf.d/01proxy or something like that instead.
Well that was a lot more exciting than I’d hoped for.
If you’re running a slave nameserver using bind9 and you’re getting messages like this in your logs:
Aug 31 19:58:30 sns named: zone somedomain.com/IN: refused notify from non-master: 2002:1234:cdef::1234:cdef#13361
then the master is sending out notifies on an IPv6 address. Normally, you could just add that address to the “masters” list in the zone on the slave, but if the master isn’t listening on IPv6 you’ll get a bunch of other errors, like this:
Aug 31 07:32:33 sns named: zone somedomain.com/IN: refresh: retry limit for master 2002:1234:cdef::1234:cdef#53 exceeded (source ::#0) Aug 31 07:32:33 sns named: zone somedomain.com/IN: Transfer started. Aug 31 07:35:42 sns named: transfer of 'somedomain.com/IN' from 2002:1234:cdef::1234:cdef#53: failed to connect: timed out Aug 31 07:35:42 sns named: transfer of 'somedomain.com/IN' from 2002:1234:cdef::1234:cdef#53: Transfer completed: 0 messages, 0 records, 0 bytes, 189.000 secs (0 bytes/sec)
There are two ways to fix this: on the slave nameserver, or on the master.continue reading