Forum - www.netflix.com not working over SixXS tunnel :: SixXS

www.netflix.com not working over SixXS tunnel

Shadow Hawkins on Monday, 23 March 2015 16:35:54

I've been trying to figure out why I can't connect to www.netflix.com over my SixXS IPv6 tunnel. I am able to connect to Netflix without any problem using native IPv6 from XS4All at a different location. When I switch from my SixXS tunnel to my HE tunnel, netflix is loaded correctly. If I disable IPv6 (forcing IPv4) I can connect to netflix without any problem. I seem to be able to get the correct IPv6 addresses using nslookup but I can't seem to get any of my browsers to connect to www.netflix.com when I have IPv6 turned on. Can anybody help me with getting to the root cause of this problem?

www.netflix.com not working over SixXS tunnel

Jeroen Massar SixXS Staff

on Monday, 23 March 2015 16:47:05

Can anybody help me with getting to the root cause of this problem?

Traceroute6, tracepath6 and friends will be your first thing to check. You likely have MTU issues some way or another.

www.netflix.com not working over SixXS tunnel

Shadow Hawkins on Monday, 23 March 2015 16:55:20

Jeroen Massar wrote:

> Can anybody help me with getting to the root cause of this problem? Traceroute6, tracepath6 and friends will be your first thing to check. You likely have MTU issues some way or another.

Thanks, I'll change the MTU to be identical to the HE tunnel and see if that helps the issue. I didn't even think about that to be honest.

www.netflix.com not working over SixXS tunnel

Shadow Hawkins on Monday, 23 March 2015 17:03:26

Jeroen Massar wrote:

> Can anybody help me with getting to the root cause of this problem? Traceroute6, tracepath6 and friends will be your first thing to check. You likely have MTU issues some way or another.

Jup, turned out to be the MTU. Thanks so much for pointing me in the right direction!

www.netflix.com not working over SixXS tunnel

Shadow Hawkins on Friday, 27 March 2015 21:45:27

Lennaert Goris wrote:

Jeroen Massar wrote:

> Can anybody help me with getting to the root cause of this problem? Traceroute6, tracepath6 and friends will be your first thing to check. You likely have MTU issues some way or another.

Jup, turned out to be the MTU. Thanks so much for pointing me in the right direction!

Hello, I have the same problem - Netflix works only when the ipv6 interface is down (I use aiccu). Could you explain how you solved this, I tried to blindy change the tunnel MTU to 1428, but this didn't help. I'm not sure MTU is the problem in my case, netflix works on another tunnel I have (with default MTU 1280), different ISP though. Grateful for any help! /Fredde

www.netflix.com not working over SixXS tunnel

Jeroen Massar SixXS Staff

on Sunday, 29 March 2015 08:31:08

I tried to blindy change the tunnel MTU to 1428, but this didn't help.

Did you read the FAQ about MTU?

www.netflix.com not working over SixXS tunnel

Shadow Hawkins on Tuesday, 31 March 2015 21:28:16

I am also having problems connecting to Netflix with ipv6 but not with ipv4. The problems started about 3 weeks ago. My tunnel MTU is 1280.

www.netflix.com not working over SixXS tunnel

Jeroen Massar SixXS Staff

on Wednesday, 01 April 2015 08:08:54

Eric Negaard wrote:

I am also having problems connecting to Netflix with ipv6 but not with ipv4. The problems started about 3 weeks ago. My tunnel MTU is 1280.

As above: "Traceroute6, tracepath6 and friends will be your first thing to check."

www.netflix.com not working over SixXS tunnel

Shadow Hawkins on Wednesday, 08 April 2015 02:10:11

Fredrik Welander wrote:

Lennaert Goris wrote:

Jeroen Massar wrote:

> Can anybody help me with getting to the root cause of this problem? Traceroute6, tracepath6 and friends will be your first thing to check. You likely have MTU issues some way or another.

Jup, turned out to be the MTU. Thanks so much for pointing me in the right direction!

I'm afraid an MTU of 1428 isn't gonna cut it, netflix only works if you set the tunnel MTU to 1480 so this solution probably won't work for AICCU setups. I did find that if I set my MTU in my OS to the same value as that of my tunnel MTU, netflix works. So clearly, the path MTU discovery is broken. The big question is, where's the offender. For an answer to that, I'd suggest you follow the discussion in this ticket

www.netflix.com not working over SixXS tunnel

Jeroen Massar SixXS Staff

on Wednesday, 08 April 2015 08:38:12

I'm afraid an MTU of 1428 isn't gonna cut it,

Why not? The minimum IPv6 MTU is 1280.

so this solution probably won't work for AICCU setups.

AICCU can configure both proto-41 (/heartbeat) and AYIYA tunnels. proto-41 tunnels can have a MTU of 1480 when the Path MTU is 1500 clean.

I did find that if I set my MTU in my OS to the same value as that of my tunnel MTU, netflix works. So clearly, the path MTU discovery is broken.

That indicates that TCP MSS is being used and pMTU being ignored.

The big question is, where's the offender. For an answer to that, I'd suggest you follow the discussion in this ticket

Which only indicates that on the path ICMPv6 is being dropped. Hence, something for Netflix to look into..

www.netflix.com not working over SixXS tunnel

Shadow Hawkins on Wednesday, 08 April 2015 12:42:01

Jeroen Massar wrote:

I'm afraid an MTU of 1428 isn't gonna cut it,

Why not? The minimum IPv6 MTU is 1280.

Because an MTU of 1428 is 52 shy of the MTU of 1480 that Netflix seems to assume as the MTU to rule them all.

so this solution probably won't work for AICCU setups.

