ipv6 sloooow tonight

[#1]

On ADSL 21CN, not seeing the problem.
Let me know if you want any tests carried out.

[#2]

@ chrcoluk
Do you have QoS enabled?
Have you tried changing the MTU of the ethernet port (from telnet ifconfig eth0 mtu 1460)?
What about if you download a single file over IPv6 - http://ipv6.download.thinkbroadband.com/1GB.zip what is your speed like then?
What if you put your router's IPv6 address in here http://www.letmecheck.it/mtu-test.php - do you get 1492 as your max MTU?
Edit: Something else - Asus are apparently aware of further IPv6 issues in both their stock and Merlin's builds. I've asked for clarification on what issues. They've given me a couple of development firmware releases to try, but there is something else wrong with my IPv6 which needs to be found and solved first.

[#3]

2nd site gives The maximum MTU size for xxxxx is: 1500
tbb download url is approx 2mbit/sec.
I dont think its my firmware as I have had this firmware installed for about a month now, was working for weeks before this issue started.
the mtu test was done on my router ip as my pc isnt allowing icmp.
my pc mtu for ipv6 is actually down to 1400 bytes mtu to rule out mtu issues.

Quote

C:\Windows\system32>netsh interface ipv6 show subinterfaces   MTU  MediaSenseState  Bytes In  Bytes Out  Interface ------  ---------------  ---------  ---------  ------------- 4294967295                1          0      17644  Loopback Pseudo-Interface 1   1280                5          0          0  isatap.MerlinASUS   1400                1    2976619    182173  Local Area Connection

[#4]

this loads and says I have no mtu issues.
http://www.ipv6chicken.com/

[#5]

thanks to andy for his time assisting me.
Still no explanation as to the cause of the problem other than to say starting a new login session has brought ipv6 speeds back to normal.

[#6]

[#7]

was a mistake.
but glad you here kelly.
it seems it was mtu.
the moment I reduced my router down to 1492 bytes speeds are back.  so have plusnet reconfigured anything related to mss/mtu on ipv6?  for weeks it was fine at 1500 bytes using RFC 4638 workaround.
unusually overiding mtu on the pc wasnt enough.

[#8]

The MTU stuff is beyond my technical know how tbh!  I think there is some negotiation of MTU sizing which occurs on IPv4 which doesn't happen with v6 (or not in our trial configuration) so it's suddenly a lot more important for the size to be correct.
I don't understand why it will have suddenly changed though!

[#9]

The MTU stuff is a little bit beyond me also  
There is a bit of a guide here about overheads - http://sd.wareonearth.com/~phil/net/overhead/
A 1492 byte IP packet (1492 = 1444 bytes + 40 bytes +  8 bytes) works fine over v6:

Quote

admin@RT-N66U:/tmp/home/root# ping6 -s 1444 -c 5 ipv6.thinkbroadband.com PING ipv6.thinkbroadband.com (2a02:68:1::4): 1444 data bytes 1452 bytes from 2a02:68:1::4: seq=0 ttl=58 time=5.866 ms 1452 bytes from 2a02:68:1::4: seq=1 ttl=58 time=5.702 ms 1452 bytes from 2a02:68:1::4: seq=2 ttl=58 time=5.972 ms 1452 bytes from 2a02:68:1::4: seq=3 ttl=58 time=5.703 ms 1452 bytes from 2a02:68:1::4: seq=4 ttl=58 time=5.566 ms --- ipv6.thinkbroadband.com ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 5.566/5.761/5.972 ms

Anything above 1492 bytes fails:

Quote

admin@RT-N66U:/tmp/home/root# ping6 -s 1445 -c 5 ipv6.thinkbroadband.com PING ipv6.thinkbroadband.com (2a02:68:1::4): 1445 data bytes --- ipv6.thinkbroadband.com ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss

On v4, I can send any size. So as Kelly says, there must be a limitation (1492/1500 PPPoE? 1508 ADSL?) enforced PN's end:

Quote

admin@RT-N66U:/tmp/home/root# ping -s 9999 -c 5 ipv4.thinkbroadband.com PING ipv4.thinkbroadband.com (80.249.99.130): 9999 data bytes 10007 bytes from 80.249.99.130: seq=0 ttl=59 time=11.426 ms 10007 bytes from 80.249.99.130: seq=1 ttl=59 time=11.118 ms 10007 bytes from 80.249.99.130: seq=2 ttl=59 time=10.929 ms 10007 bytes from 80.249.99.130: seq=3 ttl=59 time=10.753 ms 10007 bytes from 80.249.99.130: seq=4 ttl=59 time=10.974 ms --- ipv4.thinkbroadband.com ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 10.753/11.040/11.426 ms

[#10]

ipv6 is defenitly been finicky.
the netsh setting in windows defaults to 1500, indeed right now for ipv4 mine is still set to 1500. ipv4 mtu discovery on windows has detected 1492 bytes and works correctly.
the same netsh setting for ipv6 last night I had to reduce to 1492 bytes, I was unable to load ipv6 sites until I did this. (after router was reduced to 1492 bytes).  so with the pc at 1500 and router at 1492 I had the same problem andyh appeared to have before he fixed it.
with pc and router at 1500, ipv4 works fine, ipv6 was previously working fine, but now it restricts ipv6 throughput to very low speeds.  note pc was still using mtu discovery it used 1500 as it detected 1500.
Now as I understand it, the end to end point if it has a mtu lower than intermediate devices then it will overide.
so eg. if my pc is at 1492 bytes and router at 1500 then the pc should overide the router and the end to end connection uses a mss based on 1492 byte mtu.  This is happening on ipv4, but appeared to not be happening on ipv6 last night.
if a intermediate device has a mtu lower than the end to end so eg. pc at 1500 and router at 1492 then usually mtu discovery should take care of it and reduce the end to end mtu to match, but again this appears to not be working on ipv6.
So another theory.
is it possible mtu was already limited to 1492 on plusnet ipv6, but previously mtu discovery was working and fixing it, but now is broken?

[#11]

chrcoluk - any slow speeds last night are likely down to the same as deathtrap here:
http://community.plus.net/forum/index.php/topic,125587.msg1091777.html#msg1091777
We spotted an issue that affected some users on PTW and you were on PTW last night.
I'll do some digging on the MTU part.

[#12]

Just found this topic because I've suddenly hit a problem with IPv6 speeds on a particular site: http://apod.nasa.gov I'm on pcl-ag03.
Using IPv6, as the pictures absolutely crawl down the screen, NetWorX is showing sub 100Kbps speeds.
Using IPv4 http://129.164.179.22/apod/ap140404.html then click the picture to see the full image it's coming in at over 2000Kbps.
I visit that site most days and haven't had any issue until now, but I'm not aware of whether in the past it was using IPv4 or IPv6.
Edit: Two better URLs to compare:
http://[2001:4d0:2310:150::22]/apod/image/1404/NGC6960_WesternVeil_POSS2_Czernetz4.jpg
http://129.164.179.22/apod/image/1404/NGC6960_WesternVeil_POSS2_Czernetz4.jpg
Edit 2: I'm on 20CN so it's not a fibre specific problem.

[#13]

Wireshark has been uploaded to ticket 83851787
Edit: There's nothing wrong with IPv6 speeds in general:

[#14]

I was going to suggest looking at your MTU, but I tested that site also:
IPv6
2014-04-05 11:42:28 (35.4 KB/s) - 'farside_lro1600.jpg' saved [1509327/1509327]
IPv4
2014-04-05 11:42:41 (317 KB/s) - 'farside_lro1600.jpg.1' saved [1509327/1509327]
I think it's just their site is slow.
It's worth getting an extension on your browser to show you if your site is being fetched in v4 or v6. For Chrome, I use this: https://code.google.com/p/ipvfoo/

[#15]

I have https://addons.mozilla.org/en-US/firefox/addon/4or6/ installed. It was when I went to look at today's picture which was dog slow and spotted that it was using IPv6 that I came to this forum and found this topic. I can't believe today is the first time it's decided to use IPv6 on this site.