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

Cool: Gmail accepts SMTP over IPv6

Cool: Gmail accepts mail via SMTP over IPv6

sander@toverdoos:~$ telnet gmail-smtp-in.l.google.com. smtp

Trying 2a00:1450:8005::1a...

Connected to gmail-smtp-in.l.google.com.

Escape character is '^]'.

220 mx.google.com ESMTP 1si2968615eee.121

ehlo asdf

250-mx.google.com at your service, [2001:41d0:2:bb58:dead:beef:8637:e45b]

250-SIZE 35882577

250-8BITMIME

250-STARTTLS

250 ENHANCEDSTATUSCODES

mail from: <blabla@gmail.com>

250 2.1.0 OK 1si2968615eee.121

rcpt to: <blubblub@gmail.com>

250 2.1.5 OK 1si2968615eee.121

data

354  Go ahead 1si2968615eee.121

Cool, it works!

.

250 2.0.0 OK 1345123513 1si2968615eee.121

quit

221 2.0.0 closing connection 1si2968615eee.121

Connection closed by foreign host.

sander@toverdoos:~$

Raspi's Raspbian: no IPv6 by default ...

Strange: Raspberry Pi's Raspbian ("2012-07-15-wheezy-raspbian") has no IPv6 activated by default. Just plain IPv4. Strange ... why leave out IPv6 in 2012? On Ubuntu IPv6 is even built-in into the kernel.

Anyway:

• A manual "modprobe ipv6" solved it ... until the next reboot.
• Adding "ipv6" (without the quotes) to /etc/modules solved it really

Some specs:

pi@raspberrypi ~ $ uname -a

Linux raspberrypi 3.1.9+ #168 PREEMPT Sat Jul 14 18:56:31 BST 2012 armv6l GNU/Linux

pi@raspberrypi ~ $ 

pi@raspberrypi ~ $ lsmod | grep -i ipv6

ipv6                  290227  20 

pi@raspberrypi ~ $

pi@raspberrypi ~ $ ping6 -nc4 www.google.com

PING www.google.com(2a00:1450:4007:803::1012) 56 data bytes

64 bytes from 2a00:1450:4007:803::1012: icmp_seq=1 ttl=50 time=39.9 ms

64 bytes from 2a00:1450:4007:803::1012: icmp_seq=2 ttl=50 time=38.0 ms

64 bytes from 2a00:1450:4007:803::1012: icmp_seq=3 ttl=50 time=38.9 ms

64 bytes from 2a00:1450:4007:803::1012: icmp_seq=4 ttl=50 time=38.1 ms

--- www.google.com ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3004ms

rtt min/avg/max/mdev = 38.094/38.783/39.923/0.780 ms

pi@raspberrypi ~ $

HTH

iOS 6: "IPv6 Support for Wi-Fi and LTE"

Apple showed the included sheet on yesterday's WWDC with information on iOS 6. It says "IPv6 Support for Wi-Fi and LTE" in the right lower corner (right below the blue logo). 

Let's analyze that:

• IPv6 support for Wifi is nothing new: an iPod Touch 4 with iOS 5 connected to Wifi will already handle IPv6 correctly (if IPv6 is offered by the LAN).
• IPv6 support for LTE is great ... as long as your iOS device supports LTE. I guess currently that is only the new iPad / iPad 3. A far as I know the iPhone 4 does not support LTE. I guess iOS 6 does not support any IPv6 tunnels, so your mobile operator also needs to offer IPv6. That's what T-Mobile in the US does (based on NAT64).
• Apparantly IPv6 support for 3G / UMTS / HSPA / HSDPA / EDGE / GPRS is not available. Pity.