Netflix and IPv6

RouterOS General
1

I can not reach the Netflix if i have IPv6 enabled. Or on every 10th try i get netflix to work. I find the solution but i need translatin to Mikrotik talk.

https://www.reddit.com/r/ipv6/comments/evv7r8/ipv6_and_netflix/


----snip from reddit--------
MSS clamping of 1432, or interface MTU of 1508 with PPPoE MTU of 1500 (note that the config tree in Edgerouter tries to set an MTU of 1412 if it’s blank and you make changes to something unrelated)

Since I enabled IPv6 in my house, Netflix has basically not worked - the website doesn’t even load. I contacted Netflix support who told me “IPv6 doesn’t work with IPv4 tunneling”. Now, I’m not expert, but I’m pretty sure I am not tunneling. My ISP provides a /56 prefix, and my router and devices use SLACC to get a public facing IP. Tracert to netflix.com shows a straight IPv6 connection the whole way.

If I disable IPv4 on my PC, I still have connection to IPv6 enabled sites, but Netflix completely refuses to load unless I disable IPv6. Netflix themselves told me I should “disable IPv6” if I want to use Netflix.

I personally would rather not use it, but I have family members in the house who watch Netflix a lot, and it’s getting frustrating when casting to Chromecast takes 3+ attempts before it kicks in.

Has anyone else experienced problems?

Edit: Thanks for everyone willing to offer help with my problem. I will be trying connecting with the stock ISP router when I can, but unfortunately living in a house with other people, I can’t just start booting everyone offline.

Netflix does occasionally work with Chromecast, just takes a few goes, which is a pain, but I will look into what I can do. I don’t think there’s any way of limiting certain devices to NATed IPv4, so looks like I’ll have to live with the problem for now. Maybe start shoving a WiFi point through an IPv4 only VPN and see if it fixes things
------snip from reddit--------


My isp give me /56 subnet so no VPN is in play here.

My config

https://pastebin.com/7p3gZ3iP


Edit: corrected reddit link

2

Set underlying ethernet interface actual MTU to 1520 (value is this high because MikroTik seems to require undocumented padding for PPPoE on layer 2.5, in normal cases of course 1508 is sufficient) and L2 value must be greater than that to ensure VLANs works well, 1598 is good enough.

Now in the PPPoE client, leave MRU and MTU as null, RouterOS will auto-detect the appropriate MTU and MRU that will be negotiated between your ethernet’s interface and then passed through the PON link (if it’s PON) or DSL link etc (some ONTs and modems do not support baby jumbo frames auto-negotiation on their ethernet interface) and finally hit the access concentrator.

I’m 1000% sure your ISP is not RFC4638 compliant. With the above, your IPv6 and IPv4 MTU/MRU issues will be resolved.

Source: I have two uplink providers, once is RFC4638 compliant, the other is not. We solved this MTU issue with the above methods. TCP clamping is no longer required with proper MTU.

3

Connection to ISP is fibre. It is not GPON. It is plain FTTH.

4

What is you PPPoE interface Actual MTU?
Anyway, take a look on this topic too: http://forum.mikrotik.com/t/some-websites-unavailable-on-ipv6/145044/7

5

Thank you for right direction. MTU for IPv6 worked.

6

Bruh, FTTH is Fibre to the home, what in the world is “plain” FTTH? Unless you live right next to AT&T’s NOCs, it is a PON, no way your ISP can afford AON to millions of customers.
It can be GPON or EPON or XG-PON or XGS-PON or 10G-EPON.

Forcing 1280 IPv6 MTU is a poor solution. I don’t know why you’re resistant to fix the actual MTU on the underlying ethernet’s interface like I described and ensuring sufficient padding for any future RFC4638 from your ISP.

Underlying Ethernet

Leave RouterOS to auto-negotiate with the access concentrator based on the new ethernet MTU + jumbo frame negotiation on the PON link

Having proper MRU of 1500 even if ISP caps MTU due to no RFC4638 ensures incoming traffic is unfragmented and therefore full potential performance excluding choking etc on ISP/Local link.

7

How do you know that he forced 1280?

8

This is how: http://forum.mikrotik.com/t/netflix-and-ipv6/145906/1

