Good news: Ducth cable ISP "Ziggo" has started the rollout of IPv6. See article (in Dutch) on http://tweakers.net/nieuws/102311/ziggo-begint-met-uitrol-van-ipv6.html
Ziggo spokesperson Gradus Vos confirms the rollout has started last week (around beginning of April 2015), and so far 6.000 users have been assigned IPv6 connectivity.
Tuesday, April 7, 2015
Netflix and "This webpage has a redirect loop"
Suddenly Netflix was not working anymore: my Chrome on Ubuntu Linux said "This webpage has a redirect loop" on www.netflix.com.
Netflix advised to clear my cookies.
The real cause was different: IPv6, and possibly my Hurricane Electric IPv6 tunnel.
After disabling IPv6 in Chrome with the startup command "google-chrome --disable-ipv6", Netflix was working again.
Great. Not.
EDIT: I found a dirty workaround: I put this into my /etc/hosts
54.197.238.114 www1.netflix.com
Netflix advised to clear my cookies.
The real cause was different: IPv6, and possibly my Hurricane Electric IPv6 tunnel.
After disabling IPv6 in Chrome with the startup command "google-chrome --disable-ipv6", Netflix was working again.
Great. Not.
EDIT: I found a dirty workaround: I put this into my /etc/hosts
54.197.238.114 www1.netflix.com
... and now a plain google-chrome startup (so with IPv6 enabled) leads to a working Netflix!
EDIT 2:
Thijs Kroesbergen (@TheIceCoMa) reports a Netflix problem with Sixxs IPv6:
https://twitter.com/TheIceCoMan/status/585829217046294528
@NetflixNL IPV6 on the http://netflix.com site is broken (connection timeout on the first HTTPS request) coming from a SiXXS tunnel.
EDIT 3:
Windows 7 & Chrome on the same LAN (so: with tunneled IPv6) correctly works with Netflix. Strange
Ubuntu & Netflix with Pipelight works too with Netflix
Screenshot of the not-working Netflix:
EDIT 2:
Thijs Kroesbergen (@TheIceCoMa) reports a Netflix problem with Sixxs IPv6:
https://twitter.com/TheIceCoMan/status/585829217046294528
@NetflixNL IPV6 on the http://netflix.com site is broken (connection timeout on the first HTTPS request) coming from a SiXXS tunnel.
EDIT 3:
Windows 7 & Chrome on the same LAN (so: with tunneled IPv6) correctly works with Netflix. Strange
Ubuntu & Netflix with Pipelight works too with Netflix
Screenshot of the not-working Netflix:
Tuesday, February 17, 2015
Docker 1.5 and IPv6 on Ubuntu
Docker 1.5 offers IPv6. Here's how I got it working on my Ubuntu VPS.
First of all: my VPS provider (thanks, Philip!) was so friendly to provide & route a separate IPv6 subnet to my VPS, which I used for Docker:
(Note: AAAA is a placeholder for the real hex digits)
First check you have at least docker 1.5:
sander@makreel:~$ sudo docker --version
Docker version 1.5.0, build 7e803ba
Stop de docker daemon:
sudo service docker stop
To avoid
FATA[0000] bridge IPv6 does not match existing bridge configuration fe80::1
do this:
sudo apt-get install bridge-utils
sudo ifconfig docker0 down
sudo brctl delbr docker0
Then start the docker daemon with IPv6 and the IPv6 subnet:
sudo docker -d --ipv6 --fixed-cidr-v6="2001:AAAA:FF00:1700::/64"
And that's it! The docker daemon is ready, and you don't need any special settings in the docker container. Let's check that:
Check IPv6 within a ubuntu container:
sander@makreel:~$ sudo docker run -it ubuntu bash -c "ifconfig"
eth0 Link encap:Ethernet HWaddr 02:42:ac:11:00:0a
inet addr:172.17.0.10 Bcast:0.0.0.0 Mask:255.255.0.0
inet6 addr: fe80::42:acff:fe11:a/64 Scope:Link
inet6 addr: 2001:aaaa:ff00:1700:0:242:ac11:a/64 Scope:Global
UP BROADCAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:110 (110.0 B) TX bytes:90 (90.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
First of all: my VPS provider (thanks, Philip!) was so friendly to provide & route a separate IPv6 subnet to my VPS, which I used for Docker:
- Separate subnet provided by my VPS provider: 2001:AAAA:FF00:1700::/56
- Sub-subnet used for Docker: 2001:AAAA:FF00:1700::/64
(Note: AAAA is a placeholder for the real hex digits)
First check you have at least docker 1.5:
sander@makreel:~$ sudo docker --version
Docker version 1.5.0, build 7e803ba
Stop de docker daemon:
sudo service docker stop
To avoid
FATA[0000] bridge IPv6 does not match existing bridge configuration fe80::1
do this:
sudo apt-get install bridge-utils
sudo ifconfig docker0 down
sudo brctl delbr docker0
Then start the docker daemon with IPv6 and the IPv6 subnet:
sudo docker -d --ipv6 --fixed-cidr-v6="2001:AAAA:FF00:1700::/64"
And that's it! The docker daemon is ready, and you don't need any special settings in the docker container. Let's check that:
Check IPv6 within a ubuntu container:
sander@makreel:~$ sudo docker run -it ubuntu bash -c "ifconfig"
eth0 Link encap:Ethernet HWaddr 02:42:ac:11:00:0a
inet addr:172.17.0.10 Bcast:0.0.0.0 Mask:255.255.0.0
inet6 addr: fe80::42:acff:fe11:a/64 Scope:Link
inet6 addr: 2001:aaaa:ff00:1700:0:242:ac11:a/64 Scope:Global
UP BROADCAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:110 (110.0 B) TX bytes:90 (90.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Looks good.
Check you have outside IPv6 connectivity
sander@makreel:~$ sudo docker run -it ubuntu bash -c "ping6 -c5 ipv6.google.com"
PING ipv6.google.com(2a00:1450:400c:c07::64) 56 data bytes
64 bytes from 2a00:1450:400c:c07::64: icmp_seq=3 ttl=56 time=7.12 ms
64 bytes from 2a00:1450:400c:c07::64: icmp_seq=4 ttl=56 time=7.05 ms
64 bytes from 2a00:1450:400c:c07::64: icmp_seq=5 ttl=56 time=7.28 ms
--- ipv6.google.com ping statistics ---
5 packets transmitted, 3 received, 40% packet loss, time 4019ms
rtt min/avg/max/mdev = 7.056/7.152/7.280/0.116 ms
sander@makreel:~$
Good! So IPv6 is working!
Speedtest:
$ sudo docker run -it ubuntu bash -c "apt-get update && apt-get install -y wget && wget -6 'http://ftp.belnet.be/ubuntu.com/ubuntu/releases/precise/ubuntu-12.04.4-desktop-i386.iso' -O /dev/null"
...
100%[======================================>] 766,509,056 8.25MB/s in 97s
2015-02-17 12:16:50 (7.52 MB/s) - '/dev/null' saved [766509056/766509056]
sander@makreel:~$
Note: the official documentation https://docs.docker.com/articles/networking/#ipv6-with-docker does not state you need a separate IPv6 subnet. Strange.
Wednesday, January 14, 2015
One-liner to check (and ping6) IPv6 devices
A one-line to check IPv6 devices on your LAN:
$ ping6 -c3 -I wlan0 ff02::1 | awk ' /bytes from/ { print $4 }' | sort -u | sed 's/:$//'
fe80::1af4:6aff:fe9c:ced4
fe80::212:40ff:fe8a:8e38
fe80::66d1:a3ff:fe31:9c57
fe80::c24a:ff:fe2c:dcbc
fe80::d263:b4ff:fe00:2a61
So: 5 IPv6-enabled devices on my LAN. At least: 5 devices that react on the broadcast ping6.
You can feed that into ping6 to see if they are ping6-able:
$ ping6 -c3 -I wlan0 ff02::1 | awk ' /bytes from/ { print $4 }' | sort -u | sed 's/:$//' | awk '{ print "ping6 -c3 -I wlan0 " $1 }' | /bin/sh | awk ' /PING/ { print $2 } /packets transmitted/ { print $0 "\n" } '
fe80::1af4:6aff:fe9c:ced4(fe80::1af4:6aff:fe9c:ced4)
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
fe80::212:40ff:fe8a:8e38(fe80::212:40ff:fe8a:8e38)
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
fe80::66d1:a3ff:fe31:9c57(fe80::66d1:a3ff:fe31:9c57)
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
fe80::c24a:ff:fe2c:dcbc(fe80::c24a:ff:fe2c:dcbc)
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
fe80::d263:b4ff:fe00:2a61(fe80::d263:b4ff:fe00:2a61)
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
So ... they are all ping6-able.
$ ping6 -c3 -I wlan0 ff02::1 | awk ' /bytes from/ { print $4 }' | sort -u | sed 's/:$//'
fe80::1af4:6aff:fe9c:ced4
fe80::212:40ff:fe8a:8e38
fe80::66d1:a3ff:fe31:9c57
fe80::c24a:ff:fe2c:dcbc
fe80::d263:b4ff:fe00:2a61
So: 5 IPv6-enabled devices on my LAN. At least: 5 devices that react on the broadcast ping6.
You can feed that into ping6 to see if they are ping6-able:
$ ping6 -c3 -I wlan0 ff02::1 | awk ' /bytes from/ { print $4 }' | sort -u | sed 's/:$//' | awk '{ print "ping6 -c3 -I wlan0 " $1 }' | /bin/sh | awk ' /PING/ { print $2 } /packets transmitted/ { print $0 "\n" } '
fe80::1af4:6aff:fe9c:ced4(fe80::1af4:6aff:fe9c:ced4)
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
fe80::212:40ff:fe8a:8e38(fe80::212:40ff:fe8a:8e38)
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
fe80::66d1:a3ff:fe31:9c57(fe80::66d1:a3ff:fe31:9c57)
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
fe80::c24a:ff:fe2c:dcbc(fe80::c24a:ff:fe2c:dcbc)
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
fe80::d263:b4ff:fe00:2a61(fe80::d263:b4ff:fe00:2a61)
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
So ... they are all ping6-able.
Thursday, November 13, 2014
Discover IPv6 enabled devices on your LAN
pi@raspevaq ~ $ ping6 -c4 -I eth0 ff02::1 | awk '{ print $4 }' | grep fe80 | sed -e 's/:$//' | sort -u
fe80::1af4:6aff:fe9c:ced4
fe80::212:40ff:fe8a:8e38
fe80::ba27:ebff:fef2:b330
pi@raspevaq ~ $
Tuesday, July 29, 2014
Dutch ISP Telfort ends its IPv6 offering
Ouch: It's 2014 and Dutch ISP ends its IPv6 service to its customers.
Telfort started an IPv6 pilot in December 2011 (see my blog post) and offered opt-in IPv6 to all its customers as of March 2013 (see my blog post). And all that ended yesterday, July 28, 2014.
As the reason for ending the IPv6 pilot, Telfort says it's moving to a new datacenter.
Telfort offers no clear plans for re-introduction of IPv6: Telfort refers to its dependency on mother company KPN, which does not offer IPv6 to consumer customers.
So: one step back for IPv6 and Telfort.
Telfort started an IPv6 pilot in December 2011 (see my blog post) and offered opt-in IPv6 to all its customers as of March 2013 (see my blog post). And all that ended yesterday, July 28, 2014.
As the reason for ending the IPv6 pilot, Telfort says it's moving to a new datacenter.
Telfort offers no clear plans for re-introduction of IPv6: Telfort refers to its dependency on mother company KPN, which does not offer IPv6 to consumer customers.
So: one step back for IPv6 and Telfort.
Sunday, July 13, 2014
Testing IPv6-only on Ubuntu
A nice try, just for fun: how is the Internet behaving with IPv6-only on a Ubuntu system?
Before we start: I think IPv4 will be in use for at least 10 years, together with IPv6. So IPv6-only is just a test.
Pre-condition: your IPv6 must be working. Check with
ping6 -c4 ipv6.google.com
Two steps to remove IPv4:
First
sudo gedit /etc/resolv.conf
and put this before the existing nameserver entry:
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844
Then remove your IPv4 address, in my case 192.168.1.113 from wlan0:
sudo ip addr del 192.168.1.113/24 dev wlan0
You now only have IPv6. (Don't worry: after a network reload, you have your IPv4 back)
Check that IPv4 is not working anymore:
$ ping 8.8.8.8
connect: Network is unreachable
Check that IPv6 is still working:
ping6 -c4 ipv6.google.com
With your webbrowser, visit (which should all work):
Not working (shame on them!):
You can visit an IPv4-only site like nu.nl via http://www.nu.nl.ipv6.sixxs.org/ . Note that this only work for plain HTTP, not for HTTPS.
If you run
sudo apt-get update && sudo apt-get upgrade
you will get messages like:
Could not resolve 'ppa.launchpad.net'
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
Pity.
Back to dual stack IPv4 and IPv6? Just reload your network.
Before we start: I think IPv4 will be in use for at least 10 years, together with IPv6. So IPv6-only is just a test.
Pre-condition: your IPv6 must be working. Check with
ping6 -c4 ipv6.google.com
Two steps to remove IPv4:
First
sudo gedit /etc/resolv.conf
and put this before the existing nameserver entry:
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844
Then remove your IPv4 address, in my case 192.168.1.113 from wlan0:
sudo ip addr del 192.168.1.113/24 dev wlan0
You now only have IPv6. (Don't worry: after a network reload, you have your IPv4 back)
Check that IPv4 is not working anymore:
$ ping 8.8.8.8
connect: Network is unreachable
Check that IPv6 is still working:
ping6 -c4 ipv6.google.com
With your webbrowser, visit (which should all work):
- http://ipv6.test-ipv6.com/ , which should say "No IPv4 address detected"
- https://www.google.com/
- https://www.youtube.com/
- https://gmail.com/
- https://www.facebook.com/
- https://www.xs4all.nl/
Not working (shame on them!):
You can visit an IPv4-only site like nu.nl via http://www.nu.nl.ipv6.sixxs.org/ . Note that this only work for plain HTTP, not for HTTPS.
If you run
sudo apt-get update && sudo apt-get upgrade
you will get messages like:
Could not resolve 'ppa.launchpad.net'
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
Pity.
Back to dual stack IPv4 and IPv6? Just reload your network.
Subscribe to:
Posts (Atom)