Setting up a Sitecom X6 router with a HE IPv6 tunnel

Here's an instruction how to setup the Sitecom WLR-6100 X6 N900 router with a Hurricane Electric IPv6 Tunnel. It will probably also work with other Sitecom routers, like the X4.

The trick is to use a Routed /48 tunnel.

In short: Request a tunnel with routed /48 from Hurricane Electric and use just three parameters to set up 6RD IPv6 in your Sitecom.

The longer description:

1. Upgrade your Sitecom router to firmware 2.4 (or higher)
2. Make sure your Sitecom is ping-able from Internet
3. Create an account on http://www.tunnelbroker.net/
4. Request a tunnel on http://www.tunnelbroker.net/ . Choose a tunnel provider near you
5. On that tunnel page, request the “Routed /48”
6. From the tunnel page, the following items are relevant:
1. Server IPv4 Address
2. Client IPv4 Addres (=your own public IPv4 address)
3. Routed /48
7. In the Sitecom, click on "Internet Settings", then "IPv6 Settings". Choose "6RD" in the firs drop down option
8. Then fill out the Sitecom form as in the screendump below

It should now work. So, with your laptop/PC, go to http://test-ipv6.com/ to see if you have IPv6 connectivity. That site should say something like "Your IPv6 address on the public Internet appears to be 2001:470:... (HURRICANE - Hurricane Electric, Inc.)".


Screendump (click for larger image):

The throughput over Wifi is quite impressive: I get 11,3 MB/s, thus about 113 Mbps. (on my 300/300 Mbps Internet connection). See this output:


sander@flappie:~$ wget -6 http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso -O /dev/null
--2013-04-19 16:32:06--  http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso
Resolving ftp.belnet.be (ftp.belnet.be)... 2001:6a8:3c80:2::21
Connecting to ftp.belnet.be (ftp.belnet.be)|2001:6a8:3c80:2::21|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 726970368 (693M) [application/x-iso9660-image]
Saving to: ‘/dev/null’

 6% [==>                                                ] 49.882.045  11,5MB/s  eta 61s    
28% [=============>                                     ] 206.782.525 11,5MB/s  eta 45s    
71% [===================================>               ] 520.086.461 11,2MB/s  eta 18s    
100%[==================================================>] 726.970.368 11,3MB/s   in 61s    

2013-04-19 16:33:08 (11,3 MB/s) - ‘/dev/null’ saved [726970368/726970368]

sander@flappie:~$ 

I can't test the IPv6 speed of wired ethernet as the Sitecom becomes completely unreachable with 3 seconds when do that. So I would say that's a bug in the Sitecom.

Update: with another laptop (HP with Windows7, instead of Samsung with Ubuntu), IPv6 over wired ethernet does not lock up the Sitecom, and the speed is impressive:



C:\>wget-1.14.exe -6 http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso
--2013-04-19 16:57:58--  http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso
Resolving ftp.belnet.be (ftp.belnet.be)... 2001:6a8:3c80:2::21
Connecting to ftp.belnet.be (ftp.belnet.be)|2001:6a8:3c80:2::21|:80... connected
.
HTTP request sent, awaiting response... 200 OK
Length: 726970368 (693M) [application/x-iso9660-image]
Saving to: 'ubuntu-12.04.2-desktop-i386.iso.1'

100%[======================================>] 726,970,368 24.1MB/s   in 29s

2013-04-19 16:58:27 (24.1 MB/s) - 'ubuntu-12.04.2-desktop-i386.iso.1' saved [726970368/726970368]


C:\>

So ... that's 24.1 MB/s, or 241 Mbps...! FWIW: tested on a 300/300 Mbps Caiway FttH connection.

Update 2: with the same laptop (HP) with Ubuntu, the speed is even higher: 34.1 MB/s, or 341 Mbps. Kudo's to the Sitecom router for handling the IPv6 at this great speed.


ubuntu@ubuntu:~$ wget -6 http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso -O /dev/null
--2013-04-19 18:24:42-- http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.2-desktop-i386.iso
Resolving ftp.belnet.be (ftp.belnet.be)... 2001:6a8:3c80:2::21
Connecting to ftp.belnet.be (ftp.belnet.be)|2001:6a8:3c80:2::21|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 726970368 (693M) [application/x-iso9660-image]
Saving to: ‘/dev/null’

39% [==============> ] 289,894,144 36.7MB/s eta 13s
79% [=============================> ] 577,715,328 37.2MB/s eta 5s
100%[======================================>] 726,970,368 27.6MB/s in 20s

2013-04-19 18:25:02 (34.1 MB/s) - ‘/dev/null’ saved [726970368/726970368]

ubuntu@ubuntu:~$

IPv6 MTU discovery

Thanks to http://muzso.hu/2009/05/17/how-to-determine-the-proper-mtu-size-with-icmp-pings it looks like it's easy to discover the IPv6 MTU (Maximum Transmission Unit):


$ ping6 -c1 -M do -s 10000 www.google.com  | grep mtu | awk '{ print $NF }' 

mtu=1500

So the IPv6 MTU to www.google.com is 1500.

From another system, the MTU is 1480:

$ ping6 -c1 -M do -s 10000 www.google.com  | grep mtu | awk '{ print $NF }'

mtu=1480

Easy, isn't it?

For old-skool IPv4, the output of ping is a bit different, so the awk parsing is a bit different:

$ ping -c1 -M do -s 10000 www.google.com | grep mtu | awk '{ print $NF }' | sed -e s/\)//

