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!
Thursday, December 10, 2009
Sunday, December 6, 2009
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:
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.
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.
6rd: improved 6to4
Rémi Després has developed "6rd" (IPv6 Rapid Deployment), which is an
improved version of 6to4: 6rd has the good things of 6to4 (easy IPv6
over IPv4 tunnel technique), but has taken care of one of the Bad
Things of 6to4: with 6rd the IPv6-over-IPv4 tunnel is completely
handled by the customer's own ISP, instead of some random unknown 6to4
gateway on the Internet. So, with 6rd you get an IPv6 from your ISP,
not a 2002: address.
improved version of 6to4: 6rd has the good things of 6to4 (easy IPv6
over IPv4 tunnel technique), but has taken care of one of the Bad
Things of 6to4: with 6rd the IPv6-over-IPv4 tunnel is completely
handled by the customer's own ISP, instead of some random unknown 6to4
gateway on the Internet. So, with 6rd you get an IPv6 from your ISP,
not a 2002: address.
IMHO, one Bad Thing of 6to4 remains in 6rd: it is not desgined to work
from behind NAT. In my experience, 6to4 might or might not work behind
NAT: It depends on the NAT device: does it handle Protocol 41 or GRE
tunnels. Brrr ...
So the best solution is the deploy 6rd / 6to4 on the NAT device
itself. So far, only Free has deployed 6rd on it's self-developed
Freebox. So the wait continues for the usual suspects: when do Thomson
Speedtouch, Zyxel, Linksys, AVM Fritzbox deploy 6rd on their DSL
modems?
Relevant URLs:
http://tools.ietf.org/html/draft-despres-6rd-03
http://fr.wikipedia.org/wiki/6rd (alert: in French!)
Sunday, November 29, 2009
SABnzbd's webinterface on IPv6
The great NZB downloader SABnzbd is fully IPv6 enabled:
There fill out:
Then click save and restart SABnzbd. You can now access SABnzbd over it's private and public IPv6 interface:
BTW: as of SABnzbd 0.5.0, you don't need the 'sabnzbd' anymore in the URL, so the very cryptical http://[::1]:8080/ is also OK!
- you can download from IPv6 newsservers, like new.ipv6.eweka.nl and newszilla6.xs4all.nl. This feature is enabled by default.
- you can access SABnzbd's webinterface over IPv6. See instruction below.
SABnzbd Host:
Host SABnzbd should listen on.
Host SABnzbd should listen on.
There fill out:
::
Then click save and restart SABnzbd. You can now access SABnzbd over it's private and public IPv6 interface:
http://ip6-localhost:8080/sabnzbd/
http://[::1]:8080/sabnzbd/
http://[2001:8348:3a3:0:224:2cff:fe6a:66ab]:8080/sabnzbd/
http://[::1]:8080/sabnzbd/
http://[2001:8348:3a3:0:224:2cff:fe6a:66ab]:8080/sabnzbd/
BTW: as of SABnzbd 0.5.0, you don't need the 'sabnzbd' anymore in the URL, so the very cryptical http://[::1]:8080/ is also OK!
Friday, November 20, 2009
CouchDB ... with IPv6?!
... brute force grepping on the CouchDB source code seems to reveal there is IPv6 in CouchDB. Now I have to find out how to enable it ...
UPDATE:
Thanks to JanL's comment, my CouchDB instance now works over IPv6 (::1):
I added the IPv6 localhost address ::1 to "bind_address" in /etc/couchdb/local.ini, like this:
[httpd]
;port = 5984
;bind_address = 127.0.0.1
bind_address = ::1
After a restart, CouchDB now listens on http://[::1]:5984/_utils/
UPDATE 2:
I added :: to "bind_address" in /etc/couchdb/local.ini, like this:
[httpd]
;port = 5984
;bind_address = 127.0.0.1
bind_address = ::
After a restart, CouchDB now listens on the public IPv6 address! Great!
sander@quirinius:~/apache-couchdb-0.10.0$ egrep -i -e inet6 -e inet4 -e inet6fb4 -e ipv6 * */* */*/* */*/*/* */*/*/*/*
CHANGES: * CouchDB can now be bound to IPv6 addresses.
src/mochiweb/mochiweb_socket_server.erl:ipv6_supported() ->
src/mochiweb/mochiweb_socket_server.erl: case (catch inet:getaddr("localhost", inet6)) of
src/mochiweb/mochiweb_socket_server.erl: case ipv6_supported() of % IPv4, and IPv6 if supported
src/mochiweb/mochiweb_socket_server.erl: true -> [inet, inet6 | BaseOpts];
src/mochiweb/mochiweb_socket_server.erl: {_, _, _, _, _, _, _, _} -> % IPv6
src/mochiweb/mochiweb_socket_server.erl: [inet6, {ip, Ip} | BaseOpts]
sander@quirinius:~/apache-couchdb-0.10.0$
UPDATE:
Thanks to JanL's comment, my CouchDB instance now works over IPv6 (::1):
I added the IPv6 localhost address ::1 to "bind_address" in /etc/couchdb/local.ini, like this:
[httpd]
;port = 5984
;bind_address = 127.0.0.1
bind_address = ::1
After a restart, CouchDB now listens on http://[::1]:5984/_utils/
UPDATE 2:
I added :: to "bind_address" in /etc/couchdb/local.ini, like this:
[httpd]
;port = 5984
;bind_address = 127.0.0.1
bind_address = ::
After a restart, CouchDB now listens on the public IPv6 address! Great!
sander@quirinius:~/apache-couchdb-0.10.0$ egrep -i -e inet6 -e inet4 -e inet6fb4 -e ipv6 * */* */*/* */*/*/* */*/*/*/*
CHANGES: * CouchDB can now be bound to IPv6 addresses.
src/mochiweb/mochiweb_socket_server.erl:ipv6_supported() ->
src/mochiweb/mochiweb_socket_server.erl: case (catch inet:getaddr("localhost", inet6)) of
src/mochiweb/mochiweb_socket_server.erl: case ipv6_supported() of % IPv4, and IPv6 if supported
src/mochiweb/mochiweb_socket_server.erl: true -> [inet, inet6 | BaseOpts];
src/mochiweb/mochiweb_socket_server.erl: {_, _, _, _, _, _, _, _} -> % IPv6
src/mochiweb/mochiweb_socket_server.erl: [inet6, {ip, Ip} | BaseOpts]
sander@quirinius:~/apache-couchdb-0.10.0$
Wednesday, November 4, 2009
IPv6 an overwhelming success: "Too many connections to server news.ipv6.eweka.nl:119"
It's clear: IPv6 is an overwhelming success!
Proof is here: "Too many connections to server news.ipv6.eweka.nl:119".
;-)
But seriously: give users a reason for IPv6 (free downloads!), and they will start using IPv6.
Proof is here: "Too many connections to server news.ipv6.eweka.nl:119".
;-)
But seriously: give users a reason for IPv6 (free downloads!), and they will start using IPv6.
Sunday, October 18, 2009
Subscribe to:
Posts (Atom)