Updated my post with screenshots: http://forum.mikrotik.com/t/netflix-and-ipv6/145906/6

Anyone with basic knowledge and fundamental understanding of MTU and MTU negotiation should be able to comprehend. And RFC4638 of course.

9

Your magic orb is probably better than mine, maybe he set it to the MTU negotiated by the PPPoE interface, like I wrote on the other topic :slight_smile:
PS: your screenshots kinda proove that your ISP has RFC4638 implemented, otherwise it wouldn’t negotiate 1500 MTU on your PPPoE interface.
Why do you state that it doesn’t (on the other topic)?

10

My english is not so good so i wiil try to explain my plain FTTH. I plug in my fibre direct in SFP in modem.No GPON interface in front of my modem. In our contry was deployed FTTH at first but then started GPON deployment beacuse of price.

SFP is BiDi 1310/1550

11

I have two ISPs. Can’t you see ethernet1/2, pppoe1/2? One is RFC4638 complaint, the other is not. My screenshot of the MTU config will be helpful for users of either type of ISPs.

12

That SFP module is your ISP’s method of handoff, from there you are likely connected by ethernet to the ONU/ONT (modem doesn’t exist in fibre optics), and since that SFP model is rated for 1G, your FTTH is using EPON technology. And the ONT by default is bridged which is great.

Change the ethernet interface MTU and PPPoE client like my screenshots. Your problem will disappear.

13

Ah, you had another post above explaining the two ISP’s, I’ve missed it, sorry.
Did some tests here, is this realy a MikroTik PPPoE implementation bug?
I’ll post some logs with stripped irelevant (I hope) stuff.
Ethernet MTU 1500:

13:20:05 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x20 
13:20:05 pppoe,ppp,debug,packet    <mru 1480> 
13:20:05 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfReq id=0x1 
13:20:05 pppoe,ppp,debug,packet    <mru 1492> 
13:20:05 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfAck id=0x1 
13:20:05 pppoe,ppp,debug,packet    <mru 1492> 
13:20:06 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x21 
13:20:06 pppoe,ppp,debug,packet    <mru 1480> 
13:20:06 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfAck id=0x21 
13:20:06 pppoe,ppp,debug,packet    <mru 1480>

Ethernet MTU 1508:

13:29:52 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x28 
13:29:52 pppoe,ppp,debug,packet    <mru 1488> 
13:29:52 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfReq id=0x1 
13:29:52 pppoe,ppp,debug,packet    <mru 1492> 
13:29:52 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfAck id=0x1 
13:29:52 pppoe,ppp,debug,packet    <mru 1492> 
13:29:53 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x29 
13:29:53 pppoe,ppp,debug,packet    <mru 1488> 
13:29:53 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfAck id=0x29 
13:29:53 pppoe,ppp,debug,packet    <mru 1488>

Ethernet MTU 1512, there is a new “ppp-max-payload” packet showing up in the packets before the ones posted above, (it doesn’t show up with 1500 or 1508).

 
13:20:32 pppoe,debug,packet ether1: sent PADI to FF:FF:FF:FF:FF:FF 
13:20:32 pppoe,debug,packet     ppp-max-payload=1492 
13:20:33 pppoe,debug,packet ether1: sent PADI to FF:FF:FF:FF:FF:FF 
13:20:33 pppoe,debug,packet     ppp-max-payload=1492 
13:20:33 pppoe,debug,packet ether1: rcvd PADO from 1C:20:DB:XX:XX:XX 
13:20:33 pppoe,debug,packet ether1: sent PADR to 1C:20:DB:XX:XX:XX 
13:20:33 pppoe,debug,packet     ppp-max-payload=1492 
13:20:33 pppoe,debug,packet ether1: rcvd PADS from 1C:20:DB:XX:XX:XX 

13:20:33 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x23 
13:20:33 pppoe,ppp,debug,packet    <mru 1492> 
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfReq id=0x1 
13:20:34 pppoe,ppp,debug,packet    <mru 1492> 
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfAck id=0x1 
13:20:34 pppoe,ppp,debug,packet    <mru 1492> 
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: sent LCP ConfReq id=0x24 
13:20:34 pppoe,ppp,debug,packet    <mru 1492> 
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP ConfAck id=0x24 
13:20:34 pppoe,ppp,debug,packet    <mru 1492>

