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.


MichaelNZ

1594 posts

Uber Geek
+1 received by user: 485

Trusted
Net Trust Ltd

#302996 9-Jan-2023 13:33
Send private message

Over the weekend I had to disable IPv6 for yet another client because they could not watch Neon or TVNZ on their Smart TV. But they could apparently view it on their mobile phone (presumably over wifi?)

 

Netflix, who we peer with, worked.

 

No issues with our IPv6. We have supported it for awhile and are very much behind it.

 

Any idea what is happening here?





WFH Linux Systems and Networks Engineer in the Internet industry | Specialising in Mikrotik | APNIC member | Open to job offers | ZL2NET


Create new topic
fe31nz
1294 posts

Uber Geek
+1 received by user: 423


  #3019345 9-Jan-2023 23:23
Send private message

One of the things that breaks IPv6 for a lot a people is having a PPPoE connection to their ISP.  All the available PPP software I have met has a bug that breaks IPv6 - they do not send an ICMPv6 reply when they drop packets that are too long.  If an IPv6 packet is ever dropped for being too long, the IPv6 standard requires that an ICMPv6 "packet too long" reply be sent back to the sender.  If this does not happen, the sender will continue sending long packets that will continue to be dropped.  Unlike IPv4, IPv6 does not allow a packet to be fragmented when it is too long.  So when using IPv6 over a PPPoE connection (or any PPP connection), you need to ensure that the MTU is set so that full length IPv6 packets will pass through the PPP software without being dropped.  The standard MTU of 1500 is used for IPv4 and IPv6 packets by default, and is also often the MTU that you get on your ISP connection by default.  But the PPP protocol adds an extra 8 byte header so for a normal MTU 1500 packet to pass through a PPP connection, the PPP connection needs an MTU of 1500, and the connection it runs over needs an MTU of 1508.  If the connection the PPP runs over is MTU 1500, then only packets up to MTU 1492 will pass through it.  For IPv4 packets in the 1493-1500 range, if they meet a PPP connection with MTU 1492 they will just automatically be fragmented and the two fragments will be small enough to pass through the PPP connection.  This will significantly increase the CPU usage on the router, and will cause slight delays for the IPv4 packets, but it is not usually noticeable unless the router CPU is particularly small.  For IPv6 packets in the 1493-1500 range, they will be unable to be fragmented and will be dropped - silently, so the sender does not know it is happening and keeps on sending big packets.

 

There are a number of solutions to this problem.  The best one is that fibre connections in NZ are overprovisioned by 8 bytes so that the connection the PPP connection runs over can be set to MTU 1508.  Only later versions of the PPP software support MTUs greater than 1492, but those later versions are generally what is found in routers now.  But often routers will still default to using MTU 1492 for a PPP connection, so they have to be specifically set to MTU 1500.  Then the VLAN connection over the PPP connection also needs to be set to MTU 1508, if the ISP uses VLAN, and the connection the VLAN runs over (which on fibre is a pseudo Ethernet connection) needs to be set to MTU 1508 also.  For Ubiquiti EdgeRouters such as my ER4, you have to manually set the 1508/1508/1500 MTUs and then IPv6 will work properly with MTU 1500 packets.  A lot of other routers also support doing this, but they usually need to be manually set to this also.  For FritzBoxes on 2Degrees, they are normally remotely configured by 2Degrees and the standard setup that is loaded into them has the 1508/1508/1500 settings.  If you buy a FritzBox for yourself and do not configure it to allow 2Degrees to configure it remotely, and do not install the 2Degrees version of firmware, I believe they also will default to 1500/1500/1492.  Other ISPs that do remote configuration may now also be sending 1508/1508/1500 settings if they support IPv6 - I certainly hope they are.

 

Another solution to the problem is to tell your router in its IPv6 Router Advertisement (RA) packets to advertise an IPv6 MTU of 1492.  Not all routers can be configured to do this, but a lot can.  This then sets the MTU used to send IPv6 packets via the router small enough that the packets will pass through the PPP connection.  The downside of this is that all the IPv6 connections on your network under that router will inherit the 1492 MTU, so packets that are not going via the PPP interface will also be reduced in size, reducing the efficiency of IPv6 and slowing its traffic a bit.  This is better than having non-working external IPv6 connections, but is quite annoying to people like me who like everything to work properly.  There are some other more esoteric variations on this method which can be done in good routers, but they generally have much the same effect.

 

If you enable IPv6 and have this PPP IPv6 MTU problem, the normal way you find out is that connections to the front page of facebook.com stop working and your teenagers let you know all about it - they can not log in!  Then you disable IPv6 and it works again.  That is because the facebook.com front page sends quite a number of full length IPv6 packets, which then get dropped by your router's PPP connection when they get to it.  So you never receive those packets.  It is a few years since I last tested facebook.com, but I think it still works like that.

 

The problem here is not IPv6, but the buggy PPP software - IPv6 is working as designed.  I have no idea why the PPP bug has not been fixed, but it has now been around for at least 10 years.




MichaelNZ

1594 posts

Uber Geek
+1 received by user: 485

Trusted
Net Trust Ltd

  #3019347 9-Jan-2023 23:34
Send private message

Thanks very much for your awesome detailed reply @fe31nz

 

I have had all sorts of issues running IPv6 over L2TP VPN which I attributed to MTU but was not aware this issue stretched out to 1492.

 

On my own connection I have PTP addressing (not PPP) so have the full 1500 and no issues. But I also don't have a TV.

 

I will test this :-)





WFH Linux Systems and Networks Engineer in the Internet industry | Specialising in Mikrotik | APNIC member | Open to job offers | ZL2NET


Create new topic








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.