ipv6 sloooow tonight
Quote from: AndyH The MTU stuff is a little bit beyond me also 
I might able to shed some light on it!
Quote A 1492 byte IP packet (1492 = 1444 bytes + 40 bytes + 8 bytes) works fine over v6
Okay. That's good.
Quote Anything above 1492 bytes fails
This to be expected. As you've said, the MTU for PPPoE is 1492.
Quote On v4, I can send any size.
You can, but only because your router is is splitting the packet up, i.e. fragmenting it, in order to allow it to traverse the PPPoE link.
Tell ping to set the 'do not fragment' bit and you'll see a different story:
$ ping -s 9999 -c 5 ipv4.thinkbroadband.com -M do
PING ipv4.thinkbroadband.com (80.249.99.130) 9999(10027) bytes of data.
From rugrat (192.168.1.36) icmp_seq=1 Frag needed and DF set (mtu = 1500)
From rugrat (192.168.1.36) icmp_seq=1 Frag needed and DF set (mtu = 1500)
From rugrat (192.168.1.36) icmp_seq=1 Frag needed and DF set (mtu = 1500)
From rugrat (192.168.1.36) icmp_seq=1 Frag needed and DF set (mtu = 1500)
From rugrat (192.168.1.36) icmp_seq=1 Frag needed and DF set (mtu = 1500)
--- ipv4.thinkbroadband.com ping statistics ---
0 packets transmitted, 0 received, +5 errors
So, the 1492 MTU (1500 for me as I'm on PPPoA) actually impacts IPv4 and IPv6 in the same way i.e. fragmentation has to occur if necessary. The reason why the IPv6 ping fails to get through with the bigger packet sizes is because under IPv6 intermediate routers no longer fragment packets. Instead, this is now the sole responsibility of the host(s). For the hosts to know that it needs to fragment it relies on ICMP packet-too-big messages but there are many reasons why these either don't get generated or transferred.
Try ping6 without any fragmentation attempt (again using '-M do', although note that it doesn't set the DF bit because in IPv6 there is no DF bit but it will have the same effect for us here) and see what you get. This is what I see:
$ ping6 -s 9999 -c 5 ipv6.thinkbroadband.com -M do
PING ipv6.thinkbroadband.com(www.thinkbroadband.com) 9999 data bytes
From 2a02:16c8:2000:e00::36 icmp_seq=1 Packet too big: mtu=1500
From 2a02:16c8:2000:e00::36 icmp_seq=1 Packet too big: mtu=1500
From 2a02:16c8:2000:e00::36 icmp_seq=1 Packet too big: mtu=1500
From 2a02:16c8:2000:e00::36 icmp_seq=1 Packet too big: mtu=1500
From 2a02:16c8:2000:e00::36 icmp_seq=1 Packet too big: mtu=1500
--- ipv6.thinkbroadband.com ping statistics ---
0 packets transmitted, 0 received, +5 errors
Mathew
Hmm I tried to send a 1501 byte packet packet (1453 + 40 + and the payload length of the first ping in the tcpdump was 32 bytes.
Something else I don't quite get - if I ping bbc.co.uk in v4 with a 1500 byte packet from my router, it works fine. If I try a 1501 byte packet, it fails to respond. If I do the same for www.plusnet.net, I get random results (2-3 dropped packets on a 5 ping count).
and the payload length of the first ping in the tcpdump was 32 bytes.Something else I don't quite get - if I ping bbc.co.uk in v4 with a 1500 byte packet from my router, it works fine. If I try a 1501 byte packet, it fails to respond. If I do the same for www.plusnet.net, I get random results (2-3 dropped packets on a 5 ping count).
My understanding of all of this is that there seems to be no MTU path discovery for v6 traffic because no "packet too big" messages are being received. This has caused problems when the source device sends unfragmented packets larger than 1492 bytes (even fragmented packets don't seem to be handled correctly).
Juniper give a good explanation of what should happen:
What I am not quite sure about is where these 'packet too big' messages should be coming from. Is it my router? modem? L2 Switch in the exchange? Plusnet's gateways? The host?
Something else which I did not realise is that, by default, Windows machines have an MTU of 1280 for v6. So I am not quite sure why I was still unable to access certain v6 sites with a low MTU. The MTU of the router shouldn't have made a difference (I think!).
Has anyone tried a v6 > v6 native VPN yet? This is something which would be interesting.
I've had no other issues now with v6 - I can access everything without a problem
Juniper give a good explanation of what should happen:
Quote IPv6 defines a standard mechanism called path MTU discovery that a source node can use to learn the path MTU of a path that a packet is likely to traverse. If any of the packets sent on that path are too large to be forwarded by a node along the path, that node discards the packet and returns an ICMPv6 Packet Too Big message. The source node can then adjust the MTU size to be smaller than that of the node that dropped it and sent the ICMPv6 message, and then retransmit the packet. A source node might receive Packet Too Big messages repeatedly until its packet traverses all nodes along the path successfully.
What I am not quite sure about is where these 'packet too big' messages should be coming from. Is it my router? modem? L2 Switch in the exchange? Plusnet's gateways? The host?
Something else which I did not realise is that, by default, Windows machines have an MTU of 1280 for v6. So I am not quite sure why I was still unable to access certain v6 sites with a low MTU. The MTU of the router shouldn't have made a difference (I think!).
Has anyone tried a v6 > v6 native VPN yet? This is something which would be interesting.
I've had no other issues now with v6 - I can access everything without a problem
Quote from: jelv Wireshark has been uploaded to ticket 83851787
Does this suggest why it's so slow?