And after all of the above, this is also new:

13:20:34 pppoe,ppp,debug,packet  pppoe-wan: sent LCP EchoReq id=0x0 
13:20:34 pppoe,ppp,debug,packet     <data len=1484> 
[..IPCP / IPV6CP Conf Stuff..]
13:20:34 pppoe,ppp,debug,packet  pppoe-wan: rcvd LCP EchoRep id=0x0 
13:20:34 pppoe,ppp,debug,packet     <data len=1484>

Going further with Ethernet MTU of 1520 changes only the new packet shown above (ppp-max-payload) changing from 1492 to 1500, but sadly (for me) only that. The rest is the same as the above, resulting PPPoE interface MTU of 1492.

 
13:20:50 pppoe,debug,packet ether1: sent PADI to FF:FF:FF:FF:FF:FF 
13:20:50 pppoe,debug,packet     ppp-max-payload=1500 
13:20:51 pppoe,debug,packet ether1: sent PADI to FF:FF:FF:FF:FF:FF 
13:20:51 pppoe,debug,packet     ppp-max-payload=1500 
13:20:52 pppoe,debug,packet ether1: rcvd PADO from 1C:20:DB:XX:XX:XX 
13:20:52 pppoe,debug,packet ether1: sent PADR to 1C:20:DB:XX:XX:XX 
13:20:52 pppoe,debug,packet     ppp-max-payload=1500

Why is RouterOS acting this way? requiring Ethernet MTU to be set to 1512 for proper detection of MTU 1492 for the PPPoE interface? (or like you’ve said, 1520 for 1500 PPPoE).
I was setting PPPoE MTU/MRU to 1492 manually until now because of this (with no issues, it worked, actual MTU resulted in 1492).
Thanks.
Worth filing up a bug report?

14

That’s not a bug: https://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/pppmpiwf.html

The actual potential bug is, why do we need 1520 ethernet MTU to achieve 1500+8 PPPoE overhead? Extra 12 bytes go somewhere, right? My theory is, those extra bytes are negotiated with the PON link itself, Fibre optics encapsulates ethernet inside the PON, so that itself will take overhead and likely adds the extra 12 bytes.

Stick with 1520 though, your PPPoE client will then have true 1500 MRU with zero packet fragmentation for incoming traffic, better download bandwidth performance basically.

15

That’s the one I was reffering to, how and why are those 12 (apparently invisible since it works just fine with 1500 and manualy setting 1492 for the PPPoE client interface) bytes getting in the picture.
I wasn’t referring to the max-payload packet, I was just underlining the differences there.

16

MikroTik support is garbage, so good luck trying to figure out why those extra 12 bytes are required. The only reason I’m on MikroTik is due to PCC and Nth which is crucial for my load balancing setup, else I’d be out of this vendor. In theory, 1508 ethernet MTU is the correct value to achieve 1500 MTU/MRU on PPPoE client for sure.

17

Regarding the MRU, no, here it shows only 1492 (max-mtu/mru both unset / auto) but I’ll stay with 1520 in case the ISP decides to implement RFC4638 anyway.
ppp-mtu.PNG

18

So MRU is not always going to be supported @1500. We found here in my country that about 20+ different OLT/ONT brands have broken MTU negotiation mechanisms on layer 2, so even if the MikroTik router is set for 1520 MTU, the underlying layer 2 link between the ONT and the router is capped at 1500 MTU.

We have tested three different brands and confirmed they support jumbo frames, namely:
TP-Link GPON ONTs
Genexis ONT/ONUs
Huawei (basically all the models)
A few models of Nokia’s

Long Story short, those in the know about this in my country ends up purchasing ONT/ONU models individually from the above brands. I usually recommend GX Earth 1000R as it’s XPON and supports both GPON and EPON.

19

I wrote to support about this anyway, I had good results with support in the past, the issues reported were fixed.

20

Let us know, 12 bytes going to thin air isn’t possible. Someone suggested it’s “padding” exclusive to MikroTik which happens to be undocumented.

Perhaps you can help this gentleman realise my solution to broken MTU is the most effective and works for UDP, not just TCP via MSS clamping: http://forum.mikrotik.com/t/some-websites-unavailable-on-ipv6/145044/13