On 2 July 2010, I wrote about how to get IPv6 on a Windows laptop. This involved setting up gogoCLIENT from gogo6 to access Freenet6.
This did actually work, but it turned out it was not as good as it first appeared. The problem is that the Freenet6 PoP I was using (Amsterdam) seemed to keep going down. Once down it would stay down for days at a time until it was mended. It turns out that Freenet6 were aware of the problem but there was some limitation which meant that they weren't able to maintain it very well.
So I looked around againt to see what I could do. HE tunnelbroker.net was not satisfactory because they only offer classical 6in4/protocol-41 connections which do not work from behind a NATting router, at least not directly. Whilst HE tunnelbroker.net do offer a PPtP service to tunnel a public IPv4 address to a client system, over which a 6in4/protocol-41 service can then run, it is messy, extra work to use on a daily basis, more things to go wrong, and would route all my IPv4 over HE's network.
Then there was SixXS. I had previously decided I didn't want to use SixXS for various reasons, but as it was the only thing I hadn't now ruled out, I re-visited it. It turned out that I could use SixXS because they offer a service which runs over AYIYA which will work from a NATted connection.
To use AYIYA meant using the AICCU client software. This is now working, but was hard to set up. The AICCU software needs to run all the time you want IPv6 connectivity. So I had to get a shim software which would run an arbitrary program as a service. Also it wanted to use the same pseudo network interface that OpenVPN uses. So I had to arrange for a second instance of that network interface to be created.
Once this is all configured, AICCU will connect up and set up a tunnelled IPv6 connection. This is all well and good, but Windows 7 won't "believe" that it has "proper" IPv6 connectivity unless it sees a "real" IPv6 address assigned to the "main" network connection. The upshot of Windows 7's disbelief is that whilst it will allow IPv6 to work at the packet level, it will not use resolve AAAA records in preference to A records. So if you browse to a dual-stack website, you will still go over IPv4. If you go to a pure IP6 website, it will work (IIRC).
To get round this, we need to assign a proper-looking IPv6 address to the "main" interface. So we can add this to the wireless interface and also the ethernet interface. We can use addresses in the 6to4 space for RFC1918 private ranges (2002:C0A8::/32) which should never clash with a real IPv6 address but which look perfectly genuine to Windows.