1500

HTH

Dutch ISP Telfort introduces IPv6

After conducting an IPv6 pre-pilot (see http://ipv6-or-no-ipv6.blogspot.nl/2012/01/dutch-isp-telfort-conducting-ipv6-pre.html), Dutch ISP pilot Telfort has silently introduced IPv6 for all its DSL (VDSL and ADSL) customers. I don't know about its FttH customers. And mobile customers probably have to wait.

Telfort's IPv6 is opt-in; you have to enable it in your Zyxel modem. This is how:

• Log in on your Zyxel modem at http://192.168.1.254/ 
• Go to Network Setting -> Broadband. At the top of that page, check which connection is used: VDSL or ADSL. Then find that entry in the table below, and click on the corresponding "Modify" icon on the far right
• In the windows that pops up, at "IPv6/IPv4 DualStack" click enable. More below, enable "6to4 Tunneling" and check "6RD Enable". Then click the Apply button
• Final check: the column IPv6 should now be on "enable" at your VDSL or ADSL line.

That's it. You should now have IPv6. Check via http://ip6.nl/ or http://test-ipv6.com/. If not, reboot your  modem and computer once.

Technology used is 6RD. Address prefix is 2A00:CD8::/32

Telfort's mother company KPN yet has to introduce IPv6.

Self-scan your IPv6 ports

This is nice site to scan well known ports on your IPv6 system:

http://www6.ipv6.chappell-family.com/cgi-bin6/ipscan-txt.cgi

Direct link for well known ports:

http://www6.ipv6.chappell-family.com/cgi-bin6/ipscan-txt.cgi?includeexisting=1&customport0=&customport1=&customport2=&customport3=

Direct link for well known ports, plus custom port 12345:

http://www6.ipv6.chappell-family.com/cgi-bin6/ipscan-txt.cgi?includeexisting=1&customport0=12345&customport1=&customport2=&customport3=

As far as I know, default behaviour of IPv6 enabled modems and Windows is to drop unknown incoming IPv6 sessions (and thus the above port scan); Windows thus mimics NAT behaviour

You can also use lynx to see OPEN ports:


sander@toverdoos:~$ lynx --dump 'http://www6.ipv6.chappell-family.com/cgi-bin6/ipscan-txt.cgi?includeexisting=1&customport0=12345&customport1=&customport2=&customport3=' | grep OPEN

   Port 53 = OPEN   Port 79 = RFSD    Port 80 = OPEN
   OPEN An IPv6 TCP connection was successfully established to this port.
sander@toverdoos:~$ 


So port 53 and 80 are open on this system.

"IPv6 duplicate address" in Linux

My Linux system (Ubuntu 12.10) was suddenly having problems with IPv6, and dmesg said:

IPv6: wlan0: IPv6 duplicate address 2a00:cd8:blabla:1af4:6aff:fe9c:ced4 detected!
IPv6: ipv6_create_tempaddr: regeneration time exceeded - disabled temporary address support

The workaround was to disable Duplicate Address Detection (DAD) for the IPv6 privacy extensions on my Wifi interface wlan0:

sudo sysctl net.ipv6.conf.wlan0.accept_dad=0

Please note: if you use wired ethernet eth0, you should do something like this:

sudo sysctl net.ipv6.conf.eth0.accept_dad=0

It is unclear to me where the problem is: in Linux itself , or in my modem, or in the interaction between Linux and my modem.
The problem also occurs in OpenSuSE 12.2 on the same LAN, so it's not a Ubuntu-only problem.

Bug report is here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1120617

Update: it seems to be related to Wifi; it does not happen with wired ethernet.

Easy Happy Eyeballs Testing

Easy Happy Eyeballs Testing

Nice article on http://ipv6friday.org/blog/2012/11/happy-testing/ how to test your application against Happy Eyeballs. In short, "Happy Eyeballs" (RFC 6555) means choosing the most fast (or fast enough) connection on dual-stack systems (IPv4 and IPv6).

And the testing is easy: use the URLs below in your applications (wget, curl, chrome, firefox, etc) to test your application's behaviour

http://badipv6.test.ipv6friday.org/
http://badipv4.test.ipv6friday.org/

A 'good' (= Happy Eyeballed) application should NOT get a slow time-out, but should connect with a second or so.

Example: curl (version 7.27.0) is not Happy-Eyeballed:


sander@R540:~$ time curl http://badipv4.test.ipv6friday.org/ > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   226  100   226    0     0   2054      0 --:--:-- --:--:-- --:--:--  4520

real 0m0.124s
user 0m0.012s
sys 0m0.004s
sander@R540:~$ 

sander@R540:~$ time curl http://badipv6.test.ipv6friday.org/ > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   226  100   226    0     0      3      0  0:01:15  0:01:03  0:00:12    54

real 1m3.227s
user 0m0.020s
sys 0m0.008s
sander@R540:~$

Explanation: the second URL takes more than one minute (!), so curl 7.27.0 waits for a loooong timeout. :-(

1% of Google visitors use IPv6

Interesting: Google measures the availability of IPv6 connectivity among Google users. At the beginning of 2012 it was 0.4%, at the end of 2012 it was 1%. So it multiplied with a factor 2.5. That would mean 2.5% IPv6 Google users at the end of 2013. Not bad.

Oh, Teredo usage dropped from 0.1% to 0.01%. I had not expected that.

http://www.google.com/ipv6/statistics.html#tab=ipv6-adoption