Problems with IPv6

[jre6]

While many are excited with this World IPv6 Day, I am having problems while connecting testing my IPv6 readiness.

I am on Ubuntu 10.04.2 (updated from 10.04.1) and just wanted to test whether I am IPv6 ready, as I had recently read it on Slashdot. I found these sites, and tested on them.

The problem is that the results vary on Windows XP and Ubuntu. I am sure I haven't done any configurations like 6to4/Teredo etc. One thing that I know for sure is that my ISP can't reach IPv6-only sites because it has no access to the IPv6 internet (or perhaps isn't configured to use it). The results are as below:

On Ubuntu

http://ipv6eyechart.ripe.net/





http://ipv6test.google.com





http://test-ipv6.com




On Windows

http://ipv6eyechart.ripe.net



http://ipv6test.google.com



http://test-ipv6.com



Now, why is this contradiction occuring? Can it be resolved in Ubuntu 10.04.2 by changing settings? If so, how? Otherwise, do I need an upgrade to a later version like 10.10/11.04? Or is this something where my ISP is at fault?

[regala]

...

does your ISP provide IPv6 connectivity ? if not, all your tests are pointless...

--
Mathieu

[robsoles]

does your ISP provide IPv6 connectivity ? if not, all your tests are pointless...

--
Mathieu

From the one location, behind (or 'plugged into') the same ISP, the OP indicates less functionality using 10.04.02 than OP got with Windows XP.

...

Now, why is this contradiction occuring? Can it be resolved in Ubuntu 10.04.2 by changing settings? If so, how? Otherwise, do I need an upgrade to a later version like 10.10/11.04? Or is this something where my ISP is at fault?

Your ISP is (quite possibly, at least) at fault where the testing website states that as the problem.

I doubt you need to upgrade, I'm running 10.04 on a fairly recent desktop setup and 10.10 on a Samsung netbook and they've both just pulled your 'Windows XP' results (that I can see in your pics) from the http://ipv6eyechart.ripe.net/ website and I haven't tinkered once regarding IPv6.

Jumping into the network settings on the desktop machine I found the "IPv6 Settings" tab had "Method: Ignore" selected after running that test. All the testers I tried stated my ISP wasn't IPv6 enabled but they said my PC and my location were ready for Wednesday.

Would you please post the response of the following from the indicated OS:

Ubuntu (Terminal)

ifconfig -a

Windows (DOS prompt)

ipconfig /all

If you post both of those somebody might spot if there is a difference in the implementation each is using to access services from your computer.

(remove the HWaddr (Linux) and the "Physical Address" (Windows) numbers if you like but we need to see the rest to be sure they aren't different)

[jtarin]

does your ISP provide IPv6 connectivity ? if not, all your tests are pointless...

--
Mathieu

If you use a tunnel broker like hurricane or your setup with dns resolvers of opendns or google that statement is not entirely true.

[sanderj]

AFAIK, World IPv6 Day is *not* about testing IPv6 connectivity.


World IPv6 Day is about testing whether (web)servers like Google can safely activate IPv6 on their site (and side), next to existing IPv4, without breaking connectivity to their IPv4-only (and IPv4/IPv6-) users.

For example: a laptop on a IPv4-only connection, might try to connect via IPv6 first (after seeing www.google.com has an IPv6/AAAA address), which will time out (because the connection is IPv4-only), after which it will connect via IPv4. Result: a long delay in getting the webpage, so slowness, so an unhappy user.
This is a fault of the laptop, but if it occurs on a lot of systems, it would be a reason for google *not* to give www.google.com an IPv6 address ... protecting their users.

World IPv6 Day is for finding this kind of problematic laptops, setups, etc.

[sanderj]

@jre6

So the RIPE site is reporting you have a bad connection to dual-stack site Python.org? Strange.

EDIT: RIPE's explanation:

This chart contains tests of connectivity to websites, by fetching an image from that website. The results for a website are:
<GREEN logo> Content fetched within 10 seconds
<RED logo> Content not fetched within 10 seconds

/EDIT

So Red means very slow or no connectivity at all to this dual-stack website. So exactly what I described in my earlier post: a Green logo means good connectivity, which might be pure, plain IPv4 (and no IPv6 at all)

So, do a test yourself: what's your output of "time wget python.org"? See mine below as an example.

sander@R540:~$ time wget http://python.org/
--2011-06-06 11:56:42--  http://python.org/
Resolving python.org... 2001:888:2000:d::a2, 82.94.164.162
Connecting to python.org|2001:888:2000:d::a2|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 19229 (19K) [text/html]
Saving to: `index.html.2'

100%[==============================================================================================================================>] 19,229      --.-K/s   in 0.1s    

2011-06-06 11:56:42 (170 KB/s) - `index.html.2' saved [19229/19229]


real	0m0.218s
user	0m0.010s
sys	0m0.010s
sander@R540:~$

[jre6]

For "ifconfig -a" on Ubuntu I get:

eth0      Link encap:Ethernet  HWaddr 00:18:8b:d5:b8:6e  
          UP BROADCAST MULTICAST  MTU:1500  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:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:18 

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:16436  Metric:1
          RX packets:56 errors:0 dropped:0 overruns:0 frame:0
          TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4128 (4.1 KB)  TX bytes:4128 (4.1 KB)

pan0      Link encap:Ethernet  HWaddr 3a:78:37:e4:8e:60  
          BROADCAST MULTICAST  MTU:1500  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)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:14.96.4.196  P-t-P:172.29.242.61  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2082 errors:12 dropped:0 overruns:0 frame:0
          TX packets:2088 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:2256470 (2.2 MB)  TX bytes:303630 (303.6 KB)

vboxnet0  Link encap:Ethernet  HWaddr 0a:00:27:00:00:00  
          BROADCAST MULTICAST  MTU:1500  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:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:1b:77:7a:62:3c  
          BROADCAST MULTICAST  MTU:1500  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:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

For "ipconfig /all" on Windows, I get:

Windows IP Configuration  
  
        Host Name . . . . . . . . . . . . : foobar-f28d488c  
        Primary Dns Suffix  . . . . . . . :   
        Node Type . . . . . . . . . . . . : Unknown  
        IP Routing Enabled. . . . . . . . : No  
        WINS Proxy Enabled. . . . . . . . : No  
  
Ethernet adapter Local Area Connection:  
  
        Media State . . . . . . . . . . . : Media disconnected  
        Description . . . . . . . . . . . : Intel(R) PRO/100 VE Network Connection  
        Physical Address. . . . . . . . . : 00-09-6B-DA-82-12  
  
PPP adapter TATA Indicom:  
  
        Connection-specific DNS Suffix  . :   
        Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface  
        Physical Address. . . . . . . . . : 00-53-45-00-00-00  
        Dhcp Enabled. . . . . . . . . . . : No  
        IP Address. . . . . . . . . . . . : 14.96.174.172  
        Subnet Mask . . . . . . . . . . . : 255.255.255.255  
        Default Gateway . . . . . . . . . : 14.96.174.172  
        DNS Servers . . . . . . . . . . . : 121.242.190.180  
                                            121.242.190.210  
        NetBIOS over Tcpip. . . . . . . . : Disabled

For "time wget python.org" I get:

--2011-06-06 17:51:32--  http://python.org/
Resolving python.org... ^C

real    0m7.793s
user    0m0.008s
sys    0m0.000s
supriyo@ubuntu:~$ time wget http://python.org
--2011-06-06 17:51:44--  http://python.org/
Resolving python.org... 82.94.164.162, 2001:888:2000:d::a2
Connecting to python.org|82.94.164.162|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 19229 (19K) [text/html]
Saving to: `index.html'

100%[======================================>] 19,229      30.5K/s   in 0.6s    

2011-06-06 17:51:56 (30.5 KB/s) - `index.html' saved [19229/19229]


real    0m11.398s
user    0m0.004s
sys    0m0.012s

[robsoles]

What I asked for doesn't tell me as much as sanderj's suggestion went on to tell me:

rob@rob-desktop:~$ time wget python.org
--2011-06-06 20:06:55--  http://python.org/
Resolving python.org... 82.94.164.162, 2001:888:2000:d::a2
Connecting to python.org|82.94.164.162|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 19229 (19K) [text/html]
Saving to: `index.html'

100%[======================================>] 19,229      24.0K/s   in 0.8s    

2011-06-06 20:06:57 (24.0 KB/s) - `index.html' saved [19229/19229]


real    0m2.093s
user    0m0.000s
sys    0m0.010s
rob@rob-desktop:~$ wget ipv6.google.com
--2011-06-06 20:10:00--  http://ipv6.google.com/
Resolving ipv6.google.com... 2404:6800:8004::68
Connecting to ipv6.google.com|2404:6800:8004::68|:80... failed: Network is unreachable.
rob@rob-desktop:~$

My ISP is the roadblock there, I think you will find your ISP the road block too. Maybe it is browser settings that is different between your two installations which causes the difference in outcomes.

Try http://ipv6.google.com/

sanderj is on a completely IPv6 enabled route, we aren't unless we tunnel as jtarin suggests - personally I am going to petition my ISP, and switch ISPs if necessary, when that road block starts bothering me.

[sanderj]

[/CODE]

supriyo@ubuntu:~$ time wget http://python.org
--2011-06-06 17:51:44-- http://python.org/
Resolving python.org... 82.94.164.162, 2001:888:2000:d::a2
Connecting to python.org|82.94.164.162|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 19229 (19K) [text/html]
Saving to: `index.html'

100%[======================================>] 19,229 30.5K/s in 0.6s

2011-06-06 17:51:56 (30.5 KB/s) - `index.html' saved [19229/19229]


real 0m11.398s
user 0m0.004s
sys 0m0.012s

[/CODE]

Wow: that's bad: it takes 11+ seconds to get that page. That's exactly what the RIPE site reports: "RED because more than 10 seconds"

Now: where is the delay coming from? In your wget I don't see wget trying to connect via IPv6 (which would explain the delay), so what is it? A slow name-lookup? Run some more tests:

time wget -4 python.org
time host python.org
time wget -4 python.org
time host python.org
time wget 82.94.164.162
time wget -6 python.org

And, yes, run some of them twice in this order; I want to see if there is caching.

[ratcheer]

The reason it works on Windows and not on Ubuntu is that Teredo is enabled by default of recent versions of Windows. This is "6 to 4" functionality. If you want the same thing in Ubuntu, you can install the miredo package and go from there.

The better way to get more genuine IPv6 is to create a "6 in 4" tunnel with an outfit such as Hurricane Electric or SixXS. I use Hurricane Electric and have perfect results on all the various IPv6 test pages.

If you decide to set up a tunnel, it is best to have a router that supports IPv6. If it doesn't, at a minimum it will have to pass protocol 41 packets. What I did was flash my router to a version of dd-wrt that supports IPv6.

To the best of my knowledge, only a very small handful of ISP's actually block protocol 41.

Tim