ipv6 sloooow tonight

[#1]

Looks like a peering issue - see http://forums.thinkbroadband.com/general/t/4320276-ipv6-speed.html - I've tried using the NASA contact form so see if they respond.

[#2]

Quote from: MJN

I might able to shed some light on it! Mathew

Ok mathew but you forgot pppoe can be used with 1500 bytes using jumbo frames (RFC 4638), I dont know if andyh was taking advantage of this but I was and was previously working on ipv6 and still works on ipv4.
Also you forgot ipv6 was fine up until a few weeks ago.
So something has changed plusnet side that seems to have either (a) imposed a 1492 mtu limit or (b) stopped mtu discovery working on ipv6 (meaning the 1492 limit was always there)..
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/configuration/15-2mt/ip6-15-2mt-book/ip6-mtu-p...
in my opinion plusnet need to hunt down the problem, I offer a theoretical situation.
plusnet rollout ipv6 to adsl and vdsl customers.
most routers on pppoa default to 1500 byte mtu's (which adsl customers will use).
these customers then get the problem due to the broken mtu discovery and arbitery 1492 limit on plusnet's ipv6 network.
I have been busy with other things this past week so have done no ipv6 tests at all, I plan to now get back on this my end to try and get some answers.  One answer I want is why when I set the ipv6 mtu on windows its not overiding the higher mtu on the router.

[#3]

Quote from: chrcoluk

Ok mathew but you forgot pppoe can be used with 1500 bytes using jumbo frames (RFC 4638), I dont know if andyh was taking advantage of this but I was and was previously working on ipv6 and still works on ipv4.

Not so much forgetting about it, more a case of being completely unaware of it!
I note it's not actually a standard, but you say Plusnet definitely support it? I'm not implying they couldn't support a non-standardised mechanism, just curious that they do. Can you elaborate how you achieve it, perhaps in another thread, as it could definitely be of benefit to others?

Quote

One answer I want is why when I set the ipv6 mtu on windows its not overiding the higher mtu on the router.

What do you mean by this? Remember that setting the MTU in Windows only changes the host's perception of the MTU of the link; it is not going to change what the router thinks it is. In IPv6 the only way to influence another device's MTU setting for a given link is through an RA which only a router can send.

[#4]

Plusnet I assume do not support RFC 4638 as most isps probably wont.
If I understand you correctly end points on IPv6 cannot negotiate MTU/MSS?

[#5]

It's not so much that end point negotiate an MTU. The MTU is a property of the underlying link and so it is what it is. What the end point has to do is work out what the minimum MTU is between it and the destination. The first link is easy - it gets told what it is by the router (in an RA), but it is the rest of the links from then on that's the problem. This is where PMTU discovery comes into place but for it to work the ICMP messages that it uses must be properly created by the router that can't carry the fragment, be passed back successfully, and fully understood and acted upon my the sender. That's a lot of opportunities for things to go wrong, and a big reliance on everything following the standards!

[#6]

whatever it was, its been fixed.  Someone at plusnet I guess found it but dont want to disclose what it was.
After I reported to tbb the ipv6 tester works again now also and thats fine also.

[#7]

Quote from: chrcoluk

Someone at plusnet I guess found it but dont want to disclose what it was.

To the best of my knowledge we haven't changed anything to either break it or fix it.

[#8]

@ Paul
Coming back to what you tried before from your core router:

Quote

phughes@ptw-cr01-re0> ping 2a02:16c8:2000:xxxx:: size 1444 PING6(1492=40+8+1444 bytes) 2a02:16c8::a --> 2a02:16c8:2000:xxxx:: 1452 bytes from 2a02:16c8:2000:xxxx:a6b1:e9ff:fe17:da16, icmp_seq=0 hlim=63 time=6.397 ms phughes@ptw-cr01-re0> ping 2a02:16c8:2000:xxxx:: size 1445 PING6(1493=40+8+1445 bytes) 2a02:16c8::a --> 2a02:16c8:2000:xxxx:: ^C --- 2a02:16c8:2000:xxxx:: ping6 statistics --- 5 packets transmitted, 0 packets received, 100% packet loss

When you tried the 1445 byte packet, should it not have come back "Packet too big" rather than dropping the packet with no error?

[#9]

Quote from: paulmh5

Quote from: chrcoluk Someone at plusnet I guess found it but dont want to disclose what it was. To the best of my knowledge we haven't changed anything to either break it or fix it.

##
will be one of those unresolved mysteries then I guess.
will report back if it breaks again.

[#10]

@ MJN - Any idea why I am unable to change the MTU for IPv6 in Ubuntu?

Quote

eth0$ tracepath6 ipv6.thinkbroadband.com 1?: [LOCALHOST]                        0.489ms pmtu 1480 1:  2a02:16c8:2000:1100:5246:5dff:fe6d:ef70              0.505ms 1:  2a02:16c8:2000:1100:5246:5dff:fe6d:ef70              0.466ms 2:  2a02:16c8:0:1::15                                    7.051ms 3:  2a02:16c8:1:2::19                                    5.427ms asymm  6 4:  2a02:16c8::d                                          6.062ms 5:  2a02:16c8:1:2::8                                      5.543ms 6:  lonap.he.net                                        10.435ms 7:  ipv6.lonap-gw2.rbsov.ncuk.net                        5.851ms 8:  gi1-0-24-10-star1.core-rs2.thdo.ncuk.net              7.649ms 9:  no reply 10:  no reply

Quote

sudo sysctl -w net.ipv6.conf.eth0.mtu=1500 sudo sysctl -p sysctl -a|grep mtu net.ipv6.conf.all.mtu = 1280 net.ipv6.conf.default.mtu = 1280 net.ipv6.conf.eth0.mtu = 1480

[#11]

is it 1480 on the router?

only reason I can think off hand is it detects 1480 is the max that will work and is preventing it for that reason.
as bear in mind even tho my ipv6 is working again with the router set at 1500, its set to 1492 in windows, and I havent tested if ipv6 is actually using 1500, I know ipv4 is after testing on speedguide.net but not done any tests on ipv6 yet I just know its performing at normal levels.

[#12]

Andy, what's in /etc/sysctl.conf and howcome you're running sysctl -p?
Perhaps it can't be changed on the fly and requires the interface to go down and back up?
(if you think I'm guessing you're right!)

[#13]

It's the default conf and I added at the end:
net.ipv6.conf.eth0.mtu=1500
I'm sysctl -p to reload the config. The problem is - the MTU keeps reverting back to 1480 for v6.
If you run sysctl -a|grep net.ipv6.conf.eth0.mtu do you get 1480 also?
@ chrcoluk - I have a feeling this is in the Asus firmware somewhere. I am trying to figure out if the IPv6 MTU is broadcast with DHCP6 or radvd.

[#14]

Have you bounced the interface in case it can't be changed on the fly? Are you able to set it lower than 1480?

[#15]

Yep, can set it lower. Just not higher for some reason.
Tried bouncing the interface - no luck there.