Transmission 1.80 released with "Improved IPv6 support" ... still no IPv6 webinterface

Bittorrent client Transmission version 1.80 has been released. The release notes (http://trac.transmissionbt.com/wiki/Changes#version-1.80) say "Improved IPv6 support" ... what would that mean? My hope is of course that the webinterface of Transmission is now IPv6-enabled.

Ubuntu Lucid Lynx (alpha 2) has Transmission 1.80, so I've run Lucid to see if the webinterface is indeed IPv6 enabled ...

But alas: the webinterface is not listening on the IPv6 interface. See tests below; first IPv4 (OK), then IPv6 (no connection).

More waiting before we can access Transmission's webinterface over IPv6. :-(





ubuntu@ubuntu:~$ lynx --dump http://192.168.1.36:9091/ | tail -5
  10. http://192.168.1.36:9091/transmission/web/#save
  11. http://192.168.1.36:9091/transmission/web/#cancel
  12. http://192.168.1.36:9091/transmission/web/#upload
  13. http://192.168.1.36:9091/transmission/web/#cancel
  14. about:blank
ubuntu@ubuntu:~$
ubuntu@ubuntu:~$ lynx --dump http://localhost:9091/ | tail -5
  10. http://localhost:9091/transmission/web/#save
  11. http://localhost:9091/transmission/web/#cancel
  12. http://localhost:9091/transmission/web/#upload
  13. http://localhost:9091/transmission/web/#cancel
  14. about:blank
ubuntu@ubuntu:~$


ubuntu@ubuntu:~$ lynx --dump http://ip6-localhost:9091/ | tail -5

Looking up ip6-localhost:9091
Making HTTP connection to ip6-localhost:9091
Alert!: Unable to connect to remote host.

lynx: Can't access startfile http://ip6-localhost:9091/
ubuntu@ubuntu:~$ lynx --dump http://[::1]:9091/ | tail -5

Looking up [::1]:9091
Making HTTP connection to [::1]:9091
Alert!: Unable to connect to remote host.

lynx: Can't access startfile http://[::1]:9091/
ubuntu@ubuntu:~$ lynx --dump http://[2001:0:53aa:64c:8:cf61:ad55:e84b]:9091/ | tail -5

Looking up [2001:0:53aa:64c:8:cf61:ad55:e84b]:9091
Making HTTP connection to [2001:0:53aa:64c:8:cf61:ad55:e84b]:9091
Alert!: Unable to connect to remote host.

lynx: Can't access startfile http://[2001:0:53aa:64c:8:cf61:ad55:e84b]:9091/
ubuntu@ubuntu:~$


ubuntu@ubuntu:~$ lynx --dump http://ipv6.google.com/  | tail -5
  14. http://ipv6.google.com/intl/en/ads/
  15. http://ipv6.google.com/services/
  16. http://ipv6.google.com/intl/en/about.html
  17. http://www.google.nl/
  18. http://ipv6.google.com/intl/en/privacy.html
ubuntu@ubuntu:~$

main Google search page www.google.com on IPv6 too [UPDATE: Selected ISPs only]

UPDATE: Google is indeed on IPv6, but only via ISPs participating in "Google over IPv6". The post below was on a KPN Hotspot, which is connected to Xs4all, which is such a participator.
Pity. Normal users with non-IPv6 ISPs have to wait. :-(


Wow, even the mainstream Google page is on IPv6, too! So not only ipv6.google.com, but also www.google.com and www.google.nl

See below

sander@quirinius:~$ ping6 -c4 www.google.nl
PING www.google.nl(2a00:1450:8001::6a) 56 data bytes
64 bytes from 2a00:1450:8001::6a: icmp_seq=1 ttl=53 time=163 ms
64 bytes from 2a00:1450:8001::6a: icmp_seq=2 ttl=53 time=76.0 ms
64 bytes from 2a00:1450:8001::6a: icmp_seq=3 ttl=53 time=74.3 ms
64 bytes from 2a00:1450:8001::6a: icmp_seq=4 ttl=53 time=79.2 ms

--- www.google.nl ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 74.303/98.374/163.924/37.887 ms
sander@quirinius:~$

Gmail is on IPv6! [UPDATE: Only selected ISPs]

UPDATE: Gmail is indeed on IPv6, but only via ISPs participating in "Google over IPv6". The post below was on a KPN Hotspot, which is connected to Xs4all, which is such a participator.
Pity. Normal users with non-IPv6 ISPs have to wait. :-(

Wow, Gmail is on IPv6! See the output below, and the screendump with IPv6 addres in right lower corner.

Compliments to Google! Google seems to be the only company that *does* IPv6 instead of only *talks* IPv6.



sander@quirinius:~$ host mail.google.com
mail.google.com is an alias for googlemail.l.google.com.
googlemail.l.google.com has address 74.125.77.83
googlemail.l.google.com has address 74.125.77.18
googlemail.l.google.com has address 74.125.77.19
googlemail.l.google.com has IPv6 address 2a00:1450:8005::53
googlemail.l.google.com has IPv6 address 2a00:1450:8005::11
googlemail.l.google.com has IPv6 address 2a00:1450:8005::12
googlemail.l.google.com has IPv6 address 2a00:1450:8005::13
sander@quirinius:~$

sander@quirinius:~$ ping6 -c4 mail.google.com
PING mail.google.com(2a00:1450:8001::11) 56 data bytes
64 bytes from 2a00:1450:8001::11: icmp_seq=1 ttl=53 time=162 ms
64 bytes from 2a00:1450:8001::11: icmp_seq=2 ttl=53 time=80.2 ms
64 bytes from 2a00:1450:8001::11: icmp_seq=3 ttl=53 time=88.8 ms
64 bytes from 2a00:1450:8001::11: icmp_seq=4 ttl=53 time=75.4 ms

--- mail.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3007ms
rtt min/avg/max/mdev = 75.440/101.726/162.418/35.367 ms
sander@quirinius:~$

Bravo Vista! (Sort of)

I'm typing this on a friend's Windows Vista machine. The strange thing: the machine is directly connected to Internet and thus has a public IPv4 address. The interesting thing: IPv6 works ... not based on the Teredo 2001:0: address, but based on the 6to4 2002: address. The IPv6-only website http://ipv6.ip6.me/ shows my 2002: address.

So: Bravo Vista for the IPv6 connectivity.

Oh, wait: the IPv4 & IPv6 website http://www.ipv6.surfnet.nl/ shows my IPv4 address. Vista thus still likes IPv4 more than IPv6 ... :-(



C:\>ipconfig

Windows IP Configuration


Wireless LAN adapter Wireless Network Connection:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::648d:7e53:7b48:57af%8
   IPv4 Address. . . . . . . . . . . : 94.211.128.15
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Default Gateway . . . . . . . . . : 94.211.128.1

Tunnel adapter Local Area Connection* 6:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter Local Area Connection* 7:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::200:5efe:94.211.28.10%12
   Default Gateway . . . . . . . . . :

Tunnel adapter Local Area Connection* 10:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter Local Area Connection* 9:

   Connection-specific DNS Suffix  . :
   IPv6 Address. . . . . . . . . . . : 2001:0:5ef5:73bc:2873:31a3:a12c:e3f5
   Link-local IPv6 Address . . . . . : fe80::2873:31a3:a12c:e3f5%10
   Default Gateway . . . . . . . . . :

Tunnel adapter Local Area Connection* 11:

   Connection-specific DNS Suffix  . :
   Temporary IPv6 Address. . . . . . : 2002:5ed3:1c0a::5ed3:1c0a
   Default Gateway . . . . . . . . . : 2002:c058:6301::c058:6301

C:\>

Hoster Strato offers IPv6

The German hoster Strato now offers IPv6 on it's Highspeed-Server products. The official communication says "IPv6 Ready (Beta)". I hope "IPv6 Ready" does mean it really does IPv6. (Remember: all current operating systems are already IPv6 Ready, but mostly IPv6 is not activated nor used :-( )

Details of the offering here: http://www.strato.de/server/dedicated/highq/index.html

Silly uTorrent: "hostname not found" for IPv6-only tracker on stupid Windows Vista

uTorrent is a great graphical tool to activate Teredo IPv6 on Windows XP.

However, uTorrent on Windows Vista is quite silly: with the IPv6-only tracker tracker.sixxs.net, uTorrent says "hostname not found". Grrrr! And do remember: on Vista Teredo IPv6 is enabled by default, so IPv6 should work.

Probably uTorrent is using Vista's braindead name resolving, meaning: no AAAA lookups with Teredo IPv6.

Advice @ uTorrent developers: on Windows Vista, do an explicit AAAA lookup ... please!

Improved Teredo / Miredo: three suggestions

If 6to4 can be improved (see 6rd here), why not improve Teredo / Miredo? As a happy Teredo / Miredo user, I have a few suggestions:

First: Make Teredo an ISP service, by strongly binding it to the ISP: teredo server, teredo relay and addresses from the ISP. That way, ISPs have an incentive to deploy Teredo / Miredo infrastructures: help their own customers (instead of helping random people accross the Internet). This way, we would no longer have the 2001:0: teredo addresses, but ISP addresses like 2001:888:.

Second: Change Christian Huitema's Teredo protocol so that one teredo instance on a LAN can serve as a gateway for the other device on the LAN. I think one of the things thas to change, is the teredo addressing. See here for the current addressing:

Bits	0 - 31	32 - 63	64 - 79	80 - 95	96 - 127
Length	32 bits	32 bits	16 bits	16 bits	32 bits
Description	Prefix	Teredo server IPv4	Flags	Obfuscated UDP port	Client public IPv4
Part	2001:0000	4136:e378	8000	63bf	3fff:fdd2
Decoded		65.54.227.120	cone NAT	40000	192.0.2.45

My suggestion is to swap the two right hand parts ("Obfuscated UDP Port" and "Client Public IPv4"). Goal of this swap is that the last 16 bits can be freely changed, and thus used as addresses for other devices on the LAN. I guess those addresses can be assigned via RADVD or DHCPv6. The Teredo client would thus become a IPv6 gateway. The advantage is that devices on the LAN that can do simple IPv6 but not Teredo, will now be IPv6 connected to the Internet.


Third (and this is Microsoft-Teredo-only, not Miredo): Microsoft, please enable Windows Vista (and Windows 7?) to actually *use* Teredo IPv6 in the application layer. Now, a Vista machine will have IPv6 connectivity, but typing ipv6.google.com in the web browser will result in an error; apparently Windows won't lookup or use the IPv6 name & connectivity.

PS:

Fourth: modem suppliers should specify whether their modems let pass Teredo traffic. Just like the modem suppliers tell whether their modems let VPNs pass.