Found out why firefox didn't talk ipv6 by default: the same resolver bug that I saw before: the resolver prefers ipv4+rfc1918 addresses over ipv6. Fixed with some DNS magic. Some day I'll phase out NATted IPv4 addresses. Until then they are irritating.
2008-04-15 (#)
Squid has always been my webproxy of choice. Especially at home where I need interesting proxy rules to access certain work-sites via a special route and I like to use the parent proxies of xs4all. But ipv6 support was always a problem in squid until I looked recently and found out that IPv6 support is now default in squid 3-HEAD. So I compiled it and started playing with the access-rules. What I want (ofcourse) is the dancing turtle of kame. I tried to get this by adding an acl ipv6space dst 2000::/3 and using this in specific cache_peer_access deny rules which now works after some trying. I also found that writing the acl for the local network correctly helped a lot: acl localipv6net src 2001:888:1011::/48 works, when I forgot one : at the end it didn't work and denied me access. Now to get firefox to use ipv6 to talk to the proxy...
2008-04-01 (#)
Found out the hard way: in the innfeed.conf configuration file key bindaddress6 needs its value quoted. So now inn is feeding again.
2007-11-19 (#)
Old meets new: XS4ALL now offers UUCP over IPv6. Still with the separation in the DNS, but maybe this can be the first candidate to end this distinction?
2007-10-30 (#)
I upgraded to Apache 2.2.x at home so now http://koos.idefix.net/, http://webcam.idefix.net/ and other sites at home can all be reached on IPv6 addresses. One downside: logresolve (the postprocessing apache log resolver) has absolutely no idea about IPv6 addresses.
2007-10-27 (#)
Learning ifplugd to do the ipv6 equivalent was easy: just add the following to /etc/ifplugd/action.d/ifupdown in the up part: /usr/bin/rdisc6 -q -w 250 -r 8 $1.
2007-10-26 (#)
And in trying to firewall IPv6 I found that INPUT and FORWARD are really separate. From the docs:the built-in chains INPUT (for packets coming into the box itself), FORWARD (for packets being routed through the box), and OUTPUT (for locally-generated packets).So if I want to set a policy for both the local machine and the machines behind it I need to set those rules in both INPUT and FORWARD.
2007-10-26 (#)
Trying to access machines at home directly from the outside via ipv6 made the old ndisc_send_redirect: not a neighbour show up again. I found the reason: I added an address on the internal network to the external interface, so a cool address would show and not the xs4all-ipv6-tunnel interface address, with up ip -6 addr add 2001:888:1011::13/64 dev xs4allipv6 in /etc/network/interfaces. Now when trying to access an internal machine, 2 possible routes to 2001:888:1011::/64 existed. Fix: add another line up ip -6 route del 2001:888:1011::/64 dev xs4allipv6 to remove that extra route again. Now I can access machines on the home network directly from ipv6 hosts all over the world. Time for extra firewalling rules!
2007-10-26 (#)
And the ultimate answer came from Friedemann Stoyan via the debian-ipv6 mailinglist: It's a know debian bug: libc6: Resolver prefers IPv4 to IPv6 in some cases. The bit where RFC1918 addresses trigger this bug is especially evil: in my opinion users with ipv4+nat (rfc1918) and ipv6 (globally routed) on their network would be better suited with a preference for ipv6.
2007-10-25 (#)
After working on a proposal for introducing IPv6 at work it suddenly dawned on me that pushing ipv6 at home wasn't going to work with a separate DNS zone for IPv6 addresses. The best way is to integrate ipv6 addresses in the main zone and have the "legacy ipv4 nat range" as second thing to try (for things that are still ipv4-only like nfs). But I found something weird in certain applications: for unqualified names, ipv4 is preferred, for qualified names ipv6. Forcing ipv6 works, but I want ipv6 to happen naturally. Telnet shows best what happens:$ telnet gosper
Trying 10.42.2.1...
Trying 2001:888:1011::694...$ telnet gosper.idefix.net
Trying 2001:888:1011::694...
Trying 82.95.196.202...Something weird happening here, so I asked the debian-ipv6 mailing list.
2007-06-26 (#)
Heaps of kernel messages on the home server ndisc_send_redirect: not a neighbour which is ipv6 related. I did a google search for it which found a bit by Jonathan McDowell mentioning ndisc_send_redirect: not a neighbour but the real solution for me was in the comments. Somewhere eth0 of the server had lost its IPv6 address. Doing ifdown eth0; ifup eth0 made the correct ipv6 address reappear and now the messages seem to have stopped.