AICCU can configure both proto-41 (/heartbeat) and AYIYA tunnels.

proto-41 tunnels can have a MTU of 1480 when the Path MTU is 1500 clean.

Then I spoke to soon, if one can set an MTU of 1480, then things should work ok

I did find that if I set my MTU in my OS to the same value as that of my tunnel MTU, netflix works. So clearly, the path MTU discovery is broken.

That indicates that TCP MSS is being used and pMTU being ignored.

Exactly what I was thinking, that is why I tried this. I realize it's not a real solution but it helped me reach Netflix with my IPv6 turned on.

The big question is, where's the offender. For an answer to that, I'd suggest you follow the discussion in this ticket

Which only indicates that on the path ICMPv6 is being dropped. Hence, something for Netflix to look into..

Jup, that's what I've concluded as well. I've also gathered tracepath6 data: 1?: [LOCALHOST] 0.333ms pmtu 1500 1: 2001:1af8:fe00:84e9:74:caff:fe53:177a 1.128ms 1: 2001:1af8:fe00:84e9:74:caff:fe53:177a 0.977ms 2: 2001:1af8:fe00:84e9:74:caff:fe53:177a 0.926ms pmtu 1280 2: 2001:1af8:fe00:4e9::1 50.810ms 3: 2001:1af8:4050::2 68.280ms asymm 2 4: 2001:1af8:4050::1 76.405ms asymm 3 5: 2001:1af8::81:17:32:172 44.785ms asymm 4 6: 2001:41a8:100:2::35 43.015ms asymm 7 7: 2001:41a8:400::11 61.249ms asymm 9 8: 2001:41a8:400::20 59.929ms 9: 2001:41a8:400:2::7a 87.510ms asymm 8 10: no reply 11: no reply 12: 2a01:578::9 69.556ms asymm 16 13: 2a01:578::1d 98.897ms asymm 16 14: 2a01:578::b 83.453ms asymm 12 15: 2a01:578::b 69.528ms asymm 12 ... 31: no reply Too many hops: pmtu 1280 Resume: pmtu 1280 I would appreciate some assistance with interpreting this info. To me it seems that I'm not getting ICMPv6 replies from the devices on hop 9, therefore hop 10 and 11 show up as "no reply". Then I get no reply 2a1:578::b onwards. Now if I understand this thing correctly, the path from the Netflix side is "clear" up until the tunnel (which is where the mtu is set to 1280) at which point the device uses ICMPv6 to inform netflix that it doesn't support the MTU they are using (I suspect 1480). This message never reaches the netflix servers cos it seems to be blocked. A quick internet search on Amazon EC2 provided me with this link which seems to support this theory. The Netflix support team is however less then helpful here as they have no clue what MTU is and keep insisting that IPv6 is still experimental.

www.netflix.com not working over SixXS tunnel

Jeroen Massar SixXS Staff

on Wednesday, 08 April 2015 14:11:17

Because an MTU of 1428 is 52 shy of the MTU of 1480 that Netflix seems to assume as the MTU to rule them all.

Why do you think that? Netflix works fine from my home link which is using 1280 for IPv6.

Then I spoke to soon, if one can set an MTU of 1480, then things should work ok

AICCU fetches that from TIC, hence if you set 1480 for a proto-41 tunnel in the UI, AICCU will also configure a MTU of 1480 on the client side. Hence why TIC is so useful ;)

I would appreciate some assistance with interpreting this info. To me it seems that I'm not

getting ICMPv6 replies from the devices on hop 9, therefore hop 10 and 11 show up as

"no reply". Then I get no reply 2a1:578::b onwards.

Hop 9 is replying, just not hop 10 + 11. Do note that traceroute is 'one way' it thus could be that these devices are visible the other path, unless they are assymetric. From the 'assym' notices that is very likely. Hence why it is extremely important to always have traceroutes/paths from two sides. Note that packets can go missing in either direction.

Then I get no reply 2a1:578::b onwards.

2a01:578::b onwards, which is inside the Netflix network.

Now if I understand this thing correctly, the path from the Netflix side is "clear" up until the tunnel

Nothing confirms that. Unless you are able to produce a tracepath from Netflix towards your side of the tunnel. Also note that tracepaths are mostly informational, problems can hide in various places. As an example: www.google.com does provide a full tracepath, but they ignore PtB anyway (instead fixing MSS to a magically picked number).

at which point the device uses ICMPv6 to inform netflix that it doesn't support the MTU they are using (I suspect 1480).

PMTU works differently: source (Netflix) sends a 1500 byte packet. A router along the path sees that the next link has a MTU that is smaller than that. Hence it sends back a ICMPv6 PTB (Packet Too Big) to the source. Normally the source accepts the ICMPv6 PTB and then resends the packet (based on info in the ICMPv6 packet). In the case where the PTB is dropped though, the only thing that can happen is that TCP keeps on trying sending the packet over and over again. And in the case of TCP, there is additional "packet size" info in the MSS field of the TCP header, this can be used to cheat a bit with how large the packet is supposed to be. This only works for TCP though. (hence dropping PTBs nicely breaks Google's QUIC and also UDP-based HTTP/2 ;) Note that in the case of Google the problem is that their loadbalancers do not support handling ICMPv6 as they do hash based routing. As the source/dest pair of a ICMP PTB does not hash the same, they just drop them instead of handling them specially, and thus never get to see the PTB and there they break IPv6....

The Netflix support team is however less then helpful here as they have no clue what MTU is and keep insisting that IPv6 is still experimental.

I've never seen them state that IPv6 is "experimental": http://techblog.netflix.com/2012/07/enabling-support-for-ipv6.html

Please note Posting is only allowed when you are logged in.