Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.


Filter this topic showing only the reply marked as answer View this topic in a long page with up to 500 replies per page Create new topic
1 | 2 


22 posts

Geek


  Reply # 2092885 18-Sep-2018 21:39

Aredwood: Check that your firewall is not blocking ICMP packet too large notification packets. Otherwise the remote server has to keep resending packets with progressively smaller packets, until it can figure out the max MTU supported between itself and you.

 

Hey there, 

 

By any chance can I take a screenshot of my firewall settings to show you for checking? not really a full tech person :( . 


386 posts

Ultimate Geek
+1 received by user: 79


  Reply # 2092907 18-Sep-2018 22:28
Send private message

Mark:

 

I had the same issue ... follow this post exactly!  https://www.geekzone.co.nz/forums.asp?forumid=85&topicid=240157

 

Things improved a lot for me ... but I'm still not 100% sure the MTU size of 1492 is correct for when IPv6 packets go past the first 2Degrees routers.

 

If I do ping tests with the "Do Not Fragment" flag set and the packet size set to 1436 (IPv6 ICMP adds 48bytes ?) and try to ping Googles IPv6 DNS server it fails.

 

[snip]

 

Maybe a network guru can work it out better than me, or tell me where I'm mistaken :-)  I know I set to 1492 and it improved things heaps my Mac and my Xbox (especially the Xbox) but I still think there are other devices down stream from me fragmenting the packets, so I wonder if 1280 is what should be set on the Mac, Xbox and router ?

 

 

There is clearly something wrong with your packet sizes still.  I get this:

 

root@mypvr:/tmp# ping6 -D -s 1452 2001:4860:4860::8844
PING 2001:4860:4860::8844(2001:4860:4860::8844) 1452 data bytes
[1537262049.004282] 1460 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=60 time=37.1 ms
[1537262050.004745] 1460 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=60 time=37.3 ms
[1537262051.004997] 1460 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=60 time=37.1 ms
^C
--- 2001:4860:4860::8844 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 37.101/37.201/37.321/0.240 ms
root@mypvr:/tmp# ping6 -D -s 1453 2001:4860:4860::8844
PING 2001:4860:4860::8844(2001:4860:4860::8844) 1453 data bytes
^C
--- 2001:4860:4860::8844 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5039ms

 

So the largest IPv6 ping packet that gets through is "-s 1452", which creates a packet with 1460 data bytes.  I am using a PPPoE MTU of 1508, so I have MTU 1500 for my WAN interface IP packets, so that is the maximum packet size that should work.

 

The way you want things to work is for the packets you send around your home network on Ethernet or WiFi to have an IP packet size of 1500 bytes, which is the default size.  And for the same size IP packets to be able to be sent and received over the PPPoE connection to 2degrees.  The overhead for a PPPoE connection is an extra 8 bytes, so the Ethernet and VLAN 10 connections via your router WAN port need to be 1508 bytes, and the PPPPoE connection 1500 bytes.  An IP packet ("IP datagram") has a standard size of headers on the front - 24 bytes for IPv4 and 40 bytes for IPv6.  There can also be optional extra headers, but they are rare.  So for IPv4, 1500-24=1476 bytes are available for data.  For IPv6, 1500-40=1460 bytes are available for data.

 

If your WAN connection is not able to be set to 1508 bytes, then the Ethernet and VLAN 10 connections can only be set to 1500 bytes, and when the 8 bytes of PPPoE overhead is subtracted, that leaves 1492 bytes for the IP packets over the PPPoE connection.  That is where the MTU setting of 1492 comes from.  But it should not be necessary to reduce the MTU as all Chorus fibre connections are overprovisioned to support the extra 8 bytes of PPPoE overhead, and 2degrees long ago switched to using routers that support the 1508 MTU for the Ethernet and VLAN 10 interfaces.  And FritzBox firmware can handle the 1500 byte PPPoE connection and defaults to negotiating for that first, and only dropping to 1492 if it is unable to negotiate 1500.

 

If you really do need to use an MTU of 1492 for the PPPoE connection, then that is where things get complicated with IPv6.  IPv4 handles the lower MTU just fine - if necessary, any overlong packets (packet size of 1493 to 1500 bytes) that get to the WAN interface will be automatically fragmented into smaller packets.  The speed of the connection will suffer a little, but mostly you will not notice.  IPv6 is only allowed to fragment packets at source - a router is forbidden to fragment an over long IPv6 packet.  Instead, the over long IPv6 packets will be dropped, and an ICMPv6 "Packet too long" packet should be sent back to the source address of the dropped packet.  This is where the two complications of IPv6 occur.  First, all the PPPoE implemenations I know of, including the one in my FritzBox 7390, fail to send IPv6 "Packet too long" replies when they drop over long IPv6 packets.  This is a serious and long standing bug.  Second, many people have their routers and devices set up to block some (or all) ICMP packets.  If the ICMPv6 "Packet too long" packets are blocked, or never sent by the PPPoE implementation, then the source sending those over long packets never knows to reduce its packet size, so it will keep sending over long IPv6 packets and getting them dropped.  So what is neccessary in this situation is that your IPv6 sources all know about the 1492 byte MTU limitation, and do not send IPv6 packets longer than that.  There are various ways of doing that.  The simplest one (but the messiest), is to manually set the settings on each of your devices' IPv6 interfaces to have an MTU of 1492.  Not all devices allow that, although it can usually be done for PCs.  A better way, that I used with 2degrees before they changed their routers to support a PPPoE MTU of 1500, is to use the ability of IPv6 routers to send an MTU setting in their IPv6 Router Advertisement (RA) packets.  IPv6 requires that before sending packets to other than the local LAN segment, an IPv6 device has seen an RA packet to tell it where to send its IPv6 packets.  The router sending the RA packets can be set to send an "MTU 1492" field as part of the RA packet, and that solves the problem.

 

What I do not know is whether a FritzBox which is set to use a WAN MTU of 1492 will then automatically add the "MTU 1492" field to its RA packets.  If it does, then IPv6 should just work correctly, but if not, then you would need to find out how to change that setting manually.  I use a Ubiquiti EdgeRouter Lite, not a FritzBox, so I have never used a FritzBox with MTU 1492.  In the ERLite, I have to manually add the RA MTU 1492 setting.

 

The first thing I would try with a FritzBox is to remove any manual MTU settings and just let it negotiate for the best it can get.  It should be able to negotiate for MTU 1500 on the PPPoE interface, and then everything should just work.  You also need to check that you are not blocking all the ICMPv6 packets that are specified as being necessary for IPv6 to work.  They could be being blocked in your router, or in any other firewalls in your network devices.  I would recommend just turning off all settings that block ICMP packets and see if that helps.


 
 
 
 




22 posts

Geek


  Reply # 2092912 18-Sep-2018 22:46

fe31nz:

 

Mark:

 

I had the same issue ... follow this post exactly!  https://www.geekzone.co.nz/forums.asp?forumid=85&topicid=240157

 

Things improved a lot for me ... but I'm still not 100% sure the MTU size of 1492 is correct for when IPv6 packets go past the first 2Degrees routers.

 

If I do ping tests with the "Do Not Fragment" flag set and the packet size set to 1436 (IPv6 ICMP adds 48bytes ?) and try to ping Googles IPv6 DNS server it fails.

 

[snip]

 

Maybe a network guru can work it out better than me, or tell me where I'm mistaken :-)  I know I set to 1492 and it improved things heaps my Mac and my Xbox (especially the Xbox) but I still think there are other devices down stream from me fragmenting the packets, so I wonder if 1280 is what should be set on the Mac, Xbox and router ?

 

 

There is clearly something wrong with your packet sizes still.  I get this:

 

root@mypvr:/tmp# ping6 -D -s 1452 2001:4860:4860::8844
PING 2001:4860:4860::8844(2001:4860:4860::8844) 1452 data bytes
[1537262049.004282] 1460 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=60 time=37.1 ms
[1537262050.004745] 1460 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=60 time=37.3 ms
[1537262051.004997] 1460 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=60 time=37.1 ms
^C
--- 2001:4860:4860::8844 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 37.101/37.201/37.321/0.240 ms
root@mypvr:/tmp# ping6 -D -s 1453 2001:4860:4860::8844
PING 2001:4860:4860::8844(2001:4860:4860::8844) 1453 data bytes
^C
--- 2001:4860:4860::8844 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5039ms

 

So the largest IPv6 ping packet that gets through is "-s 1452", which creates a packet with 1460 data bytes.  I am using a PPPoE MTU of 1508, so I have MTU 1500 for my WAN interface IP packets, so that is the maximum packet size that should work.

 

The way you want things to work is for the packets you send around your home network on Ethernet or WiFi to have an IP packet size of 1500 bytes, which is the default size.  And for the same size IP packets to be able to be sent and received over the PPPoE connection to 2degrees.  The overhead for a PPPoE connection is an extra 8 bytes, so the Ethernet and VLAN 10 connections via your router WAN port need to be 1508 bytes, and the PPPPoE connection 1500 bytes.  An IP packet ("IP datagram") has a standard size of headers on the front - 24 bytes for IPv4 and 40 bytes for IPv6.  There can also be optional extra headers, but they are rare.  So for IPv4, 1500-24=1476 bytes are available for data.  For IPv6, 1500-40=1460 bytes are available for data.

 

If your WAN connection is not able to be set to 1508 bytes, then the Ethernet and VLAN 10 connections can only be set to 1500 bytes, and when the 8 bytes of PPPoE overhead is subtracted, that leaves 1492 bytes for the IP packets over the PPPoE connection.  That is where the MTU setting of 1492 comes from.  But it should not be necessary to reduce the MTU as all Chorus fibre connections are overprovisioned to support the extra 8 bytes of PPPoE overhead, and 2degrees long ago switched to using routers that support the 1508 MTU for the Ethernet and VLAN 10 interfaces.  And FritzBox firmware can handle the 1500 byte PPPoE connection and defaults to negotiating for that first, and only dropping to 1492 if it is unable to negotiate 1500.

 

If you really do need to use an MTU of 1492 for the PPPoE connection, then that is where things get complicated with IPv6.  IPv4 handles the lower MTU just fine - if necessary, any overlong packets (packet size of 1493 to 1500 bytes) that get to the WAN interface will be automatically fragmented into smaller packets.  The speed of the connection will suffer a little, but mostly you will not notice.  IPv6 is only allowed to fragment packets at source - a router is forbidden to fragment an over long IPv6 packet.  Instead, the over long IPv6 packets will be dropped, and an ICMPv6 "Packet too long" packet should be sent back to the source address of the dropped packet.  This is where the two complications of IPv6 occur.  First, all the PPPoE implemenations I know of, including the one in my FritzBox 7390, fail to send IPv6 "Packet too long" replies when they drop over long IPv6 packets.  This is a serious and long standing bug.  Second, many people have their routers and devices set up to block some (or all) ICMP packets.  If the ICMPv6 "Packet too long" packets are blocked, or never sent by the PPPoE implementation, then the source sending those over long packets never knows to reduce its packet size, so it will keep sending over long IPv6 packets and getting them dropped.  So what is neccessary in this situation is that your IPv6 sources all know about the 1492 byte MTU limitation, and do not send IPv6 packets longer than that.  There are various ways of doing that.  The simplest one (but the messiest), is to manually set the settings on each of your devices' IPv6 interfaces to have an MTU of 1492.  Not all devices allow that, although it can usually be done for PCs.  A better way, that I used with 2degrees before they changed their routers to support a PPPoE MTU of 1500, is to use the ability of IPv6 routers to send an MTU setting in their IPv6 Router Advertisement (RA) packets.  IPv6 requires that before sending packets to other than the local LAN segment, an IPv6 device has seen an RA packet to tell it where to send its IPv6 packets.  The router sending the RA packets can be set to send an "MTU 1492" field as part of the RA packet, and that solves the problem.

 

What I do not know is whether a FritzBox which is set to use a WAN MTU of 1492 will then automatically add the "MTU 1492" field to its RA packets.  If it does, then IPv6 should just work correctly, but if not, then you would need to find out how to change that setting manually.  I use a Ubiquiti EdgeRouter Lite, not a FritzBox, so I have never used a FritzBox with MTU 1492.  In the ERLite, I have to manually add the RA MTU 1492 setting.

 

The first thing I would try with a FritzBox is to remove any manual MTU settings and just let it negotiate for the best it can get.  It should be able to negotiate for MTU 1500 on the PPPoE interface, and then everything should just work.  You also need to check that you are not blocking all the ICMPv6 packets that are specified as being necessary for IPv6 to work.  They could be being blocked in your router, or in any other firewalls in your network devices.  I would recommend just turning off all settings that block ICMP packets and see if that helps.

 

 

Hey there,

 

 

 

I’m not sure if your reply is also for me, but I read your instructions.

 

 

 

The Fritbox does indeed have a way to set the MTU. If you want to see it, feel free to let e know, I am more than happy to provide a screenshot. However, you can also check here as Nick from 2D has provided the photos of the settings for configuration for the Fritzbox to use ipv6 (https://www.geekzone.co.nz/forums.asp?forumid=85&topicid=240157) which I of course have “already” applied and copied but still issue persist.

 

 

 

Have tried manually setting the MTU to 1492 and 1500 as stated above. For the firewall part you mentioned, do you want me to provide a screenshot for you to check whether it is blocking?

 

 

 

Thanks




22 posts

Geek


  Reply # 2092914 18-Sep-2018 22:48

michaelmurfy:

 

Edited posts to remove name.

I'm also not having any issues with IPv6 so this is just your setup. If you've just transferred to 2degrees it may take a moment for their automation to fully provision you.

 

Also - Speeds over IPv6 are nearing Gigabit speeds for me.

 

Edit: Also using Cloudflare's DNS resolvers over IPv6 through DNS over HTTPS.

 

 

 

 

Thanks for removing my name. I have also gone through and changed my name and removed it with keeping it private as advice by Spark member.

 

 

 

I've joined 2D last week Wednesday so I think the automation has already been fully provision to me. 

 

 

 

Thanks


Mr Snotty
8072 posts

Uber Geek
+1 received by user: 4049

Moderator
Trusted
Lifetime subscriber

  Reply # 2092920 18-Sep-2018 23:18
Send private message

Have you contacted 2degrees and spoken to them as Nick has asked multiple times?







22 posts

Geek


  Reply # 2092921 18-Sep-2018 23:22

michaelmurfy:

 

Have you contacted 2degrees and spoken to them as Nick has asked multiple times?

 

 

As mentioned a few hours ago, I have not been able to call them since I mostly work from early morning to late night-time - no free time. Will try and find a time to call 2Degrees and spend 2 hours with them to diagnose the problem. Thanks for reminding me though. 


Mr Snotty
8072 posts

Uber Geek
+1 received by user: 4049

Moderator
Trusted
Lifetime subscriber

  Reply # 2092935 19-Sep-2018 07:21
One person supports this post
Send private message

YummyTech:

 

michaelmurfy:

 

Have you contacted 2degrees and spoken to them as Nick has asked multiple times?

 

 

As mentioned a few hours ago, I have not been able to call them since I mostly work from early morning to late night-time - no free time. Will try and find a time to call 2Degrees and spend 2 hours with them to diagnose the problem. Thanks for reminding me though.

 

You need to call them. There is a number of reasons behind this. You're wasting your time here hence why I originally locked this thread.

Also, for everyone else having issues with IPv6 on your Fritz!Box - Call them! They can push out the correct settings for you.





defiant
689 posts

Ultimate Geek
+1 received by user: 329

Lifetime subscriber

  Reply # 2093075 19-Sep-2018 11:46
Send private message

Out of interest I wanted to see if my setup was all good on 2degs, and for some reason I can only ping 2001:4860:4860::8844 with a packet size of 1452 from one out of two linux hosts and none of my Windows machines.

 

Surely if my MTU was incorrect I wouldn't be able to do it from anything? I've got MTU 1508 set on ETH0 and ETH0.10 and 1500 MTU on my pppoe0 interfaces.

 

Working:

 

x@ramen:~$ ping6 -c 4 -s 1452 2001:4860:4860::8844
PING 2001:4860:4860::8844(2001:4860:4860::8844) 1452 data bytes
1460 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=60 time=34.9 ms
1460 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=60 time=34.7 ms
1460 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=60 time=34.9 ms
1460 bytes from 2001:4860:4860::8844: icmp_seq=4 ttl=60 time=34.9 ms

 

--- 2001:4860:4860::8844 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 34.771/34.925/34.998/0.207 ms

 

Nope:

 

x@ubuntu:~# ping6 -c 4 -s 1452 2001:4860:4860::8844
PING 2001:4860:4860::8844(2001:4860:4860::8844) 1452 data bytes

 

--- 2001:4860:4860::8844 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3056ms

 

However, if I pick another ipv6 host like wikipedia it works fine:

 

x@ubuntu:~# ping6 -c 4 -s 1452 wikipedia.org
PING wikipedia.org(text-lb.eqsin.wikimedia.org (2001:df2:e500:ed1a::1)) 1452 data bytes
1460 bytes from text-lb.eqsin.wikimedia.org (2001:df2:e500:ed1a::1): icmp_seq=1 ttl=55 time=333 ms
1460 bytes from text-lb.eqsin.wikimedia.org (2001:df2:e500:ed1a::1): icmp_seq=2 ttl=55 time=333 ms
1460 bytes from text-lb.eqsin.wikimedia.org (2001:df2:e500:ed1a::1): icmp_seq=3 ttl=55 time=333 ms
1460 bytes from text-lb.eqsin.wikimedia.org (2001:df2:e500:ed1a::1): icmp_seq=4 ttl=55 time=333 ms

 

This is going to annoy me, any idea why this is?




22 posts

Geek


  Reply # 2093079 19-Sep-2018 11:54

michaelmurfy:

 

YummyTech:

 

michaelmurfy:

 

Have you contacted 2degrees and spoken to them as Nick has asked multiple times?

 

 

As mentioned a few hours ago, I have not been able to call them since I mostly work from early morning to late night-time - no free time. Will try and find a time to call 2Degrees and spend 2 hours with them to diagnose the problem. Thanks for reminding me though.

 

You need to call them. There is a number of reasons behind this. You're wasting your time here hence why I originally locked this thread.

Also, for everyone else having issues with IPv6 on your Fritz!Box - Call them! They can push out the correct settings for you.

 

 

 

 

Hey there Michael and @NickMack and the rest of the gang,

 

 

 

I have taken time off work today since I want to fix this issue and report back to you guys. 

 

 

 

I have called 2Degrees tech support. They have requested a firmware update which was already updated and turned off the router for 25 seconds and turned it back on. Tested speed test with both ipv6 on and off and the speeds were great and had no issue. Though the problem of ipv6 slow loading websites and such still persist and occurs. They say it may be the ethernet cable provided by 2D which I don't think is the problem since the ethernet cat6 cable I purchased from PB Tech works perfectly. 2degrees then told me to do a traceroute using command prompt which I have just done x2. Sent them the screenshot to the provided email. Currently on the phone again as they have requested me to call them back to analyse the traceroute results and to perform more methods to diagnose the issue. Can only say that the traceroute results contain many request timed out. Will keep you all updated. Thanks 


Mr Snotty
8072 posts

Uber Geek
+1 received by user: 4049

Moderator
Trusted
Lifetime subscriber

  Reply # 2093090 19-Sep-2018 12:28
2 people support this post
Send private message

Speedtests won't have any affect with IPv6 being on or off.

 

I'm going to lock this again as there isn't any actual problem here. There is too much incorrect information floating around on this thread and everyone is having separate issues, it is just causing way too much confusion here and I don't want to see incorrect information being posted about any provider to ensure nobody else gets misinformed about a problem that doesn't exist.

 

- If you've got a Fritz!Box and are on 2degrees then the first thing to do is call 0800 022 022 and get them to investigate. This is an important step.
- Also, follow the guide: https://www.geekzone.co.nz/forums.asp?forumid=85&topicid=240157 - if that doesn't work, factory reset your Fritz!Box, let it autoprovision and you should have the correct settings from this point.

 

I've been unable to replicate any of the issues here on both a Fritz!Box and my Edgerouter. Use common sense, if it is only one website affected then it may be that website.

 

Lastly, I don't see any of your posts going via IPv6. If IPv6 is indeed enabled and you're using the same connection to access Geekzone (and are not seeing the IPv6 logo show up) then you may have some local issues either related to the firewall on your computer or your own router.

 

Bare in mind - some users on Chorus connections are currently affected by an IPv6 bug - I don't think this is the case with you however. There is a separate thread here.





1 | 2 
Filter this topic showing only the reply marked as answer View this topic in a long page with up to 500 replies per page Create new topic



Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.